[tcpdump-workers] Format of libpcap packet

Guy Harris guy at alum.mit.edu
Sat Mar 28 22:55:03 EDT 2015


On Mar 28, 2015, at 5:46 PM, Jesse Johnson <jesse.alan.johnson at gmail.com> wrote:

> I am dissecting pcap packets generated by airodump-ng using libpcap and I seem to be offset on the access of the Ethernet fram.

You're assuming here that you *have* Ethernet frames.  "airo" refers to "the air", as in "over the air", as in "packets transmitted using radio waves", and they mean "Wi-Fi", as in "IEEE Std 802.11", which specifies packets that do *not* have Ethernet headers.

As this page:

	http://www.aircrack-ng.org/doku.php?id=airodump-ng

says, "Airodump-ng is used for packet capturing of raw 802.11 frames", where "raw 802.11 frames" means you're not getting the "fake Ethernet header" that you get when not capturing in monitor mode on an 802.11 adapter.  (If you're not in monitor mode, the only traffic you'll see is traffic from or to your machine; you won't see any other traffic on your network, i.e. no third-party unicast traffic.)

> I am using the call pcap_next_ex()

Use the call pcap_datalink() after you've opened the pcap_t but *before* you ever call pcap_next_ex() - or pcap_next() or pcap_dispatch() or pcap_loop() - and use the value it returns to determine what type of packets you will get.

Unless it's DLT_EN10MB, they're *not* Ethernet packets.

See

	http://www.tcpdump.org/linktypes.html

for a list of LINKTYPE_ values (which appear in files) and DLT_ values (as returned by pcap_datalink(); they're usually the same as LINKTYPE_ values, albeit with different names, but there are a few differences to deal with some annoying differences between OSes).

> and working with the returned ethernet packet. I read the first destination and source MACs into a C array and they both seem to be offset by one byte. For example, I get FF:FF:FF:FF:FF:D5 as a destination MAC instead of FF:FF:FF:FF:FF:FF which would be a broadcast address.
> 
> Is the Ethernet frame returned by the call pcap_next_ex() and exact replica of the original frame, no extra information inserted?

If it *is* an Ethernet frame - i.e., if pcap_datalink() returned DLT_EN10MB - yes, it is.

Otherwise, it's *not* an Ethernet frame, and interpreting it as one would be a mistake.  If, for example, it's DLT_IEEE802_11, it'll be an 802.11 header, which looks like this:

	http://www.wildpackets.com/images/compendium/802dot11_frame.gif

so that you have 4 bytes before the first MAC address.  (That diagram shows an 802.11 header with 4 MAC addresses.  Most data frames will probably have 3 MAC addresses, with some control frames having only 2 MAC addresses, so that diagram is incomplete.  Yes, this means that the 802.11 link-layer header is variable-length; it gets worse with, for example, QoS fields.)

If it's DLT_IEEE802_11_RADIO, it's even more complicated, as it will have a radiotap header:

	http://www.radiotap.org

containing radio metadata, followed by an 802.11 header.  Other forms of radio metadata headers preceding the 802.11 header include Prism headers, with DLT_PRISM:

	http://www.tcpdump.org/linktypes/LINKTYPE_IEEE802_11_PRISM.html

and AVS headers, with DLT_IEEE802_11_RADIO_AVS:

	http://web.archive.org/web/20040803232023/http://www.shaftnet.org/~pizza/software/capturefrm.txt



More information about the tcpdump-workers mailing list