[tcpdump-workers] Format of libpcap packet
Hi, I am dissecting pcap packets generated by airodump-ng using libpcap and I seem to be offset on the access of the Ethernet fram. I am using the call pcap_next_ex() 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? On a side note, does anyone see any value in porting the project to go? It have started looking at the source to see if there are any "show stoppers" and haven't seen any yet. My end project is to perform big data analysis on very large samples of network packets collected in open environments to test for correlations or irregularities. To perform the analysis, I would like to get access to the actual byte values of the Ethernet frame and IP headers. Thank you for your assistance, Jesse Johnson ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Format of libpcap packet
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 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
[tcpdump-workers] Work on development
Group, I would like to put some effort into the code base. What are we using to edit the code and submit changes? Any special rules for submitting changes? -- Jesse Johnson 612-840-1714 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump-workers Digest, Vol 34, Issue 3
Thanks Michael, Is there a list of things that need to be done ie: bug fixes, new features, documentation, etc...? Jesse On Mon, May 11, 2015 at 12:00 PM, wrote: > Send tcpdump-workers mailing list submissions to > tcpdump-workers@lists.tcpdump.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers > or, via email, send a message with subject or body 'help' to > tcpdump-workers-requ...@lists.tcpdump.org > > You can reach the person managing the list at > tcpdump-workers-ow...@lists.tcpdump.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tcpdump-workers digest..." > > > Today's Topics: > >1. Re: Work on development (Michal Sekletar) > > > -- > > Message: 1 > Date: Mon, 11 May 2015 12:55:12 +0200 > From: Michal Sekletar > To: tcpdump-workers@lists.tcpdump.org > Subject: Re: [tcpdump-workers] Work on development > Message-ID: <55508a90.1000...@redhat.com> > Content-Type: text/plain; charset=windows-1252 > > On 05/08/2015 06:53 PM, Jesse Johnson wrote: > > > I would like to put some effort into the code base. > > Much appreciated. > > > What are we using to edit the code and submit changes? Any special rules > for submitting changes? > > To work on tcpdump/libpcap you don't need any specialized tools. Basic > tools like code editor (vim, emacs), C compiler, GNU Make and GNU > autotools are pretty much all you need. SCM we use is git. You can find > current master branches of tcpdump and libpcap here, > > https://github.com/the-tcpdump-group > > Changes are committed to your own fork on GitHub and once you are happy > with your patch you can submit Pull Request. If you are new to GitHub > here is the link where you can read how does the basic workflow looks like. > > https://guides.github.com/introduction/flow/ > > Michal > > > > > -- > > Subject: Digest Footer > > ___ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers > > > -- > > End of tcpdump-workers Digest, Vol 34, Issue 3 > ** > -- Jesse ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump-workers Digest, Vol 34, Issue 3
I found the current issues and proposed features on the github page. I will start getting some work done. Jesse On Mon, May 11, 2015 at 12:00 PM, wrote: > Send tcpdump-workers mailing list submissions to > tcpdump-workers@lists.tcpdump.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers > or, via email, send a message with subject or body 'help' to > tcpdump-workers-requ...@lists.tcpdump.org > > You can reach the person managing the list at > tcpdump-workers-ow...@lists.tcpdump.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tcpdump-workers digest..." > > > Today's Topics: > >1. Re: Work on development (Michal Sekletar) > > > -- > > Message: 1 > Date: Mon, 11 May 2015 12:55:12 +0200 > From: Michal Sekletar > To: tcpdump-workers@lists.tcpdump.org > Subject: Re: [tcpdump-workers] Work on development > Message-ID: <55508a90.1000...@redhat.com> > Content-Type: text/plain; charset=windows-1252 > > On 05/08/2015 06:53 PM, Jesse Johnson wrote: > > > I would like to put some effort into the code base. > > Much appreciated. > > > What are we using to edit the code and submit changes? Any special rules > for submitting changes? > > To work on tcpdump/libpcap you don't need any specialized tools. Basic > tools like code editor (vim, emacs), C compiler, GNU Make and GNU > autotools are pretty much all you need. SCM we use is git. You can find > current master branches of tcpdump and libpcap here, > > https://github.com/the-tcpdump-group > > Changes are committed to your own fork on GitHub and once you are happy > with your patch you can submit Pull Request. If you are new to GitHub > here is the link where you can read how does the basic workflow looks like. > > https://guides.github.com/introduction/flow/ > > Michal > > > > > -- > > Subject: Digest Footer > > ___ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers > > > -- > > End of tcpdump-workers Digest, Vol 34, Issue 3 > ** > -- Jesse ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
