On Jan 5, 2019, at 9:53 AM, Alan Partis <alpartis@xxxxxxxxxxxxxx> wrote:
> I've got a case where I'm certain there are packets on the wire, but I'm
> not able to pick them up in wireshark/tshark (or from tcpdump and dumpcap
> either for that matter).
>
> The setup:
>
> a device (that is currently under development -- I'm the developer)
> appears to be flooding the network with some kind of packet, but the
> device itself appears to be off line i.e. `ip addr` reports no address for
> the interface and indicates that its 'state' is down. The packet flood is
> enough to DOS the rest of my LAN (unless I segregate or isolate it) and
> the flood stops when I disconnect the device from the LAN.
>
>
> The evidence:
>
> * the local switch shows flashing activity lights on the port
> the device is connected to.
> * I've inserted a sharktap device in-line between the device and the
> switch -- activity lights flash on all ports there as well.
What drives those lights?
I.e., do they light up if:
a runt packet is seen;
a packet with an invalid CRC is seen;
other low-level packet errors occur?
> The problem:
>
> * I can't sniff these packets.
On the machine on which you're sniffing:
can the Ethernet adapter supply packet events for runt packets/packets with an invalid CRC/other errors?
if so, does the driver in the OS for that machine put the adapter into that mode when you tell the driver to put the adapter into promiscuous mode (I think some drivers do)?
> I have command line/console access on the device itself, but running
> tcpdump there doesn't show the packet flood. I presume this is because
> the ethernet driver is not reporting anything back to the kernel because
> it thinks it's down.
You'd have to look at the driver, or ask the vendor about it if it's not open-source, to see if that's the case.
What OS is the device running? (I'm guessing it's probably running some OS, probably UNIX-like but possibly Windows, given that you mention tcpdump.)
If the interface is configured down, does the code path from whatever code would send packets to the point at which packets are handed to the adapter (not the driver, the adapter, so this code path includes the driver) still function on that OS with that driver?
If so, where is the "looping back" for receiving transmitted packets done? I think it's done above the driver in Linux, but done in the driver in BSD-flavored OSes.
