[tcpdump-workers] Format of libpcap packet

Jesse Johnson jesse.alan.johnson at gmail.com
Sun Mar 29 00:16:16 EDT 2015


Awesome! Exactly what I was looking for. I appreciate the great 
references. I looked over the code and saw the references for different 
frame types, but couldn't piece it together.

Can you recommend a text that explains layer 2 networking a little more 
succinct than the IEEE standards?

Thank you,

Jesse Johnson

On 03/28/2015 10:55 PM, Guy Harris wrote:
> 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