tcpdump mailing list archives

Re: capturing on both interfaces simultaneously


From: Guy Harris <guy () alum mit edu>
Date: Mon, 12 Dec 2011 13:10:44 -0800


On Dec 12, 2011, at 1:36 AM, abhinav narain wrote:

I can't find any default buffer size in pcap,

The default size is platform-dependent.  On Linux systems that support memory-mapped capture (in both the kernel, which 
your kernel does, and in libpcap, which libpcap 1.0 and later do), the default is 2 megabytes.

How can I know that it is goodenough when I am doing select

select() isn't very relevant here.  If you're capturing on more than one interface, there is the risk that if the 
application is busy processing packets from one interface it might drop packets from the other interface because it has 
no time to process them, but if that's the case, more buffering will help only if the traffic is bursty and your 
machine and software can handle the traffic at the average rate.

I'd use pcap_stats() to see whether you're dropping packets.

I am doing similar to tcpdump code to use 7.3.1.4 to detect ESS,IBSS,
PRIVACY bits on in beacon frame. The structure is in 2007 pdf.

Now, the 802.11n pdf describes the capabilty structure (2 bytes) with
totally different field !

7.3.2.56.2 show different format of Capabilities section.

Yes, it *is* a totally different field!

The field in 7.3.1.4 is not a information element, so it has a fixed position in each frame type, and has no tag or 
length field.

The filed in 7.3.2.56.2 is an information element, so it doesn't have a fixed position - it's in the sequence of 
information elements after the fixed-position fields - and it has a tag to identify it.

All beacon frames have the Capability Information field.  If the AP is an 802.11n-capable AP, its beacon frames will 
also have the HT Capability Information IE.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.


Current thread: