On Mon, Dec 16, 2002 at 06:56:24PM -0600, David Young wrote: > Sounds like hosttime is redundant.
Quite possibly, but it seemed like a good idea at the time. > Hmm. Seems like mactime should be some suitably high-resolution unit > for 802.11, such as 10ns or 1ns, or else a second header in the radio > header should tell the units. The point of DLT_IEEE802_11_RADIO is to > smooth over hardware differences. it would be at least microsecond-accurate, but beyond that. > (For some applications, it may be handy to know which frame feature > the mactime indicates. E.g., whether it is the start of the PLCP or MAC > header, or the end of frame.) Hmm. I don't recall seeing this in any of the hardware docs I'm privvy to, but it's certianly an interesting thought. > BTW, I keep thinking of reasons to adopt length-type-value tuples for > the radio header. There are three, so far. First, records such as RSSI > are meaningless for transmitted frames, so they may as well be omitted. > Second, certain records are not supported by certain hardware. Third, > the radio header is likely to change fast: one may desire to adopt a > new device driver without breaking compatibility with your tcpdump. > With LTVs, your tcpdump may skip records whose type it does not know. No, the old DLT_IEEE80211_PRISM type did that; whet you end up with is a header twice as long that can't be parsed or constructed as easily and quickly. - Solomon -- Solomon Peachy [EMAIL PROTECTED] AbsoluteValue Systems http://www.linux-wlan.com 715-D North Drive +1 (321) 259-0737 (office) Melbourne, FL 32934 +1 (321) 259-0286 (fax)
msg02105/pgp00000.pgp
Description: PGP signature
