rfc: "canonical" radiotap parser

rfc: "canonical" radiotap parser

[David Young]

At <http://svn.cuwireless.net/svn/cuw/trunk/src/radiotap/> is the radiotap
parser that I mentioned the other day.  I believe the parser captures
all of the essential ideas of radiotap.  It is also a somewhat useful
program that uses libpcap to listen on the interface you specify on the
command line for radiotap frames (DLT_IEEE802_11_RADIO).  I have tried
to make it just as portable and self-contained C99 code as I can.

The parser is table-driven: adding new fields is a matter of adding
entries to the tables field_spec[] and field_info[].  The first table,
field_spec[], contains the Minimal Specification for a field.  The Minimal
Specification is the field's alignment and its width.  The alignment
must be a power-of-two, whole number of bytes.  The width must be a
non-negative, whole number of bytes.  Every radiotap interpreter needs to
know the minimal specification of fields 0..n in order to skip past those
fields to a field of interest, field n+1.  The second table, field_info[],
tells each field's name (long and short form) and units.  I use some macro
magic to link each entry in field_info[] to its Minimal Specification.
Call the information in field_info[] and in field_spec[] for each field,
that field's Complete Specification.  An interpreter such as tcpdump or
wireshark needs a field's Complete Specification in order to render the
field for you and I to read it.

I have included all of these fields in the parser,

        IEEE80211_RADIOTAP_RX_FLAGS
        IEEE80211_RADIOTAP_TX_FLAGS
        IEEE80211_RADIOTAP_RTS_RETRIES
        IEEE80211_RADIOTAP_DATA_RETRIES
        IEEE80211_RADIOTAP_XCHANNEL

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933 ext 24

Re: rfc: "canonical" radiotap parser

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

Hi Dave,

I just took a quick look at the parser, it looks pretty good. Andy has
done something similar and was willing to relicense it under BSD last I
asked him, his code is part of the Linux kernel right now:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=net/wireless/radiotap.c;hb=HEAD

It does a lot less than your parser since that already includes code to
print out the result which we obviously don't have in the kernel, but
other than that it's pretty similar conceptually. Just for reference.
Yours also has more detailed error reporting.

Small question on the code: why did you declare that radiotap_field is
aligned? It can potentially come from anywhere unaligned, no?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: rfc: "canonical" radiotap parser

[David Young]

On Sat, Dec 08, 2007 at 11:39:57AM +0100, Johannes Berg wrote:
> Hi Dave,
> 
> I just took a quick look at the parser, it looks pretty good. Andy has
> done something similar and was willing to relicense it under BSD last I
> asked him, his code is part of the Linux kernel right now:
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=net/wireless/radiotap.c;hb=HEAD

I will take a look at that.

> Small question on the code: why did you declare that radiotap_field is
> aligned? It can potentially come from anywhere unaligned, no?

I was trying to give the compiler a hint to help it generate better
code on architectures, such as ARM, where unaligned loads may take
many instructions.  Making the whole structure 64-bit aligned doesn't
sit very well with me.  I believe this is better,

union radiotap_field { 
        int8_t          f_i8[8];
        uint8_t         f_u8[8];
        uint16_t        f_u16[4];
        uint32_t        f_u32[2];
        uint64_t        f_u64;
        struct radiotap_xchan {
                uint32_t        xc_flags;
                uint16_t        xc_mhz;
                uint8_t         xc_chan;
                int8_t          xc_dbm;
        } f_xchan __attribute__((__packed__, __aligned__(4)));
        struct radiotap_chan {
                uint16_t        c_mhz; 
                uint16_t        c_flags;
        } f_chan __attribute__((__packed__, __aligned__(2)));
};
 
Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933 ext 24

Re: rfc: "canonical" radiotap parser

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 401 bytes --]


> I was trying to give the compiler a hint to help it generate better
> code on architectures, such as ARM, where unaligned loads may take
> many instructions.

Well, yes, but who guarantees that it actually *is* aligned that way?
Radiotap only specifies that the fields are aligned with respect to the
start of the header, but there's nothing that guarantees alignment of
that.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: rfc: "canonical" radiotap parser

[David Young]

On Mon, Dec 10, 2007 at 01:37:30PM +0100, Johannes Berg wrote:
> 
> > I was trying to give the compiler a hint to help it generate better
> > code on architectures, such as ARM, where unaligned loads may take
> > many instructions.
> 
> Well, yes, but who guarantees that it actually *is* aligned that way?
> Radiotap only specifies that the fields are aligned with respect to the
> start of the header, but there's nothing that guarantees alignment of
> that.

The caller of radiotap_parse_first() must supply a 64-bit aligned
ieee80211_radiotap_header in the first argument.  If the header is not
so aligned, then the parse fails right away with RADIOTAP_ERROR_ALIGNMENT.

Really, radiotap_parse_first() should require either 32-bit alignment,
or alignment as great as the maximum alignment of all of the fields that
are present, whichever is greater.

I copy radiotap headers to ensure 64-bit alignment in
main.c:cap_cb().

Dave

-- 
David Young             OJC Technologies
dyoung-eZodSLrBbDpBDgjK7y7TUQ@public.gmane.org      Urbana, IL * (217) 278-3933 ext 24

Re: rfc: "canonical" radiotap parser

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]


> The caller of radiotap_parse_first() must supply a 64-bit aligned
> ieee80211_radiotap_header in the first argument.  If the header is not
> so aligned, then the parse fails right away with RADIOTAP_ERROR_ALIGNMENT.

Ah. I missed that, sorry.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: rfc: "canonical" radiotap parser

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]


On Thu, 2007-12-06 at 22:55 -0600, David Young wrote:
> At <http://svn.cuwireless.net/svn/cuw/trunk/src/radiotap/> is the radiotap

Another thing, I think it has endianness issues. Have you tested on big
endian platforms?

        case IEEE80211_RADIOTAP_LOCK_QUALITY:
        case IEEE80211_RADIOTAP_TX_ATTENUATION:
        case IEEE80211_RADIOTAP_DB_TX_ATTENUATION:
                printf("%s %" PRIu16 " ", fi->fi_shortdesc,
f->f_u16[0]);
                break;

That looks like it should have a conversion.

Also, here's an ambiguity in the standard:

 * IEEE80211_RADIOTAP_FHSS              uint16_t        see below
 *
 *      For frequency-hopping radios, the hop set (first byte)
 *      and pattern (second byte).

first/second byte is not really defined, I think this should be defined
as 2x uint8_t.

FWIW, I'm working on per-field pages on the wiki.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]