On Apr 28, 2013, at 5:46 PM, Guy Harris wrote:
> Oops, that should be
>
> rssi = *(int8_t *)p;
>
> so that the byte is sign-extended.
...but do *NOT* make that change to the RADIOTAP_DB_ANTENNA_SIGNAL case, as
*that* value is *unsigned*.
On Apr 28, 2013, at 4:24 PM, Guy Harris wrote:
> if (IS_PRESENT(RADIOTAP_ANTENNA_SIGNAL)) {
> /* 1-bit value */
> /*
>* This is a *SIGNED* value, so it could be positive or
> negative.
>* If you want a value guaranteed to be posi
And you can probably unroll the iteration loop into something such as
/* use appropriate 8-bit/16-bit/32-bit unsigned types here */
struct ieee80211_radiotap_header {
u_int8_tit_version; /* set to 0 */
u_int8_tit_pad;
u_int16_t it_len; /* e
Some drivers definitely change the format of the radiotap packets on the fly in
the same stream. As Guy says, you need to look at the bit field in the header
and parse the complex header. If all you care about is the dot11 header you can
just skip the header using the length field.
Also beware
On Apr 28, 2013, at 8:54 AM, Luís Correia wrote:
> Indeed I've seen a radiotap_iterator function in radiotap headers. But the
> function "logic" was a little heavy for a 400mhz MIPS CPU. No?
Maybe *that* iteration logic is heavy, but some iteration logic is a
*requirement*, unless:
y
> Hi Denis.
>
> In deed I've seen different output from the same code. As if the field's
> position change upon different power runs. For example, one time I
> successfuly got packet type, subtype and rssi values coherent with distance.
> Some other run of the same code, but I'd power cycled the
On Apr 27, 2013 11:59 PM, "Guy Harris" wrote:
>
>
> On Apr 27, 2013, at 3:26 PM, Luis Correia wrote:
>
> > Im getting DLT_IEEE802_11_RADIO. Is this ok?
>
> Yes. That means you have a Radiotap header.
>
> > About the rssi values I managed to get them by teaching myself little
endian vs big endian
On Apr 28, 2013 6:23 AM, "Denis Ovsienko" wrote:
>
> > Im getting DLT_IEEE802_11_RADIO. Is this ok?
>
> Hello.
>
> This issue with DLT_IEEE802_11_RADIO and the frame being offset by 4
octets may have something in common with another issue:
>
> https://github.com/the-tcpdump-group/tcpdump/issues/30
