CODEWITHSUNDEEP
clinuxlibpcaptcpdumpwifi
Lee Hambley
Lee Hambley

Reputation: 6370

libpcap Radiotap header extraction

I've got some code that is using the functions ieee80211_radiotap_iterator_init() and ieee80211_radiotap_iterator_next() from radiotap-parser.c,

I'm not sure what I'm doing incorrectly, perhaps someone can educate me? I'm using the sample code from the documentation more or less without modification, it fits very well to what I was trying to achieve:

/* where packet is `const u_char *packet' */
struct ieee80211_radiotap_iterator rti;
struct ieee80211_radiotap_header *rth = ( struct ieee80211_radiotap_header * ) packet;

/* 802.11 frame starts here */
struct wi_frame *fr= ( struct wi_frame * ) ( packet + rth->it_len );

/* Set up the iteration */
int ret = ieee80211_radiotap_iterator_init(&rti, rth, rth->it_len);

/* Loop until we've consumed all the fields */
while(!ret) {
  printf("Itteration: %d\n", count++);
  ret = ieee80211_radiotap_iterator_next(&rti);
  if(ret) {
    /*
     * The problem is here, I'm dropping into this clause with 
     * a value of `1` consistently, that doesn't match my platform's
     * definition of EINVAL or ENOENT.
     */
    continue;
  }
  switch(rti.this_arg_index) {
  default:
    printf("Constant: %d\n", *rti.this_arg);
    break;
  }
}

There's limited scope for having screwed something up in that code, I think, I'm confused by the 1 being returned from ieee80211_radiotap_iterator_next() which according to the implenentation doesn't seem like an error condition in the implementation.

I'm filtering for packets of type "(type mgt) and (not type mgt subtype beacon)", and I'm not even certain if libpcap will include these attributes when the data link is set to DLT_IEEE802_11_RADIO?

Upvotes: 0

Views: 4025

Answers (1)

user862787
user862787

Reputation:

First:

I'm filtering for packets of type "(type mgt) and (not type mgt subtype beacon)", and I'm not even certain if libpcap will include these attributes when the data link is set to DLT_IEEE802_11_RADIO?

It will. The filter code generated for DLT_IEEE802_11_RADIO fetches the radiotap header length and skips the radiotap header, so it'll just skip the radiotap header and check the 802.11 header following it.

Second:

the implementation

You linked to two different implementations of ieee80211_radiotap_iterator_next() - the one at radiotap-parser.c, in which ieee80211_radiotap_iterator_next() returns the "next present arg index" on success, and the one from the Linux kernel, in which ieee80211_radiotap_iterator_next() returns 0 on success. If the radiotap iterator code you're using is the one at radiotap-parser.c, pay no attention whatsoever to the one from the Linux kernel, as it doesn't behave the way the one you're using behaves.

Upvotes: 1

Related Questions