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.
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