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 head= er. >=20 > 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 =3D ds->ds_rxstat.rs_r= ssi; I get (slightly) different values for the RSSI displayed in ethereal (if it= 's=20 correctly being displayed, still looking) than the SS displayed in dB by=20 tcpdump. Is the SSI displayed by ethereal the sc->sc_rx_th.wr_antsignal being passed through? =20 =20 > Nothing is recorded for tx frames. You can typically treat it as being > in .5dBm units relative to the current noise floor. =20 *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>