When you talk about 15% RAM, do you actually mean working set or virtual address space? Which version of linux are you using?
Regarding 802.11a/b/g/n, you cannot rely much on the radiotap header of a beacon frame. The radiotap header will only tell you which band was the packet transmitted on (so "a" frequencies or "b/g" frequencies). In 99.9% of the cases, beacons are transmitted at the lowest rate possible in that specific band, so 1Mbps for "b/g" band and 6Mbps for the "a" band. You need to parse the beacon packet and understand which speeds are supported by the AP to distinguish between a,b,g and n. On the "n" topic, remember that 802.11n can work on both the "a" band and the "b/g" band. It's just a new set of modulations that can be used for both bands. Hope it helps GV -----Original Message----- From: tcpdump-workers-ow...@lists.tcpdump.org [mailto:tcpdump-workers-ow...@lists.tcpdump.org] On Behalf Of abhinav narain Sent: Sunday, December 11, 2011 4:11 PM To: tcpdump-workers@lists.tcpdump.org Subject: Re: [tcpdump-workers] capturing on both interfaces simultaneously > It sniffs for beacons by using bpf filter and keeps a per AP record of > > packet count etc in a table. > > So if that's all you're doing, you presumably don't have your own > buffer for packets; when you say "I already have 15% RAM being eaten > by the program, so I can't actually increase the buffer size to save > packets in between select switches.", are you referring to the buffer > in libpcap itself, as specified by pcap_set_buffer_size()? > > Yes, I havent user the pcap_set_buffer_size(), but in open_live() , i > give the buffersize as BUFSIZ, > > Is poll() better than select ? > > If you only have two file descriptors on which you're selecting, a > poll() call probably involves less copying of data into and out of the > kernel than a select() call. If you're only going to run this code on > Linux, an > epoll() call will involve even less copying of data into and out of > the kernel, as it keeps the set-of-file-descriptors in the kernel, so > it doesn't have to be copied in on every "wait for an event" call. > > I will look into how to use it then. > > I can only see A,B,G in beacons in tcpdump code, reading the > > radiotap header.. > > How can I infer an AP is N ? > > What do you mean by "reading the radiotap header"? > > I mean I capturing the radiotap header and and parsing it. > One way to identify a beacon frame from an 802.11n-capable AP is to > look for the HT Capabilities Info field; see "7.3.2.56.2 HT > Capabilities Info field" in the 802.11 spec. > Is this is information in the radiotap header or the mac header ? I looked at wireshark code which is the only tool i came across giving some information on N protocol, but its code is more complicated than pcap,tcpdump,kismet,horst i went through before. Is there any other tool i can see how to code it. A beacon frame is an announcement of the existence of, and capabilities of, > an AP; I say "802.11n-capable AP" rather than "802.11n AP" because an > 802.11n-capable AP may well support stations that use 802.11b or > 802.11g, so the only reason for an AP to send beacons as other than > 802.11b packets would be if it were incapable of supporting 802.11b > stations. I just now ran a capture on my machine, and the beacons > from our 802.11n-capable AP are, according to the radiotap header, > sent at a data rate of 1Mb/s, so, by reading the radiotap header, > there's no indication that the AP is 802.11n-capable; however, if you > look at the tagged parameters in the beacon frame, you see the HT > Capabilities information element. > I am parsing till the 31st bit on radiotap header bitmap. Any code base where I can see how they do it ? Abhinav - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
