Re: Format of libpcap packet

[Jesse Johnson <jesse.alan.johnson () gmail com>]

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 () 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

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers