Re: [Wireshark-users] capture not seeing packets
On Jan 5, 2019, at 4:09 PM, Alan Partis wrote: > 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. It's not, except to the extent that some hardware *might* have a "supply bad packets to the host" option and some drivers *might* enable that option if you ask them to put the device into promiscuous mode; if those are the case, all Wireshark could do would be to capture in promiscuous mode. You'd have to determine what type of interface is on your laptop and whether the driver does that. This would probably be easier for Linux or *BSD than for, say, Windows or macOS, as it's easier to figure this out for open-source drivers. (In a better world, all OS kernel capture mechanisms - or mechanisms atop which capture mechanisms can be built, such as NDIS on Windows - would offer, for wired shared-medium LAN adapters, both "promiscuous" mode, which provides all good packets seen by the adapter even if they're not directed to the host but discards bad packets and doesn't provide the CRC as part of the packet data, and "sniffer" mode, which provides all packets, good or bad, seen by the adapter, and provides the CRC as well as error flags such as runt, bad CRC, etc.. Sadly, we don't live in that world. Of course, once you get to switched networks, you probably also have to configure a monitor port on which you do sniffing, and the switch would have to pass on bad packets to that port, or you'd have to use a tap. But I digress) ___ Sent via:Wireshark-users mailing list 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
Re: [Wireshark-users] capture not seeing packets
On Jan 5, 2019, at 9:53 AM, Alan Partis 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 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
[Wireshark-users] capture not seeing packets
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. The problem: * I can't sniff these packets. 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. I have a laptop, running the latest wireshark, connected to the tap port on the sharktap, but it's not showing me the flood either (it IS running in promiscuous mode and DOES show me other packets that might be on the wire). For what it's worth, I've even connected the device directly to the laptop w/o the switch or tap and I see the same thing: nothing. How can I determine what's on the network? It's very clear that there ARE packets on the network based on the activity lights and the resulting DOS from the flood. ___ Alan Partis thundernet development group ___ Sent via:Wireshark-users mailing list 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
