This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Where exactly wireshark does captures packets?

0	Hi, Could you please explain where exactly does wireshark captures incoming packets? Is it above device driver? Or, in between device driver and network interface? thanks, wireshark asked 14 Jul '13, 09:19 adityaholla 11●1●1●3 accept rate: 0%

One Answer:

Basically the capturing framework is placed between the NIC driver and higher layer protocols in the kernel (e.g. TCP/IP).

For a general overview of the libpcap architecture, please read this:

http://sharkfest.wireshark.org/sharkfest.11/presentations/McCanne-Sharkfest%2711_Keynote_Address.pdf

For WinPcap (the capturing framework of Wireshark on Windows), please see WinPcap FAQ Q-26 and the architecture overview paper of WinPcap.

http://www.winpcap.org/docs/iscc01-wpcap.pdf
https://www.winpcap.org/docs/th_degio.zip (please skip the first few italian pages)

Regards
Kurt

answered 14 Jul '13, 09:35

Kurt Knochner ♦
24.8k●10●39●237
accept rate: 15%

edited 14 Jul '13, 10:11

Thanks much Kurt.

Is it true for outgoing packets also? Because, wireshark even gives ethernet header(this header is added by device driver), right?

I'll go thru given pdf.

Thanks much!

(14 Jul '13, 09:54) adityaholla

Is it true for outgoing packets also? Because, wireshark even gives ethernet header(this header is added by device driver), right?

For outgoing packets, the driver, in an OS-dependent fashion, arranges that the packet be handed to the capture mechanism at about the same time that it's handed to the hardware to transmit.

(14 Jul '13, 10:47) Guy Harris ♦♦

Usually in an operating system the NIC driver is only responsible for direct hardware access (receiving and transmitting of network frames, generating interrupts etc.). If the OS wants to send a frame, it (actually a higher level driver) will create the ethernet frame and pass that to the hardware NIC driver in order to send it. Due to this architecture it is possible to intercept outgoing frames before they are sent, as the capture driver is placed 'somewhere' between the NIC driver (hardware) and the upper layer drivers (ethernet, ip, tcp, etc.).

(14 Jul '13, 10:57) Kurt Knochner ♦

Systems with BPF (*BSD, OS X, possibly AIX and Solaris 11 but I don't have access to the source): the capture mechanism (BPF) is called by the driver.

Linux: drivers end up calling OS kernel routines such as dev_hard_start_xmit() for transmitting packets and netif_receive_skb() for received packets, passing them the entire packet, complete with a link-layer header (except when it doesn't...), and those routines hand packets to all PF_PACKET sockets.

Other UN*Xes: I don't have access to the source, and so can't check.

Windows: the WinPcap capture mechanism's driver uses the Windows NDIS mechanism, which supplies received packets to a "protocol" (which is what the driver registers itself as) and can also supply transmitted packets if requested to do so (WinPcap requests it to do so). For received packets, the driver hands packets to NDIS to then supply to protocols; I'm not sure where transmitted packets are handled.

(14 Jul '13, 11:35) Guy Harris ♦♦

OK, Guy, so would you suggest to me scenarios under which dev_hard_start_xmit() sends a packet to a PF_PACKET socket (because, say, dumpcap is running) ... but does not send the packet to the hardware?

I'm facing a case where I can see the DNS lookup on the wire, the ARP exchange on the wire (the receiver is subnet-local) ... but not the TCP SYN. Whereas, the pcap gathered from the host itself sees the DNS exchange, the ARP exchange, and the TCP SYN

client ------- switch -------- {network} ------- server

dumpcap running on the client and a sniffer plugged into a mirror port on the switch

Linux 3.8.0-34-generic #49 precise (Ubuntu 12.04.03 LTS)

Does IPTables twink with dev_hard_start_xmit's behavior? [Not enabled in my case, but I'm wanting to understand the entire space, not just solve my particular issue.]

--sk

(24 Dec '13, 16:18) skendric

would you suggest to me scenarios under which dev_hard_start_xmit() sends a packet to a PF_PACKET socket (because, say, dumpcap is running) ... but does not send the packet to the hardware?

good question.

Does IPTables twink with dev_hard_start_xmit's behavior? [

I did a quick test. If you drop frames in the OUTPUT chain, Wireshark will not see them, so iptables handles the packet before the kernel gets a chance to send a copy to dumpcap.

So, here are some possible explanations that might cause your TCP traffic to appear in Wireshark on the client, but not on the wire. Some of these ideas might sound weird, but that's what I have seen in the wild several times ;-) People configure something and then forget about the fact and then wonder why certain things don't work :-)

You have several interfaces and the packet takes a different route than you believe (host route, etc.) - think also about policy based routing!
another chain in iptables modifies the packet. Think about NAT and the like. I did not test it, but I think that could well cause the described behavior, from what I remember about troubleshooting on iptables firewalls
there is a transparent (TCP) proxy running on the client that 'takes care' of the connection requests. This is usually the case for http(s) and ftp, where that behavior is desirable to scan the traffic.
there is some kind of tunnel (VPN like IPSEC or OpenVPN, IPinIP, etc.) on the client and the TCP packets are routed into that tunnel
Did you compare the MAC address of the ARP reply with the one in the TCP SYN? Are they identical?

There might be other reasons, but without a deeper insight in your environment it's hard to figure out what's going on.

Regards
Kurt

(25 Dec '13, 15:16) Kurt Knochner ♦

showing 5 of 6 show 1 more comments