Network chatter generator

Mon Feb 26 02:59:40 UTC 2024

I keep running into similar issues as far as stack validation goes.   (And
by stack I mean all the way up not just L2/L3).

I know that my processor has an ethernet port it can't keep up with in all
circumstances.  Flooding it with more packets than it can handle isn't
useful,  other than to validate how it recovers from a packet flood.

So, I too would like a similar tool.  I might add some "directed at me but
intended for someone else" traffic but even if it was broadcast only it
would be useful.  Even if it was just a library of actual broadcast packet
traffic in networks with lots more than arp being tossed around.

On Sun, Feb 25, 2024, 6:39 PM Brandon Martin <lists.nanog at monmotha.net>
wrote:

> The replies I've gotten have been somewhat useful, but I think the
> purpose of what I'm seeking may not have been apparent.
>
> I'm not looking to perform volumetric or even known-vulneribility tests.
>   I have some decent ways to do both and even know that I can make the
> device in question unhappy by flooding it with large volumes of nonsense
> traffic so as to overwhelm its ability to process them as quickly as
> they come in.  This isn't surprising given its limited resources and
> 100Mb connection, and the device recovers once it works through the
> backlog and has some free buffers again.  Humongous IP datagrams broken
> into numerous small fragments is a great way to annoy almost anything,
> FWIW.
>
> What I'm really looking for is a somewhat pre-canned list of typical
> network chatter that embedded devices would have to copy due to being
> addressed to broadcast or large multicast groups but that said devices
> are likely to consider garbage and the ability to generate traffic from
> those lists with various timings and breadth of field values.  There's a
> LOT of this type of traffic on typical consumer and enterprise networks,
> and the issue is that I'm constantly finding new examples of things I'd
> never dream exist that tickle corner cases in network stacks, drivers,
> or even sometimes hardware.
>
> As an example, Cisco Meraki devices send SNAP framed packets for some
> proprietary loop-avoidance protocol even on networks using Ethernet II
> framing and even if STP is enabled.  I found out the hard way that the
> Ethernet MAC on some micros doesn't like these if you have certain
> receive accelerator functions enabled - it locks up and won't receive
> anything you perform a fairly hard reset on it.  The volume of traffic
> here is tiny - just one packet every few seconds from the nearest Meraki
> switch you're on - but can tickle processing bugs.
>
> I can and have played back PCAPs from kind folks running Wireshark.
> Combined with playing with the packet timing, this is useful, but it
> limits me to things me and my kind friends have seen on their networks
> before.  The same would be true if I tried to make my own chatter
> generator using something like scapy.
>
> --
> Brandon Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240225/6f087798/attachment.html>