Confused by libcap (pcap) and wireless

Question

Background: I'm teaching myself about packet sniffing. I run a very simple server in one shell, telnet to it from another, then try different methods to sniff on traffic. When I use raw sockets (IPPROTO_TCP), I capture what I send fine. I capture merely what I send, nothing else from the internet. libcap's behavior confuses me as follows:

(1) First, to check it out, I capture all devices with pcap_findalldevs (see (2) below as well). I find wlan0 fine. If I connect to 'all traffic' (per the man page) using

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

I capture 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 to me seems the proper way of doing this, not 'all', i capture lots of general traffic, but nothing I send. Ideas?

(2) I first find all devices using pcap_findalldevs. As the pcap_if_t structure possibly has several elements, I print all those out, 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 all new to this. Some devices offer capturing of AF_INET (=IPv4), IPv6 (10), and packet (17). when I connect to "wlan0", how is it ensured I connect to the proper of the 'addresses' of some device? Is that related to the problem?

(3) When using raw sockets, I really only capture what I sent to my server. When I use libcap, I also capture what, from the bytes printed out, must be internet headers. I am all new to this. If someone could elaborate what exactly I capture here which i don't capture on raw sockets, this would be appreciated. Are those UDP or ICMP packets which, by definition, my IPPPROTO_TCP socket would not capture, which would be why I didn't see those using raw sockets?

Many thanks.

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

Answer 1

1. It's somewhat surprising that, when capturing on wlan0, you're not seeing packets you send, if they're actually being sent over your Wi-Fi device. Are you sending them to other machines on your Wi-Fi network? If, for example, you're sending them to other processes on your machine, they'll show up on lo, not on wlan0 (and if you send them to other machines on your Wi-Fi network, rather than to other processes on your machine, they will not show up on lo - no, all traffic doesn't eventually go through the loopback interface).
2. The list of addresses you get from pcap_findalldevs() is NOT a list of addresses for which you can capture on that interface, it's just a list of network addresses the system has for that interface. You don't get to choose which addresses for which to capture - it captures for all of them. You capture on an interface, not an address.
3. Libpcap is different from a raw socket; it gives you lower-layer headers than the ones for the data being sent or received, as well as that data. For an Ethernet device, you'll see Ethernet headers; for a Wi-Fi device, what you see depends on the OS you're on and the headers you select (on Linux, which is what you're using, you'll probably see Ethernet headers unless you capture in "monitor mode", in which case you'll either see Wi-Fi headers or some "radio" header such as radiotap headers followed by Wi-Fi headers); for the "any" device, you'll see "Linux cooked headers"; and so on. You'll need to call pcap_datalink() after calling pcap_open_live() to find out the header type for the interface; see the list of link-layer types (pcap_datalink() will return the DLT_ value, as listed there; don't assume the number given there is the same as the DLT_ value, compare with the DLT_ value by name).