Date: Tue, 30 Aug 2005 12:17:01 -0500 From: Sam Pierson <samuel.pierson@gmail.com> To: Sam Leffler <sam@errno.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Atheros driver and radiotap reliability Message-ID: <d9204e4c05083010171fa6cfc9@mail.gmail.com> In-Reply-To: <4313A2EC.5070300@errno.com> References: <d9204e4c050829120713734e3d@mail.gmail.com> <4313A2EC.5070300@errno.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8/29/05, Sam Leffler <sam@errno.com> wrote: > Sam Pierson wrote: > >I had some correspondence with the ethereal developers and David Young > > and apparently there is a bug in how ethereal handles the radiotap header. > > News to me; the last time I checked it looked correct. I'm not sure. David told me this: FYI, ethereal's radiotap dissector was broken the last time I checked. :-( It does not obey the alignment rules for radiotap fields: the radiotap producer (usually, the kernel) inserts zeroes to ensure natural alignment of all multi-byte fields. Ethereal does not account for this. The tcpdump sources get this right. > The radiotap header includes the rssi returned by the hardware for rx'd > frames. > sc->sc_rx_th.wr_antsignal = ds->ds_rxstat.rs_rssi; I get (slightly) different values for the RSSI displayed in ethereal (if it's correctly being displayed, still looking) than the SS displayed in dB by tcpdump. Is the SSI displayed by ethereal the sc->sc_rx_th.wr_antsignal being passed through? > Nothing is recorded for tx frames. You can typically treat it as being > in .5dBm units relative to the current noise floor. *it*, referring to the rssi value above? Thanks for the help, Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d9204e4c05083010171fa6cfc9>