hi, I'm looking for more detailed description on how Wireshark works. From the Wireshark book from Laura Chappell it says the we have: Network --> winpcap / libpcap (capture filters) --> dumpcap (the actual capture engine) --> core dump (filters, dissectors ...). I guess the NIC driver is first that will "see" the frame , correct ? If a host receives a broadcast that has not it's IP in the layer 3 header it will drop the packet, correct ? So how is Wireshark able to "see" the packet in question ? BR Adam asked 08 Jan '16, 05:14  adasko edited 08 Jan '16, 16:48  Guy Harris ♦♦ |
3 Answers:
There are several paths through which a packet can travel in the host networking stack. The "regular" networking stack will, in typical cases, drop IP packets if they're not sent to one of the host's IP addresses or to a broadcast IP address, and, even for those packets, it'll drop them (perhaps with an ICMP response or a TCP RST or something such as that) if there's nothing running on the host listening for those packets at the transport layer (or listening for raw IP packets). The path used by the mechanisms that libpcap and WinPcap use does not, by default, filter on anything in layer 3 whatsoever - it doesn't even look at the IP header. The mechanisms may allow a simple layer 2 filter be specified to check, for example, the Ethernet type of a packet, but, if they do provide that type of filtering, libpcap and WinPcap don't use it. Instead, they either tell those mechanisms to apply a "capture filter" (which is what the capture filter string you type into tcpdump or Wireshark or TShark or dumpcap is translated into), and those mechanisms drop packets that don't match the filter, or, if the mechanism doesn't support capture filters (they're supported on Linux, *BSD, OS X, Solaris 11, AIX, and Windows), they filter out the packets themselves. So, if there's no capture filter, every packet supplied by the NIC to the host should go through the host networking stack up to the application using libpcap/WinPcap. Now, for unicast (rather than broadcast) packets, the NIC will normally reject packets not sent to one of the adapter's MAC addresses, and not even deliver them to the host. However, wired NICs can usually be put into "promiscuous" mode, in which case all packets they see get passed to the host even if they're not to one of the "right" MAC addresses, and they'll get provided to the capture mechanism. For wireless NICs, promiscuous mode often doesn't work, and you may need "monitor" mode. Many NICs won't even look at the layer 3 headers of packets at all. Those that do - for example, those doing IP header checksum checking, TCP or UDP packet checksum checking, IP or TCP reassembly, redirecting different packet flows to different queues or interrupting different hosts, etc. - may disable all of that in promiscuous mode. answered 08 Jan '16, 16:45 Guy Harris ♦♦ |
Adam, the packet filter in the NIC hardware acts only at L2 (MAC address). Once the packet passes the MAC filter because its dst MAC is the NIC's own (or broadcast or multicast to which the NIC is subscribed, as discussed in other question) or because the promiscuous mode is on, software (and thus Wireshark or, even more precisely, WinPcap) will get the packet. The reason is that the NIC cannot know in advance whether L3 will be OSI, IPX, IPv4, IPv6, ..., and that there is actually little point in filtering at L3 because the mapping of L3 address to L2 address at LAN is mostly 1:1 (except a few exceptions ;-) ). answered 08 Jan '16, 09:17  sindy I wonder what happens to various OS's and NIC drivers and WinPcap\libpcap if a packet with the correct MAC address and an incorrect destination IP address is received. Does anyone know? (08 Jan '16, 09:52) grahamb ♦ @grahamb, maybe this topic deserves its own question as not everyone is subscribed to everything that happens on this site? My understanding is such that as even Windows machines can act as IP routers under circumstances, arrival of a packet with dst MAC of the local interface and dst IP not matching any of the local interfaces' ones should not cause any fireworks as routers simply forward such packets, so protocol stacks of routing-capable OSes should not get mad on receiving such packet when their routing functionality is not enabled. So from the point of view of libpcap/WinPcap visibility of such packet, reception of such packet is a standard situation (at least if we talk about IP). From the point of view of L3 protocol stacks in general, different reactions to arrival of a packet of non-local dst L3 address when routing is disabled (silent dropping or some error report packet sent upstream) may be required depending on the specification of that particular protocol, and also depending on a particular scenario (e.g. whether the dst IP matches one of local interfaces' subnets or not). Not that I would know what behaviour is required in such case even for IPv4, leaving other protocols aside ;-) (08 Jan '16, 12:33) sindy |
Even when not in promiscuous mode, many (most?) NICs won't bother looking at the layer 3 header, so they'll deliver to the host packets with the right MAC destination address but the wrong IP destination address.