On Mon, Dec 16, 2002 at 04:59:21PM -0800, Guy Harris wrote:
> On Mon, Dec 16, 2002 at 06:56:24PM -0600, David Young wrote:
> > 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.
>
> That might require some central registry for values for the T part of
> the TLV.
Won't Solomon will keep that? =)
>
> Note that there should still be a field at the beginning of the header
> giving the length of the header, so that, in order to find the 802.11
> header, one doesn't need a loop - machine code for most processors
> running libpcap-based applications can do loops, but BPF code can't.
Right. Also, since variable-length headers are difficult for
libpcap/tcpdump to deal with, implementations should probably
return radio headers with a suitably large, standard length until
variable-length headers are supported. A "null" LTV should fill unused
space in the radio header.
Dave
--
David Young OJC Technologies
[EMAIL PROTECTED] Engineering from the Right Brain
Urbana, IL * (217) 278-3933
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
