Re: [tcpdump-workers] why libpcap cannot capture outbound 802.11 beacons?
Could you explain what do you mean by outbound beacons ? I have been able to capture beacons using libpcap. Am I missing on something ? Abhinav On Mon, Oct 31, 2011 at 3:27 PM, Yifan Zhang wrote: > > Hello all, > > I am writing my own program, which will be running on a 802.11 AP, to > capture all the outgoing beacons on the AP. But I just noticed I cannot do > it with the current libpcap: the program couldn't capture any outbound > beacons. I've also tried Wireshark which gave the same result. > > My questions are: > 1. Can anyone shed some lights on the causes of what I saw? > 2. Is there any user space method that I can capture the outbound beacons > of a 802.11 AP on that specific AP (rather than capturing on other PCs)? It > is better for me if I can do this without hacking into the wireless driver. > > Thanks, folks. > > -ivan > - > 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.
[tcpdump-workers] capturing on both interfaces simultaneously
hi, I am using libpcap on Openwrt platform, Netgear router wndr3700v2. I am able to capture packets on phy0, interface. But what should I do to capture packets on phy0,phy1 simultaneously in the same program ? I don't think I can use "any" interface as it might capture packets from bridge interface also ! Kindly suggest. Abhinav - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] listening 80211 n beacons
hi, I have been running tcpdump on my laptop and openwrt router (netgear). I have used the command : iw phy phy1 set channel 40 ht40+/ht40-/ht20 But I have not been able to hear n beacons. Is it that tcpdump can't decipher n beacons ? I went through code and saw PRINT_HT_RATES and ieee80211_htrates[] are defined. Though in the function print_chaninfo, there are only, a,b ,g taken care of ? How can I get to know a beacon is of n protocol ? Abhinav - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
I was using pthreads for two interfaces, but I am trying to optimize now. I have 15% memory usage. I am trying to use select, as it seems the most basic. Junkie uses threads to do this, so can't really use it. I want to sniff only beacons in the network, so I am attaching a bpf filter on the handle Can I use pcap_loop when using select, or i have to use recvfrom in loop ? Abhinav On Wed, Nov 30, 2011 at 10:25 AM, wrote: > On Wed, Nov 30, 2011 at 01:06:19PM +0100, Joerg Mayer wrote: > > On Mon, Nov 28, 2011 at 02:35:24PM -0500, abhinav narain wrote: > > > I am using libpcap on Openwrt platform, Netgear router wndr3700v2. > > > I am able to capture packets on phy0, interface. > > > But what should I do to capture packets on phy0,phy1 simultaneously in > the > > > same program ? > > > > > > I don't think I can use "any" interface as it might capture packets > from > > > bridge interface also ! > > > > The current *development* tree of Wireshark supports simultanous capture > > on several interfaces and this includes the text version tshark. AFAIK, > > tcpdump does not support this - but you may alway start tcpdump multiple > > times, once for each interface and later merge the capture files. > > > > Kismet does this as well, if you're in the wireless space. > > But yeah - mergecap is your friend otherwise, it's application level > logic to capture from multiple sources. > > -m > > > Ciao > > Joerg > > -- > > Joerg Mayer > > We are stuck with technology when what we really want is just stuff that > > works. Some say that should read Microsoft instead of technology. > > - > > 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.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
On Sat, Dec 10, 2011 at 3:18 PM, wrote: > Hi! > > > I was using pthreads for two interfaces, but I am trying to optimize > now. I > > have 15% memory usage. > > So you were capturing traffic on two threads with two distinct pcap > handlers? > yes > Looks fine to me. What's eating 15% of your RAM, exactly? > I think pthread while keeping the states > > > I am trying to use select, as it seems the most basic. > > If I understand correctly, you are replacing your threaded aproach by a > singly > threaded program using select. Unfortunately, I don't know any way to > associate a file descriptor with a pcap handle portably. :-( > > > Junkie uses threads to do this, so can't really use it. > > Yes junkie uses one thread per interface. The reason behind this is that > I use > it to perform a lot of process for every packet so using threads on many > interfaces offer as much parallelism as necessary (even when you are > interested > in only one device you can still scatter its traffic through several > handlers > by proper filtering). > > > Can I use pcap_loop when using select, or i have to use recvfrom in loop > ? > > I think you will be forced into recvfrom, which is not as portable as plain > libpcap so from my very limited knowledge I would recommend against it. > > - > 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.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
So, I can do select + pcap_dispatch to read on two interfaces without even using threads. I read select is slow for monitoring. But with only two interfaces, it should not be a problem. Abhinav On Sat, Dec 10, 2011 at 3:50 PM, Guy Harris wrote: > > On Dec 10, 2011, at 7:39 AM, abhinav narain wrote: > > > Can I use pcap_loop when using select, > > No. > > You can, however, use pcap_dispatch(). pcap_loop() loops either > indefinitely or until it sees the specified number of packets; it will try > to read more packets from the underlying descriptor, and thus potentially > block. pcap_dispatch() will read more packets from the descriptor at most > once, so it's more appropriate to call if select() or poll() reports the > selectable descriptor for a pcap_t as having packets available. Pass it a > "cnt" argument of -1, so it processes all the packets in the batch that it > reads, and thus does a read at the beginning of each call.- > 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.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
Two threads are too large on this.
I was unable to find how to set the set of interfaces to be restricted to 2
(the ones i want) and call the same callback on return from dispatch.
This code is not right, but I am clueless to proceed
Any direction will be good.
fd_set rfds;
char * device="phy0";
char * device1="phy1";
handle1 = pcap_open_live(device, BUFSIZ, 1, 0, errbuf);
handle2 = pcap_open_live(device1, BUFSIZ, 1, 0, errbuf);
fd = pcap_get_selectable_fd(handle1);
pcap_compile(handle1, &fcode, "type mgt subtype beacon", 1, 0);
pcap_setfilter(handle1, &fcode);
/*
fd = pcap_get_selectable_fd(handle2);
pcap_compile(handle2, &fcode, "type mgt subtype beacon", 1, 0);
pcap_setfilter(handle2, &fcode);
*/
while (retval == 0) {
FD_ZERO(&rfds);
FD_SET(fd, &rfds);
tv.tv_sec = 1; /* timeout 1 sec */
tv.tv_usec = 0;
retval = select(fd + 1, &rfds, NULL, NULL, &tv);
if(pcap_dispatch(handle1,-1,callback1,(u_char *)NULL) < 0 ){
printf("error");
}
if(pcap_dispatch(handle2, -1,callback1,(u_char *)NULL) < 0 ){
printf("error");
}
}
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
Actually, I did better now ... but I don't know what should be done to call
the corresponding dispatch
If someone can give me a hint
char *device0="phy0";
char *device1="phy1";
pcap0 = pcap_open_live(device0, BUFSIZ, 1, -1, errbuf);
pcap1 = pcap_open_live(device1, BUFSIZ, 1, -1, errbuf);
for(;;)
{
/* If you include STDIN_FILENO, be sure to read from it when you get
traffic from it, or select will return every time it is called,
since there will still be traffic waiting there.
*/
FD_ZERO(&fd_wait);
//FD_SET(STDIN_FILENO, &fd_wait);
FD_SET(pcap_fileno(pcap0), &fd_wait);
FD_SET(pcap_fileno(pcap1), &fd_wait);
st.tv_sec = 1;
st.tv_usec = 0; /* 1000 = 1 second */
t=select(FD_SETSIZE, &fd_wait, NULL, NULL, &st);
printf("t is %d\n",t);
switch(t)
{
case -1: /* Something went really wrong */
printf("Argh!\n\n");
exit(1);
case 0: /* We timed out, no trafffic */
printf( " Time out ! \n");
break;
default: /* We got traffic */
pcap_dispatch(pcap0,-1, (void *) packet_callback, NULL);
pcap_dispatch(pcap1,-1, (void *) packet_callback2, NULL);
}
// Put your service routine here.. is called when select times out or
when a packet is processed
}
On Sat, Dec 10, 2011 at 7:12 PM, abhinav narain
wrote:
> Two threads are too large on this.
>
> I was unable to find how to set the set of interfaces to be restricted to
> 2 (the ones i want) and call the same callback on return from dispatch.
>
> This code is not right, but I am clueless to proceed
>
> Any direction will be good.
>
> fd_set rfds;
> char * device="phy0";
> char * device1="phy1";
> handle1 = pcap_open_live(device, BUFSIZ, 1, 0, errbuf);
> handle2 = pcap_open_live(device1, BUFSIZ, 1, 0, errbuf);
>
> fd = pcap_get_selectable_fd(handle1);
> pcap_compile(handle1, &fcode, "type mgt subtype beacon", 1, 0);
> pcap_setfilter(handle1, &fcode);
>
> /*
>
>
> fd = pcap_get_selectable_fd(handle2);
>
>
> pcap_compile(handle2, &fcode, "type mgt subtype beacon", 1, 0);
>
>
> pcap_setfilter(handle2, &fcode);
>
>
> */
>
> while (retval == 0) {
> FD_ZERO(&rfds);
> FD_SET(fd, &rfds);
> tv.tv_sec = 1; /* timeout 1 sec */
> tv.tv_usec = 0;
> retval = select(fd + 1, &rfds, NULL, NULL, &tv);
>
> if(pcap_dispatch(handle1,-1,callback1,(u_char *)NULL) < 0 ){
> printf("error");
> }
> if(pcap_dispatch(handle2, -1,callback1,(u_char *)NULL) < 0 ){
> printf("error");
> }
>
> }
>
>
>
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
I got it to work.
Thanks for replying on the thread
Abhinav
On Sat, Dec 10, 2011 at 8:15 PM, abhinav narain
wrote:
> Actually, I did better now ... but I don't know what should be done to
> call the corresponding dispatch
> If someone can give me a hint
>
>
> char *device0="phy0";
> char *device1="phy1";
> pcap0 = pcap_open_live(device0, BUFSIZ, 1, -1, errbuf);
> pcap1 = pcap_open_live(device1, BUFSIZ, 1, -1, errbuf);
>
> for(;;)
>{
>
>/* If you include STDIN_FILENO, be sure to read from it when you get
> traffic from it, or select will return every time it is called,
> since there will still be traffic waiting there.
>*/
>
>FD_ZERO(&fd_wait);
>//FD_SET(STDIN_FILENO, &fd_wait);
>FD_SET(pcap_fileno(pcap0), &fd_wait);
>FD_SET(pcap_fileno(pcap1), &fd_wait);
>
>st.tv_sec = 1;
>st.tv_usec = 0; /* 1000 = 1 second */
>
>t=select(FD_SETSIZE, &fd_wait, NULL, NULL, &st);
>printf("t is %d\n",t);
>switch(t)
> {
> case -1: /* Something went really wrong */
>printf("Argh!\n\n");
>exit(1);
>
> case 0: /* We timed out, no trafffic */
>printf( " Time out ! \n");
>break;
>
> default: /* We got traffic */
>pcap_dispatch(pcap0,-1, (void *) packet_callback, NULL);
>pcap_dispatch(pcap1,-1, (void *) packet_callback2, NULL);
> }
>// Put your service routine here.. is called when select times out or
> when a packet is processed
>}
>
>
>
>
>
> On Sat, Dec 10, 2011 at 7:12 PM, abhinav narain > wrote:
>
>> Two threads are too large on this.
>>
>> I was unable to find how to set the set of interfaces to be restricted to
>> 2 (the ones i want) and call the same callback on return from dispatch.
>>
>> This code is not right, but I am clueless to proceed
>>
>> Any direction will be good.
>>
>> fd_set rfds;
>> char * device="phy0";
>> char * device1="phy1";
>> handle1 = pcap_open_live(device, BUFSIZ, 1, 0, errbuf);
>> handle2 = pcap_open_live(device1, BUFSIZ, 1, 0, errbuf);
>>
>> fd = pcap_get_selectable_fd(handle1);
>> pcap_compile(handle1, &fcode, "type mgt subtype beacon", 1, 0);
>> pcap_setfilter(handle1, &fcode);
>>
>> /*
>>
>>
>> fd = pcap_get_selectable_fd(handle2);
>>
>>
>> pcap_compile(handle2, &fcode, "type mgt subtype beacon", 1, 0);
>>
>>
>> pcap_setfilter(handle2, &fcode);
>>
>>
>> */
>>
>> while (retval == 0) {
>> FD_ZERO(&rfds);
>> FD_SET(fd, &rfds);
>> tv.tv_sec = 1; /* timeout 1 sec */
>> tv.tv_usec = 0;
>> retval = select(fd + 1, &rfds, NULL, NULL, &tv);
>>
>> if(pcap_dispatch(handle1,-1,callback1,(u_char *)NULL) < 0 ){
>> printf("error");
>> }
>> if(pcap_dispatch(handle2, -1,callback1,(u_char *)NULL) < 0 ){
>> printf("error");
>> }
>>
>> }
>>
>>
>>
>
>
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
I used the FD_IFSET() way to fnd out the descriptor.
I have an issue,
For few time dispatch works fine, but after I write the stats to a file,
and the loop returns to phy0, the programs quits with switch condition of
-1.
I don't see why ? I have the pcap{0,1} to non blocking. But this does not
work after sometime and I have an error displayed
: Interrupted system call
Abhinav
On Sun, Dec 11, 2011 at 3:21 AM, Guy Harris wrote:
>
> On Dec 10, 2011, at 11:58 PM, Cedric Cellier wrote:
>
> >> I got it to work.
> > (...)
> >>> default: /* We got traffic */
> >>> pcap_dispatch(pcap0,-1, (void *) packet_callback, NULL);
> >>> pcap_dispatch(pcap1,-1, (void *) packet_callback2, NULL);
> >
> > So that other may benefit from it in the future, I
> > guess your fixed version looks like:
> >
> > default:
> > if (t==pcap0) pcap_dispatch(pcap0,...)
> > else if (t==pcap1) pcap_dispatch(pcap1,...)
>
> I would not guess that, because select() returns a count of the number of
> descriptors that are ready to read - it does not return one of the
> descriptors that are ready to read - and because pcap0 and pcap1 are
> pointers to pcap_t structures, not descriptors.
>
> The right way to do this is
>
> pcap0 = pcap_open_live(device0, BUFSIZ, 1, -1, errbuf);
> if (pcap0 == NULL)
>/* report failure */
> pcap1 = pcap_open_live(device1, BUFSIZ, 1, -1, errbuf);
> if (pcap1 == NULL)
>/* report failure */
> /*
> * If this is being built with a version of libpcap that doesn't
> * include pcap_get_selectable_fd(), use pcap_fileno(), but be
> * prepared to be surprised if the devices don't happen to be
> * selectable or if you're running on Windows.
> */
> pcapfd0 = pcap_get_selectable_fd(pcap0);
> if (pcapfd0 == -1)
>/* fail with an indication that you can't select on device0 */
> pcapfd1 = pcap_get_selectable_fd(pcap1);
> if (pcapfd1 == -1)
>/* fail with an indication that you can't select on device1 */
>
> for(;;)
>{
>
>/* If you include STDIN_FILENO, be sure to read from it when you get
> traffic from it, or select will return every time it is called,
> since there will still be traffic waiting there.
>*/
>
>FD_ZERO(&fd_wait);
>//FD_SET(STDIN_FILENO, &fd_wait);
> FD_SET(pcapfd0, &fd_wait);
>FD_SET(pcapfd1, &fd_wait);
>
>st.tv_sec = 1;
>st.tv_usec = 0; /* 1000 = 1 second */
>
>t=select(FD_SETSIZE, &fd_wait, NULL, NULL, &st);
>printf("t is %d\n",t);
>switch(t)
> {
> case -1: /* Something went really wrong */
> printf("select failed: %s\n", strerror(errno));
> exit(1);
>
> case 0: /* We timed out, no trafffic */
>printf( " Time out ! \n");
>break;
>
> default: /* We got traffic */
> //if (FD_ISSET(STDIN_FILENO, &fd_wait))
>// process information from the standard input
>if (FD_ISSET(pcapfd0, &fd_wait))
> {
> if (pcap_dispatch(pcap0,-1, (void *) packet_callback, NULL) == -1)
>/* report an error processing packets from device0 */
> }
>if (FD_ISSET(pcapfd1, &fd_wait))
> {
> if (pcap_dispatch(pcap1,-1, (void *) packet_callback2, NULL) ==
> -1)
>/* report an error processing packets from device0 */
> }
> }
>}
> -
> 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.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
the return value of error is -1, EINTR is 4. Also, it keeps printing ": Resource temporarily unavailable" though I don't have any error statement to be printed. This is increasing CPU usage Abhinav On Sun, Dec 11, 2011 at 7:48 AM, wrote: > I did not remember what select() uses to return the readable file > descriptors, but I do remember that any select can be interrupted > while still waiting, and that the error is then EINTR, so you have > to catch this particular error and ignore it (ie. merely loop on > it). > Googling for "non-restartable system call" may provide you with more > detail. > - > 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.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
I just ignored that case of return value -1 : and continued. It works now. The memory usage for two captures is 15%. I think I din't gain much using select() ! Abhinav On Sun, Dec 11, 2011 at 12:09 PM, wrote: > -[ Sun, Dec 11, 2011 at 11:36:14AM -0500, abhinav narain ] > > the return value of error is -1, > > EINTR is 4. > > errno is EINTR. > If select returns -1, check for errno. If errno == EINTR, just retry. > > - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
RETURN VALUES > Select() returns the number of ready descriptors that are contained in > the descriptor sets, or -1 if an error occurred. If the time limit > expires, select() returns 0. If select() returns with an error, > includ- > ing one due to an interrupted call, the descriptor sets will be unmodi- > fied and the global variable errno will be set to indicate the error. > > so it's one of those APIs. > > What you should do is to, if select() returns -1 *and* errno is EINTR, > just ignore the error and continue looping. > > Ya, I did that in the morning ... it works now. > > Also, it keeps printing ": Resource temporarily unavailable" > > though I don't have any error statement to be printed. > > What is "it"? Your program? Or just *some* program? > Its the return statement of perror. I removed it. It works fine now. But how do I know, how much packets is my program dropping? using pcap_stats ? 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. Abhinav - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
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. Is poll() better than select ? I can only see A,B,G in beacons in tcpdump code, reading the radiotap header.. How can I infer an AP is N ? On Sun, Dec 11, 2011 at 2:35 PM, Guy Harris wrote: > > On Dec 11, 2011, at 11:17 AM, abhinav narain wrote: > > >> What is "it"? Your program? Or just *some* program? > >> > > Its the return statement of perror. > > Presumably you were calling perror() because some call returned -1; what > call was that? If something keeps returning -1 because, for example, it's > a read from a non-blocking file descriptor on which no data is available to > read, your program is going to be chewing up CPU looping. > > > It works fine now. > > But how do I know, how much packets is my program dropping? > > using pcap_stats ? > > Yes. > > > 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. > > What is your program doing with the packets when it captures them?- > 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.
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.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
On Sun, Dec 11, 2011 at 9:04 PM, Gianluca Varenni < gianluca.vare...@riverbed.com> wrote: > When you talk about 15% RAM, do you actually mean working set or virtual > address space? Which version of linux are you using? > > I am using Openwrt on a Netgear router. Kernel 2.6.39 I see this usage by top command. VSZ reports 9304 Bytes.I think this must be virtual address space. I am not sure how to find the exact memory used by my code and by pcap/libz library i am 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. Ok. The point is I can know only the fact that an AP is a supporting n or not, at maximum ? The rates showed in tcpdump can give me an indication of the AP is n enabled or not ? I am looking for alternative seeing into management frame and finding HT Capability... TCPdump code reads the radiotap header and classifies the channel information using the radiotap header into the following : fhss A,G (half/full duplex) , B,T , HT40+,HT40- I am listening only for beacons in then network. Hence I notice I never see anything apart from A, G. When is HT40+,40- transmitted in radiotap header ? in data frames ? Will I ever see HT40+,40- in case of beacons. Does this field in radiotap header (if it occurs) mean the interface beacon came from was having the above (equivilantly n ) support ? HT40+,- is essentially n ? So, do I need to look at any other type of frames than beacons... Or just once AP support 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. > Ok. So, there is nothing as a N beacon.. Only advertisements at 1,6 rate and then actual data at N speed. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
>> 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, > > > There is no buffer size option in pcap_open_live(), so you *can't* give > the buffer size in a pcap_open_live() call. > > I can't find any default buffer size in pcap,How can I know that it is goodenough when I am doing select > > >> 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 > > No. > > > or the mac header ? > > No. > > It's in the management frame body. See sections 7.1, 7.2, and 7.3 of the > 802.11 standard: > >http://standards.ieee.org/getieee802/download/802.11-2007.pdf > > and of the 802.11n standard: > >http://standards.ieee.org/getieee802/download/802.11n-2009.pdf > > Thanks for the resources! 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. I have a pointer to capabilty section, I am not sure how to check the protocol n is advertised by the AP > > 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. > > None that I know of. > > > I am parsing till the 31st bit on radiotap header bitmap. > > Any code base where I can see how they do it ? > > None of this is in the radiotap header! It's in the body of a management > frame.- > 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.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
> > > > VSZ reports 9304 Bytes.I think this must be virtual address space. > > 9394 *bytes*? That's 15% of about 62KB; if that's 15% of your RAM, you're > probably running on a machine with 64K, which I doubt. > > Did you mean 9394KB? top, at least on my machine (running Mac OS X), > reports various memory sizes with B/K/M/G suffixes. > > Its KB then, because the router has 64MB RAM So, it means, I am filling the buffer almost always. > > TCPdump code reads the radiotap header and classifies the channel > > information using the radiotap header into the following : > > fhss A,G (half/full duplex) , B,T , HT40+,HT40- > > I am listening only for beacons in then network. Hence I notice I never > see > > anything apart from A, G. When is HT40+,40- transmitted in radiotap > header > > ? in data frames ? > > Yes. You won't see HT beacons; I'm surprised you're even seeing G > beacons, as B-only stations won't be able to see them. > > I have seen G beacon. I have seen beacons at both 6,1 Mbits/s; > > Will I ever see HT40+,40- in case of beacons. > > Probably not. > > Ok. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] capturing on both interfaces simultaneously
On Mon, Dec 12, 2011 at 4:10 PM, wrote: > On Mon, Dec 12, 2011 at 12:53:38PM -0800, Guy Harris wrote: > > > > Will I ever see HT40+,40- in case of beacons. > > > > Probably not. > > > > > > Ok. So, there is nothing as a N beacon.. > > > Only advertisements at 1,6 rate and then actual data at N speed. > > > > Right. The beacons will generally be transmitted at low speed, so even > older stations can see them. > > About the only time you'll see beacons on non-basic rates is a > greenfield deployment, of which I've *never* found one in the wild > despite all the manufacturers caring about it. > > Lets see > Also under linux you will need to tune explicitly to CH+ or CH- to get > 40mhz data packets, they will be silently ignored on just CH. This > means you must use netlink to set the channel as siochannel can't > understand HT+ and HT-. > > Is CH+,CH- synonymous to HT+,HT-. I havent come across these terms as of now. iw talks about HT though > I don't recall offhand if you'll still see basicrate packets on CH+ or > CH- settings. > > Sniffing 11n in linux is a big mess. > > Any specific reason why? Abhinav - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] percentage of traffic captured on monitor interfaces
I wanted to know how much percentage of the original wireless traffic do I
lose when I am sniffing on monitor interfaces ?
pcap statistics show me no packet loss, but I wanted to know, if the
virtual interfaces( phy{0,1}) itself gave me all the traffic or not.
Ideal case would have been sweeping out the packets from the kernel itself,
but my patch does not work for some reason, hence I am sniffing on monitor
interfaces.
Abhinav
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] regarding ring buffer
hi, I have modified skbuff to add a custom phy header instead of the usual packet by slapping the custom header at the start of packets. Instead of pcap, i am reading from raw socket now, but I don't have any mechanism to know if any wireless frames were dropped by the ring buffer.. the statistics pcap gives ... Can anyone suggest how to get this information while i am writing code in userland. Abhinav narain - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] regarding wireless data frames
hi,
I have seen tcpdump,wireshark both just print packet contents till mac
header in monitor mode.
In case of normal wireless interfaces (wlan0), they follow a different
execution path.
Can someone tell me what should I expect in the the frame after
ieee80211_hdr (which comes after the radiotap header) ?
According to my knowledge, I assume if the control frame bit with
Is it an llc header with a general format :
struct llc_hdr {
uint8 dsap;
uint8 ssap;
struct {
uint8 ui;
uint8 org_code[3];
uint16 ether_type;
} snap;
};
so that i can jump it and get the ip header ?
If some one can correct me ? would be great
Abhinav
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] regarding wireless data frames
>
>
> No, it's not based on the type of interface, or the mode of the interface.
> It's based on whether the 802.11 payload has been decrypted or not; if
> you're capturing in monitor mode most frames are probably encrypted, but if
> you're not capturing in monitor mode and seeing only frames to or from your
> machine, they're probably decrypted.
>
> Got you !
> What the decrypted data (if the frame was encrypted) or the unencrypted
> data (if the frame wasn't encrypted) is then depends on the type and
> subtype fields.
>
> > According to my knowledge, I assume if the control frame bit with
> > Is it an llc header with a general format :
> > struct llc_hdr {
> > uint8 dsap;
> > uint8 ssap;
> > struct {
> >uint8 ui;
> >uint8 org_code[3];
> >uint16 ether_type;
> > } snap;
> > };
>
> Since I am capturing every frame in monitor mode, I would like to see the
packet type : arp/ip ... and is it tcp/udp type.
But when I do the following, I don't get any output
// f is ieee80211_hdr
if( subtype== IEEE80211_STYPE_DATA ){
struct llc_hdr* llc = (struct llc_hdr*)(((uchar*)f) + hdrlen);
int llc_type = ntohs(llc->snap.ether_type);
if (llc_type == ETHERTYPE_ARP) {
printf("ethernet type \n");
} else if (llc_type == ETHERTYPE_IP) {
if (jh->caplen_ < hdrlen + sizeof(*llc) + sizeof(struct iphdr))
return;
struct iphdr* ih = (struct iphdr*)(llc+1);
if (ih->protocol == IPPROTO_TCP)
printf("tcp \n");
else if (ih->protocol == IPPROTO_UDP)
printf("udp \n");
else if (ih->protocol == IPPROTO_ICMP)
printf("icmp \n");
}else if(subtype == IEEE80211_STYPE_NULLFUNC ){
printf("no data\n");
}
> Well, if the type is a data frame, then the payload, *once it's been
> decrypted if it was encrypted*, begins with an 802.2 LLC header. That's
> not determined by a single bit, but by a 2-byte type field (and a 4-byte
> subtype field, as some data frames have no data).
As you can notice, I am using a 2 byte field to check the subtype field.
> 802.2 headers don't necessarily have an organization code or protocol ID
> field - that's the case only for SNAP frames, where the DSAP and SSAP are
> 0xAA - and, for SNAP frames, the protocol ID field is an Ethernet type only
> if the organization code is 00:00:00.
>
> Shall i use some other llc struct to find out the data packet is of which
transport layer protocol
Abhinav Narain
> -
> 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.
Re: [tcpdump-workers] regarding wireless data frames
> > > By the way, note that the 802.11 header is *variable length*; the length > depends on, for example, whether the frame has one, two, three, or four MAC > addresses, and on whether it's a QoS frame. Yes, I am taking care of that :) Abhinav - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] regarding wireless data frames
> Oh, and one more thing: > > Some network adapters, when running in a mode where they supply an 802.11 > header (such as monitor mode), put some padding in between the 802.11 > header and the payload, so the 802.2 LLC header in a data frame might not > immediately follow the 802.11 header (regardless of whether the payload is > encrypted or not). The radiotap header includes a flag for that - it's the > 0x20 flag bit in the Flags field: > >http://www.radiotap.org/defined-fields/Flags > > I have two questions. I believe, the data packets destined for my AP, will be decrypted by the hardware itself In any case, when I get them in userland, they should be unencrypted. right ? If I look at tpdump code, for each data frame, I need to check FC_WEP(fc), if only its false, I should check further. then get the header length. int hdrlen = (FC_TO_DS(fc) && FC_FROM_DS(fc)) ? 30 : 24; if (DATA_FRAME_IS_QOS(FC_SUBTYPE(fc))) hdrlen += 2 And then, if then jump this length to check for ether type, using the llc frame . I hope I am not missing any detail. As on doing the above .. i get very low frequency of arp,udp packets, but I never get tcp packets output on my screen , even though I am browsing. Any comments ? Abhinav - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [Wireshark-dev] tcpdump-workers mailing list troubles
Please do so. my last two messages bounced back ! -Abhinav On Wed, Apr 18, 2012 at 6:05 PM, Sam Roberts wrote: > For what its worth, the last message I saw was on Mar 13th, thought I > have 2 or 3 more messages than I can see on > http://news.gmane.org/gmane.network.tcpdump.devel > > I'm CCing tcpdump-workers, I'll see if I have the problem, too. > > Sam > > > On Wed, Apr 18, 2012 at 1:52 PM, Christopher Maynard > wrote: > > I have been having trouble with the tcpdump-workers mailing list and > since I > > know at least some of the folks subscribed to this list are also > subscribed to > > that one, I thought I might mention the troubles I've seen to see if > anyone else > > is also experiencing the same troubles and if anyone here might be in a > position > > to help resolve the problems or perhaps advise me of some other course > of action > > that I could take. > > > > 1) I have not seen any activity on the list for over a month, which > seems odd to > > me right there, although not conclusive of a problem in itself, except > that ... > > > > 2) I tried to post a message and it never showed up. I read the gmane > FAQ and > > it doesn't look like they will be of much help; however ... > > > > 3) Per http://www.tcpdump.org/#mailing-lists, I tried re-subscribing to > the list > > by sending an e-mail to majord...@lists.tcpdump.org. I later received > > notification that the message was delayed and had not yet been delivered > but > > that our mail server would continue to try to deliver the message. > > Unfortunately, I later received the failure notification of the message > and that > > our mail server stopped trying to deliver it. > > > > 4) On http://www.tcpdump.org/#mailing-lists, it also indicates that you > should > > be able to use the web interface[1] to subscribe; however, that never > worked > > either. > > > > 5) The message that I tried to post earlier later came back to me as > > undeliverable. > > > > Is anyone else here experiencing trouble with the tcpdump-workers? > > > > Thanks. > > - Chris > > > > [1]: > https://cod.sandelman.ca/cgi-bin/mj_wwwusr/domain=lists.tcpdump.org?user=&; > > passw=&func=lists-long-full&extra=tcpdump-workers > > > > (NOTE: I had to split the URL over 2 lines; otherwise gmane complains > that, > > "You have lines longer than 80 characters. Fix that.") > > > > > > > ___ > > Sent via:Wireshark-dev mailing list > > Archives:http://www.wireshark.org/lists/wireshark-dev > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] mmap consumes more CPU
hi, I just checked the two mechanism : (1) Using mmap to fetch packets from kernel to userspace (2) Using recvfrom() call to fetch packets I see top reports (1) 34% memory 20% cpu usage (2) 21% memory 7% cpu usage ! I wanted a performance improvement using mmap but I am slowing my small router for packet capture( I can't use pcap for that; I have modified skbuff ) and its worst than twice ! Memory increase is fine. Can anyone suggest what going on ? Or how to improve -Abhinav Narain ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] regarding usage of recv calls in mmap code
hi I wanted to know why is MSG_PEEK used in the recv() call in mmap code and not recvfrom() with MSG_TRUNC flag. The reason i am asking is .. because I see my code takes a lot of CPU which is due to more looping, I suppose. The flag description for MSG_PEEK shows it doesn't discard the bytes even after reading from the queue. Can someone please explain. I would like to use recvfrom with MSG_TRUNC .. is that fine ? -Abhinav ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] timestamp in pcap/tcpdump
hi, I am looking for timestamp provided by pcap header and later used by tcpdump. Seems like some of wireless drivers do not provide the mac tsf timestamp. I can't figure out the timestamp meaning in pcap. Its surely not the time when packet arrived at the driver (referring to tsft). Looking at old pcap (not using mmap), it seems this is got by ioctl system, which is a deprecated mechanism ( I suppose) and not many drivers provide ioctl implementation. On the other hand, I don't have any idea how the mmap code is getting the packet timestamp ! Can someone throw light on this ? The ioctl could be traced to another function call on struct sock *, but I have not been able to comprehend the meaning of the timestamp provided. Please clarify. -Abhinav Narain ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] mmap consumes more CPU
@Guy, Basically, I was adding my own header (instead of radiotap) in kernel and processing it in userland with my own code. Basically I wrote my own pcap for that. Since, I did not get the performance, Now I have added extra fields in radiotap. But I still see high CPU usage. Its interesting that you point out there are more errors during mmap calls. Is this anything to do with allignment of frames ? [I am having 37 byte radiotap header, which is not very good number I suppose] Shall I see how the frame is added so that these errors don't occur. @Dave : I am running this code on a Netgear router running OpenWrt, so I am not sure if there is profiler that can help me out. You have raised a valid point, but is there any better tool to use/write for this ? I want to know if this processor usage will effect the router performance ? Or is it fine if the processor takes 40% or more for proper functioning of router ? its clocked at 600 Mhz, so I suppose its a beefy hardware ... -Abhinav On Mon, Nov 12, 2012 at 9:01 AM, David Laight wrote: > > hi, > > I just checked the two mechanism : > > (1) Using mmap to fetch packets from kernel to userspace > > (2) Using recvfrom() call to fetch packets > > > > I see top reports > > (1) 34% memory 20% cpu usage > > (2) 21% memory 7% cpu usage ! > > It is worth remembering that the cpu usage reported by top isn't > worth the paper it is printed on for many workloads. > IIRC it is based on the cpu state when the timer interrupt fires. > processes that are scheduled very often, and run for short periods > tend to get mis-counted. > > Since the Linux scheduler doesn't get a high-res timestamp everytime > it does a process switch, about the only way to measure idle time > is to put a very low priority process into a counting loop. > Unfortunately the scheduler might make it difficult to make the > processes priority low enough. > > David > > > > > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] hoe to debug tcpdump and libpcap source?
I have understood the codeflow without using Eclipse :-) Why don't you try that way ! -Abhinav On Mon, Nov 12, 2012 at 3:54 AM, Subbi Tk wrote: > hi All, > I am new to tcpdump and libpcap, I have downloaded the source files and > trying to compile in eclipse also facing some issue or the other > and fixing it ...But wanted to know if you have any existing document > or steps to compile the source in eclipse and how to run in debug mode it > would be of great help. > >My goal: I want to run in debug mode to understand the code flow the > design (internals) of how tcpdump/libpcap works. Basically how the hooks > are made into kernal etc. Read few documents and materials available in > net...but wanted to understand the complete code flow...so.. > > Thanks > Suhas > ___ > tcpdump-workers mailing list > tcpdump-workers@lists.tcpdump.org > https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] tcpdump vs libpcap : CPU usage shooting high for two simultaneous captures on wireless monitor interfaces
hi everyone, I have written my own data collection tool, for custom needs using libpcap for wireless interfaces(2.4,5 GHz) on a router. I could not find any flag in tcpdump that i can collect only x number of mgmt packets, y number of control packets and the rest data packets. The issue i face is this : When I run two instances of tcpdump on each interface, it has 5-10% cpu usage on the router. When I use my tool written using libpcap: When I run it on one interface (say 2.4 GHz), I get 5-10% CPU usage (output on top), but when I run another instance of the tool on the other interface(5 GHz lets say), both the processes start eating 100% of CPU all the time. Can someone explain this behavior ? I was thinking, if both the process's recv() call was spinning on some shared resource (buffer)/some kernel thread ... but why does that not happen for tcpdump ? I have literally read tcpdump/pcap code before, but I hadn't notice anything special. Can someone help me debug this problem ? - Abhinav ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump vs libpcap : CPU usage shooting high for two simultaneous captures on wireless monitor interfaces
Thanks for replying on this, as I am actually helpless on this issue for days now. As you're saying "libpcap" rather than WinPcap, I'm assuming this is some > flavor of UN*X, such as Linux. > > You are right, its running 2.6.32 on OpenWrt. > Could you build a profiled version of your tool (compile with "-pg") and > then run gprof on the tool and the gmon.out file it produces when it exits? > That should show you *where* the CPU time is being spent. > > This means that the program has to eventually exit cleanly - you can't > interrupt it with, for example, ^C unless it catches SIGINT and exits, > otherwise it'll fail to write out the gmon.out file. > > This might also be tricky if you cross-compile the tool to run on the > router, and the router doesn't have gprof installed - you might have to > have a version of gprof capable of analyzing executable files and gmon.out > files from the router. This is the trickiest part, as I haven't found profiling tools for OpenWrt. I am curious to know if tcpdump does something interesting to deal with such situation (I dint find anything when I last read the code..couple of months back) Am I right to say that the two processes spin on some shared resource ? - Abhinav ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump vs libpcap : CPU usage shooting high for two simultaneous captures on wireless monitor interfaces
Hi Guy, Thanks for clearing this > It does absolutely nothing whatsoever to discover whether there are other > versions of tcpdump are running. Ok > Am I right to say that the two processes spin on some shared resource ? > > Given that I don't know what routines in the programs or libraries they > use are running when they're consuming that CPU time, I have absolutely no > idea whether you're right or not to say that. That's why I wanted the > profiling data - so that we *know* what routines are consuming the CPU > time, not just *guessing*. > > I understand your point, but unfortunately I am unable to provide you the information. Can you show us the source code to the parts of your program that make > libpcap calls? thanks for taking the pains to have a look at the code. The line has the pcap handle return. https://github.com/abnarain/wifi_dump-tmpfs/blob/master/mac-darktest.c#L782 I have modified the mac80211 to send me radiotap info with extra information, and hence i check to see the radiotap header length to differentiate between the packet and copy the various parts of buffer into a separate table, write it to a file and ship it from the router. The other fancy thing which I am doing is setting a SIGPROCMASK to capture alarms to get to a handler which writes into the file every x minute(and if the table is full) This file only deals with the pcap code. - Abhinav ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump vs libpcap : CPU usage shooting high for two simultaneous captures on wireless monitor interfaces
hi Guy, > What happens if you eliminate that (and any code paths that eliminating > that breaks)? > > That seems to be the biggest difference between your code and tcpdump's > code (both your program and tcpdump use pcap_loop() as their main loops). I turned off SIGPROCMASK stuff ... it did not help bringing down the CPU utilization :'( - Abhinav ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump vs libpcap : CPU usage shooting high for two simultaneous captures on wireless monitor interfaces
On Thu, Apr 18, 2013 at 8:37 AM, abhinav narain wrote: > hi Guy, > > What happens if you eliminate that (and any code paths that eliminating >> that breaks)? >> >> The biggest issue for me to understand is, why is the CPU usage going up when two instances of the tool run simultaneously. It doesn't have high usage for single instance. Please let me know, if you have any suggestions where I can make my headway to investigate. - Abhinav ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump vs libpcap : CPU usage shooting high for two simultaneous captures on wireless monitor interfaces
Hi Guy,
This is one thing I am confused about.
I am right now setting the sigprocmask
in the callback function :
pkt_callback(...){
if (sigprocmask(SIG_BLOCK, &block_set, NULL) < 0) {
perror("sigprocmask");
exit(1);
}
code ...
if (sigprocmask(SIG_UNBLOCK, &block_set, NULL) < 0) {
perror("sigprocmask");
exit(1);
}
}
When I turned down all the alarms, the CPU % usage came down,
as you were also asking to try out.
I think there is lot of overhead in setting up the signal masks etc.
Can i instead set the masks in the main() function before and after calling,
pcap_loop(), which will avoid this overhead ?
I am not sure, I think this will set the masks for the code that pcap runs,
right ?
and block all the signals, which pcap might be using for any purpose, if
any.
Am I right to wrap the pcap_loop() inside the sigprocmask() block, instead
of using
it in callback function (which I am doing now ) ?
sigprocmask(block) ..
pcap_loop()
sigprocmask(unblock) ..
How will the signals work then ?
-
Abhinav
On Thu, Apr 18, 2013 at 9:06 AM, abhinav narain
wrote:
>
> On Thu, Apr 18, 2013 at 8:37 AM, abhinav narain > wrote:
>
>> hi Guy,
>>
>> What happens if you eliminate that (and any code paths that eliminating
>>> that breaks)?
>>>
>>>
> The biggest issue for me to understand is, why is the CPU usage going up
> when
> two instances of the tool run simultaneously. It doesn't have high usage
> for single instance.
> Please let me know, if you have any suggestions where I can make
> my headway to investigate.
> -
> Abhinav
>
>
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump vs libpcap : CPU usage shooting high for two simultaneous captures on wireless monitor interfaces
Hi guy,
I have strace of both tcpdump and mac-analyzer(my tool) from the router
attached.
I cannot understand why the file descriptor number is different in tcpdump
and my tool
(3 and 4) respectively.
Is this is of any significance ?
I am run both the tools on the same interface created by using iw (iw phy
phy0 .interface add phe0 ..)
Any suggestions,
please let me know.
-
Abhinav
On Fri, Apr 19, 2013 at 12:22 AM, abhinav narain
wrote:
> Hi Guy,
> This is one thing I am confused about.
>
> I am right now setting the sigprocmask
> in the callback function :
> pkt_callback(...){
> if (sigprocmask(SIG_BLOCK, &block_set, NULL) < 0) {
> perror("sigprocmask");
> exit(1);
> }
>
> code ...
> if (sigprocmask(SIG_UNBLOCK, &block_set, NULL) < 0) {
> perror("sigprocmask");
> exit(1);
> }
> }
>
> When I turned down all the alarms, the CPU % usage came down,
> as you were also asking to try out.
>
> I think there is lot of overhead in setting up the signal masks etc.
>
> Can i instead set the masks in the main() function before and after
> calling,
> pcap_loop(), which will avoid this overhead ?
>
> I am not sure, I think this will set the masks for the code that pcap
> runs, right ?
> and block all the signals, which pcap might be using for any purpose, if
> any.
>
> Am I right to wrap the pcap_loop() inside the sigprocmask() block, instead
> of using
> it in callback function (which I am doing now ) ?
>
> sigprocmask(block) ..
> pcap_loop()
> sigprocmask(unblock) ..
>
>
> How will the signals work then ?
> -
> Abhinav
>
>
>
> On Thu, Apr 18, 2013 at 9:06 AM, abhinav narain > wrote:
>
>>
>> On Thu, Apr 18, 2013 at 8:37 AM, abhinav narain <
>> abhinavnarai...@gmail.com> wrote:
>>
>>> hi Guy,
>>>
>>> What happens if you eliminate that (and any code paths that eliminating
>>>> that breaks)?
>>>>
>>>>
>> The biggest issue for me to understand is, why is the CPU usage going up
>> when
>> two instances of the tool run simultaneously. It doesn't have high usage
>> for single instance.
>> Please let me know, if you have any suggestions where I can make
>> my headway to investigate.
>> -
>> Abhinav
>>
>>
>
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump vs libpcap : CPU usage shooting high for two simultaneous captures on wireless monitor interfaces
Status : bug fixed.
-
Abhinav
On Sat, Apr 20, 2013 at 12:51 AM, abhinav narain
wrote:
>
> Hi guy,
> I have strace of both tcpdump and mac-analyzer(my tool) from the router
> attached.
>
> I cannot understand why the file descriptor number is different in tcpdump
> and my tool
> (3 and 4) respectively.
>
> Is this is of any significance ?
> I am run both the tools on the same interface created by using iw (iw phy
> phy0 .interface add phe0 ..)
>
> Any suggestions,
> please let me know.
>
> -
> Abhinav
> On Fri, Apr 19, 2013 at 12:22 AM, abhinav narain <
> abhinavnarai...@gmail.com> wrote:
>
>> Hi Guy,
>> This is one thing I am confused about.
>>
>> I am right now setting the sigprocmask
>> in the callback function :
>> pkt_callback(...){
>> if (sigprocmask(SIG_BLOCK, &block_set, NULL) < 0) {
>> perror("sigprocmask");
>> exit(1);
>> }
>>
>> code ...
>> if (sigprocmask(SIG_UNBLOCK, &block_set, NULL) < 0) {
>> perror("sigprocmask");
>> exit(1);
>> }
>> }
>>
>> When I turned down all the alarms, the CPU % usage came down,
>> as you were also asking to try out.
>>
>> I think there is lot of overhead in setting up the signal masks etc.
>>
>> Can i instead set the masks in the main() function before and after
>> calling,
>> pcap_loop(), which will avoid this overhead ?
>>
>> I am not sure, I think this will set the masks for the code that pcap
>> runs, right ?
>> and block all the signals, which pcap might be using for any purpose, if
>> any.
>>
>> Am I right to wrap the pcap_loop() inside the sigprocmask() block,
>> instead of using
>> it in callback function (which I am doing now ) ?
>>
>> sigprocmask(block) ..
>> pcap_loop()
>> sigprocmask(unblock) ..
>>
>>
>> How will the signals work then ?
>> -
>> Abhinav
>>
>>
>>
>> On Thu, Apr 18, 2013 at 9:06 AM, abhinav narain <
>> abhinavnarai...@gmail.com> wrote:
>>
>>>
>>> On Thu, Apr 18, 2013 at 8:37 AM, abhinav narain <
>>> abhinavnarai...@gmail.com> wrote:
>>>
>>>> hi Guy,
>>>>
>>>> What happens if you eliminate that (and any code paths that eliminating
>>>>> that breaks)?
>>>>>
>>>>>
>>> The biggest issue for me to understand is, why is the CPU usage going up
>>> when
>>> two instances of the tool run simultaneously. It doesn't have high usage
>>> for single instance.
>>> Please let me know, if you have any suggestions where I can make
>>> my headway to investigate.
>>> -
>>> Abhinav
>>>
>>>
>>
>
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump vs libpcap : CPU usage shooting high for two simultaneous captures on wireless monitor interfaces
Hi Guy,
This is very interesting indeed !
I was using snap len as 350 bytes and the processor was bouncing off limits.
I am using BUFSIZ as the packet capture size and my processor utilization !
Is this a bug in pcap ?
I thought may be I should try 512 (4 byte boundary) and it should also give
low CPU utilization but that does not help !
Can you please explain why pcap behaves like this ?
I am guessing tcpdump also captures the whole packet even when I use -s
option,
because I get low CPU usage with any option in tcpdump !
-
Abhinav
On Sat, Apr 20, 2013 at 1:18 AM, abhinav narain
wrote:
> Status : bug fixed.
>
> -
> Abhinav
>
>
> On Sat, Apr 20, 2013 at 12:51 AM, abhinav narain <
> abhinavnarai...@gmail.com> wrote:
>
>>
>> Hi guy,
>> I have strace of both tcpdump and mac-analyzer(my tool) from the router
>> attached.
>>
>> I cannot understand why the file descriptor number is different in
>> tcpdump and my tool
>> (3 and 4) respectively.
>>
>> Is this is of any significance ?
>> I am run both the tools on the same interface created by using iw (iw phy
>> phy0 .interface add phe0 ..)
>>
>> Any suggestions,
>> please let me know.
>>
>> -
>> Abhinav
>> On Fri, Apr 19, 2013 at 12:22 AM, abhinav narain <
>> abhinavnarai...@gmail.com> wrote:
>>
>>> Hi Guy,
>>> This is one thing I am confused about.
>>>
>>> I am right now setting the sigprocmask
>>> in the callback function :
>>> pkt_callback(...){
>>> if (sigprocmask(SIG_BLOCK, &block_set, NULL) < 0) {
>>> perror("sigprocmask");
>>> exit(1);
>>> }
>>>
>>> code ...
>>> if (sigprocmask(SIG_UNBLOCK, &block_set, NULL) < 0) {
>>> perror("sigprocmask");
>>> exit(1);
>>> }
>>> }
>>>
>>> When I turned down all the alarms, the CPU % usage came down,
>>> as you were also asking to try out.
>>>
>>> I think there is lot of overhead in setting up the signal masks etc.
>>>
>>> Can i instead set the masks in the main() function before and after
>>> calling,
>>> pcap_loop(), which will avoid this overhead ?
>>>
>>> I am not sure, I think this will set the masks for the code that pcap
>>> runs, right ?
>>> and block all the signals, which pcap might be using for any purpose, if
>>> any.
>>>
>>> Am I right to wrap the pcap_loop() inside the sigprocmask() block,
>>> instead of using
>>> it in callback function (which I am doing now ) ?
>>>
>>> sigprocmask(block) ..
>>> pcap_loop()
>>> sigprocmask(unblock) ..
>>>
>>>
>>> How will the signals work then ?
>>> -
>>> Abhinav
>>>
>>>
>>>
>>> On Thu, Apr 18, 2013 at 9:06 AM, abhinav narain <
>>> abhinavnarai...@gmail.com> wrote:
>>>
>>>>
>>>> On Thu, Apr 18, 2013 at 8:37 AM, abhinav narain <
>>>> abhinavnarai...@gmail.com> wrote:
>>>>
>>>>> hi Guy,
>>>>>
>>>>> What happens if you eliminate that (and any code paths that
>>>>>> eliminating that breaks)?
>>>>>>
>>>>>>
>>>> The biggest issue for me to understand is, why is the CPU usage going
>>>> up when
>>>> two instances of the tool run simultaneously. It doesn't have high
>>>> usage for single instance.
>>>> Please let me know, if you have any suggestions where I can make
>>>> my headway to investigate.
>>>> -
>>>> Abhinav
>>>>
>>>>
>>>
>>
>
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Different/Same queue used for promiscuous capture on ethernet ?
Hi Everyone, I am doing a packet capture on 480 MHz router on ethernet interface using pcap and see packet drops for anything greater than 50-60 Mbps. My question is following : Does pcap (and hence the kernel) create a new queue for all the packets in the promiscuous or is it collecting all packets in the same/default queue attached to the interface eth0 ? I am asking above question because I want to know if the router starts dropping packets destined to itself because of this promiscuous mode capture? I think 480 MHz is quite good processor, it is hard for me to believe that there is packet drops in queues. Router used : http://support.netgear.com/product/WNDR3700v2 Thanks, Abhinav ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Different/Same queue used for promiscuous capture on ethernet ?
Hi Guy, I infer from "eth0" that this is Linux. (DD-WRT or some other > OpenWRT-based project?) > > Yes. OpenWrt based netgear router. > On Linux, libpcap creates a PF_PACKET socket for each open pcap_t for a > regular network interface such as eth0. Each PF_PACKET socket has a queue > of its own, regardless of promiscuous mode. > > Okay, thats what I expected. The drops shown by pcap_t handle refer to the drop from this buffer. This will depend on how fast is the userland binary processing the frames from this buffer. What about kernel buffer ? How do I know if I actually dropped the frame because I ran out of memory on the device (if at all ?). What queueing the *driver* for the adapter does depends on the driver. > > > I am asking above question because I want to know if the router starts > > dropping packets destined to itself because of this promiscuous mode > > capture? > > ... > > > Router used : > > http://support.netgear.com/product/WNDR3700v2 > > Do you have more than one machine plugged into the LAN ports of the router? > > According to > > http://wiki.openwrt.org/toh/netgear/wndr3700#interfaces > > eth0 is for the "LAN ports (1 to 4)" and, according to > > > http://wiki.openwrt.org/toh/netgear/wndr3700#switch.ports.for.vlans > > eth0 is port 5 on a Realtek RTL8366s: > > > http://realtek.info/pdf/rtl8366s_8366sr_datasheet_vpre-1.4_20071022.pdf > > switch chip. > > I am sniffing on 'br-lan' interface. Its a bridged interface for all the lan port. This is because if I have packets going on wlan interface I can capture them. I don't think it captures packet to and from the lan ports 1-4. If eth0 is not in promiscuous mode, I would assume that only traffic going > between machines on the Ethernet LAN and machines on the 802.11 WLAN would > arrive on eth0, not traffic between two machines on the Ethernet LAN. I > don't know whether the eth0 port can be put into a port mirroring mode > where traffic on all the Ethernet LAN ports can be sent to the eth0 port > or, if it can, whether the driver does so if eth0 is put into promiscuous > mode, so that it sees all traffic through the switch, not just traffic to > be sent to the WLAN. > > If it *is* put into mirroring mode, and you have a significant amount of > traffic going between Ethernet LAN hosts, then promiscuous mode would > significantly increase the number of packets received. > > If it's *not* put into mirroring mode, promiscuous mode shouldn't make any > difference. > > It is not put in mirroring mode (atleast explicitly in the c code). It only sees traffic going in and out to the WLAN port. > Are you capturing in promiscuous mode? It is not in promiscuous mode. > If so, do you see as many packets dropped if you *don't* capture in > promiscuous mode? > > Can you explain why will this happen ? The packet drops given by pcap_t is packets dropped by the queue corresponding to socket on which pcap is reading data. My question was if the packets drop in promiscuous mode will actually cause packets to be dropped for other applications (file upload in some application on browser, for eg) ? or the queue for the promiscuous mode socket will be separate which will just cause packets which are being processed by pcap application to be dropped and not affect tcp timeouts to the other flow. I have not seen packet drops(I don't set the device in promiscuous), but I want to know in which case they might be dropped (if at all) since the processor is very beefy and I don't expect them to be dropped ! By the way, according to > > http://www.dd-wrt.com/wiki/index.php/Netgear_WNDR3700 > > the v2 model has a Atheros AR7161 680 MHz processor; the only model they > list with a 480 MHz processor is the v3 model, with a Broadcom BCM4718A > 480MHz processor. It shows 680 MHz in dmesg log. I said 480 MHz as I read cat /proc/cpuinfo (which reports 450.12 MIPS to be precise). Thanks, Abhinav ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
