Re: [tcpdump-workers] Missing packet fields in big endian with ath9k
Hi Harris, thnks for your help. On Apr 27, 2013, at 2:03 AM, Guy Harris wrote: > > On Apr 26, 2013, at 11:50 AM, Luis Correia 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 you seem to indicate below! If you're getting a radiotap > header, and pcap_datalink(dev_handler) == DLT_IEEE802_11, the driver for your > network adapter is buggy - it's returning ARPHRD_IEEE80211 when it should be > returning ARPHRD_IEEE80211_RADIOTAP. Im getting DLT_IEEE802_11_RADIO. Is this ok? > >> Meanwhile I've media some progress by looking at iwcap >> (https://dev.openwrt.org/browser/trunk/package/iwcap/src/iwcap.c?rev=30747) > > What happens if you try to run iwcap on that interface? I'll run iwcap to see what happens. > >> However I still can't access the RSSI value of the packet.. About the rssi values I managed to get them by teaching myself little endian vs big endian and redefining my struct's fields. I'm now getting correct rssi values almost every time. (Negative, distance coherent..) However sometimes I see packets with positive values!! I'm debugging that.. PS: If I'm not mistaken aren't you the guy that wrote libpcap?! If so, Congrats on you're work! > > If you're getting packets without a radio header (which is what > DLT_IEEE802_11 would imply), there's no place to get the RSSI from. > > If you're getting packets with a radiotap header (which is what > DLT_IEEE802_11_RADIO would imply), the only way to get the RSSI is if the > driver is violating the radiotap spec, because the only mention of RSSI at > > http://www.radiotap.org > > is > > http://www.radiotap.org/suggested-fields/RSSI > > and, as they say, the presence-bit value picked by OpenBSD clashes with an > officially assigned value for a different field. > > You might, however, be able to get signal and noise levels, *if* the driver > supplies them (just because a given value *can* be supplied in a radiotap > header doesn't mean that a given driver *will* supply it): > > http://www.radiotap.org/defined-fields/Antenna%20signal > > http://www.radiotap.org/defined-fields/Antenna%20noise > > http://www.radiotap.org/defined-fields/dB%20antenna%20signal > > http://www.radiotap.org/defined-fields/dB%20antenna%20noise ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Missing packet fields in big endian with ath9k
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 and redefining my struct's fields. > > I'm now getting correct rssi values almost every time. (Negative, distance > coherent..) Note that, as I said, unless you're running on OpenBSD, what you're getting is either "RF signal power at the antenna" as "a single signed 8-bit value, which indicates the RF signal power at the antenna, in decibels difference from 1mW": http://www.radiotap.org/defined-fields/Antenna%20signal or "RF signal power at the antenna, decibel difference from an arbitrary, fixed reference" as "a single unsigned 8-bit value": http://www.radiotap.org/defined-fields/dB%20antenna%20signal Note also that parsing radiotap headers should not be done by assuming the radiotap header is a fixed-format structure; all values in a radiotap header are optional, so you should scan through the "presence bits" looking for one of the two "antenna signal" values and, *depending on which one you find*, treating it as "signed dB from 1mW" or "unsigned dB from some unspecified reference point". > However sometimes I see packets with positive values!! If it's dBm (decibels from 1 mW) the value is signed, which could be positive (meaning "stronger than 1mW"). If it's dB from an arbitrary fixed reference point, the value is unsigned, which is *always* positive. > PS: If I'm not mistaken aren't you the guy that wrote libpcap?! You're mistaken. It was written by Steve McCanne and Van Jacobson: http://sharkfest.wireshark.org/sharkfest.11/presentations/McCanne-Sharkfest'11_Keynote_Address.pdf I've been a significant contributor, but that's just building upon a strong base they created. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Missing packet fields in big endian with ath9k
> 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. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
