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
