What drives the lights? I don't have that degree of detail handy, but I guess the question I'd have to ask is this: is there a way to get Wireshark to _see_ runts or packets with invalid CRC, or other errors? I recognize that you're asking if there's a way to get the ethernet adapter to supply this info, so I'm going to assume that either way, it's not a function of Wireshark.
_______________________________________________________ Alan Partis thundernet development group On Sat, 5 Jan 2019, Guy Harris wrote: > On Jan 5, 2019, at 9:53 AM, Alan Partis <alpar...@thundernet.com> 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. > ___________________________________________________________________________ > Sent via: Wireshark-users mailing list <wireshark-users@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-users > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users > mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-users Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe
