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.john...@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
