Confused by libcap (pcap) and wireless

Question

Reference Information. I teach myself about sniffing packages. I run a very simple server in one shell, telnet to it from another, and then try to use various methods to sniff traffic. When I use raw sockets (IPPROTO_TCP), I commit what I send. I only capture what I send, nothing more from the Internet. libcap behavior confuses me as follows:

(1) First, to test this, I capture all devices using pcap_findalldevs (see also (2) below). I find wlan0 fine. If I connect to "all traffic" (on the man page) using

if ( !( pcap_handle = pcap_open_live(NULL, 4096, 1, 0, errbuf) ) ) 

I record what I send (plus more, see (3)). when i try to connect to it using

 if ( !( pcap_handle = pcap_open_live("wlan0", 4096, 1, 0, errbuf) ) ) 

which seems to me to be the right way to do this, and not "everything", I collect a lot of general traffic, but I do not send anything. Ideas?

(2) First, I find all devices using pcap_findalldevs. Since the pcap_if_t structure may have several elements, I print all this data to see the following:

 Devices found: 1. eth0 - None: family: 17, address: 2.0.0.0 2. wlan0 - None: family: 17, address: 3.0.0.0 family: AF_INET, address: 192.168.0.159 family: 10, address: 0.0.0.0 3. usbmon1 - USB bus number 1: 4. usbmon2 - USB bus number 2: 5. usbmon3 - USB bus number 3: 6. usbmon4 - USB bus number 4: 7. usbmon5 - USB bus number 5: 8. any - Pseudo-device that captures on all interfaces: 9. lo - None: family: 17, address: 1.0.0.0 family: AF_INET, address: 127.0.0.1 family: 10, address: 0.0.0.0 

I am new to this. Some devices offer AF_INET (= IPv4), IPv6 (10), and packet (17) capture. when I connect to "wlan0", how is this ensured, do I connect to the corresponding "addresses" of any device? Is this a problem?

(3) When using raw sockets, I really capture only what I sent to my server. When I use libcap, I also commit that of the printed bytes should be Internet headers. I am not at all familiar with this. If someone could clarify what exactly I catch here, what I do not fix on raw sockets, this would be appreciated. Are these UDP or ICMP packets that, by definition, the IPPPROTO_TCP socket will not capture, why haven't I seen those using raw sockets?

Thank you very much.

Edit: I work under Ubuntu 10.04 on a Toshiba netbook using the gcc / gdb command.

Answer 1

• It’s somewhat surprising that when you capture wlan0 you don’t see the packets you sent, if they are really sent through your Wi-Fi device. Are you sending them to other computers on a Wi-Fi network? If, for example, you send them to other processes on your computer, they will be displayed on lo , not on wlan0 (and if you send them to other computers on a Wi-Fi network, and not to other processes on your computer, they will not be displayed on lo - no, all traffic will ultimately not go through the loopback interface).
• The list of addresses that you get from pcap_findalldevs() is NOT a list of addresses for which you can capture on this interface, it is just a list of network addresses that the system has for this interface. You cannot choose which addresses to capture - this is exciting for everyone. You capture the interface, not the address.
• Libpcap is different from a raw socket; it gives headers of a lower level than those sent or received, as well as data. For an Ethernet device, you will see Ethernet headers; for a Wi-Fi device, what you see depends on the operating system you are on and the headers you have selected (on the Linux you use, you will probably see Ethernet headers if you do not capture “monitor mode” , in this case you will see either the Wi-Fi headers or the “radio” heading, for example radiotap headers followed by the Wi-Fi headers); for "any" device you will see "ready-made Linux headers"; and so on. You will need to call pcap_datalink() after calling pcap_open_live() to find out the type of header for the interface; see the list of link layer types ( pcap_datalink() will return the DLT_ value as indicated there; do not allow the specified number to be the same as the DLT_ value, compared with the DLT_ value by name).