dyoung@pobox.com said:
> As I say, there are rules.  On any given radio, there are only two
> structs, one for tx, one for rx. 

Actually, the structs for ral/ural were broken, the 16-bit
"channel" stuff was misaligned.

> If ethereal really counts bytes, w/o considering alignment, then they
> seriously botched their implementation, and you should file a PR against
> ethereal.

I'm currently testing a patch which fixes the alignment
problems.
There is still the FCS problem, and the dissector displays
nonsense for other fields (eg "preamble" and "channel type"),
but at least it can distinguish the header fields now.

> I am going to check in some changes to the manual page shortly

Imho it is still not obvious that each element of the radiotap
header needs to be aligned at its individual natural boundary.
And if you explicitely recommend to use "packed" structures you
should state that padding bytes need to be inserted manually.
(FreeBSD's ral/ural driver doesn't use packed structures, that's
why the alignment problem didn't strike there appearently.)
I also wouldn't use the term "suitable alignment" -- this has
to be struct, after all capture files should be machine independant.

> In sum, I am not convinced that there is a design flaw in radiotap.
> The documentation may not be true to my intent.

As said, some fixed fields to locate the inner ieee802_11 frame
without parsing would be nice, but it is too late anyway.
Now that it is clarified how the alignment is supposed to
work I can live with it. (But if both the driver and ethereal
are wrong, just tcpdump is right, this looks much like a
documentation problem.)

best regards
Matthias