s == s Correia Lu writes:
s Indeed I've seen a radiotap_iterator function in radiotap headers. But
the
s function logic was a little heavy for a 400mhz MIPS CPU. No?
well, you could, rather than interpret the flag bits each time, write a
generic decode routine, and then for each known
On Apr 28, 2013 6:23 AM, Denis Ovsienko infrastat...@yandex.ru 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:
On Apr 27, 2013 11:59 PM, Guy Harris g...@alum.mit.edu wrote:
On Apr 27, 2013, at 3:26 PM, Luis Correia lfpcorr...@gmail.com 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
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 28, 2013, at 8:54 AM, Luís Correia lfpcorr...@gmail.com 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*,
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
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; /*
On Apr 28, 2013, at 4:24 PM, Guy Harris g...@alum.mit.edu 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
On Apr 28, 2013, at 5:46 PM, Guy Harris g...@alum.mit.edu 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*.
Hi Harris, thnks for your help.
On Apr 27, 2013, at 2:03 AM, Guy Harris g...@alum.mit.edu wrote:
On Apr 26, 2013, at 11:50 AM, Luis Correia lfpcorr...@gmail.com wrote:
I check for link type this way:
(pcap_datalink(dev_handler) ==DLT_IEEE802_11) ,
So i'm pretty sure its the right data
On Apr 27, 2013, at 3:26 PM, Luis Correia lfpcorr...@gmail.com 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 and redefining my struct's fields.
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/303
There are patches attached there that may come handy.
--
Hi Michael, thnks for replying.
I check for link type this way:
(pcap_datalink(dev_handler) == DLT_IEEE802_11) ,
So i'm pretty sure its the right data link. Unless pcap_datalink() is broken..
Meanwhile I've media some progress by looking at iwcap
On Apr 26, 2013, at 11:50 AM, Luis Correia lfpcorr...@gmail.com wrote:
I check for link type this way:
(pcap_datalink(dev_handler) ==DLT_IEEE802_11) ,
So i'm pretty sure its the right data link.
DLT_IEEE802_11 is the *wrong* data link if you're getting a radiotap header in
your packets, as
14 matches
Mail list logo
