[tcpdump-workers] Problem with pcap_set_datalink DLT_IEEE802_11_RADIO
I am using libpcap-dev 0.9.8 in Ubuntu 12.04 on my laptop.
Setting my wlan0 interface to monitor mode using iwconfig and tcpdump -i
wlan0 -y IEEE802_11_RADIO
works fine but when doing it in C it fails with an DLT not supported by
device error.
Here is the source code excerpt that fails:
/* Set device in monitor mode */
if(pcap_can_set_rfmon(handle)) {
if(pcap_set_rfmon(handle, 1) ==
PCAP_ERROR_ACTIVATED) {
printf("Failed to activate monitor
mode\n");
exit(EXIT_FAILURE);
}
}else{
printf("Cannot set monitor mode\n");
exit(EXIT_FAILURE);
}
/* Set additional settings for pcap */
pcap_set_snaplen(handle, 2048);
pcap_set_promisc(handle, 1);
pcap_set_timeout(handle, 100);
pcap_activate(handle);
/* Set datalink type */
if(pcap_set_datalink(handle, DLT_IEEE802_11_RADIO) == -1) { //
returns -1 on device that supports this DLT
printf("Couldn't set datalink type %s: %s\n",
device, pcap_geterr(handle));
}
What could be the problem?
Thanks in advance.
Elton Lika
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] pcap_read_linux_mmap() not returning packets on time
I am having a problem using libpcap in my program and I would like a bit of guidance before I try to understand how Linux PACKET_MMAP works. Using an unpatched libpcap 1.4.0 (and a OpenWRT patched 1.1.1) I find this call: pcap_dispatch(pcap_descr, -1, placeholder, NULL); after a blocking, successful, read() sometimes doesn't return any packet. Adding a few printf() to libpcap I found that in pcap_read_linux-mmap() sometimes, a) The first pcap_get_ring_frame() returns NULL b) poll() immediately returns 1 (pcap_descr is non blocking) c) The pcap_get_ring_frame() in the while returns NULL in the first iteration Since poll() says there is a packet, shouldn't pcap_get_ring_frame return it? I mean, shouldn't be 100% guaranteed? The behaviour I am seeing is that for some periods all pcap_dispatch() calls return 1 without even calling poll(). But for some other periods, that can last *minutes* hundreds of pcap_dispatch() calls return 0 just to then get all these missing packets in a single pcap_dispatch() call. The program is running in one of these things: http://wiki.openwrt.org/toh/tp-link/tl-wdr3600. I don't discard the possibility of a problem in the network driver. But what kind of problem would make read() and poll() see the packets, but not pcap_get_ring_frame()? There is a bug here (probably not in libpcap) or is all this expected? Thanks. -- Cristian Morales Vega Email crist...@samknows.com Office +44 (0) 20 3111 4330 Web: www.samknows.com This email is sent for and on behalf of SamKnows Limited. This email and any attachments are confidential, legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. SamKnows Limited, Registered Number: 06510477, Registered Office: Hill House, 1 Little New Street, London, EC4A 3TR. Registered in England and Wales. Trade Mark 2507103 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_read_linux_mmap() not returning packets on time
The simple version is that I am seeing poll repeatedly returning POLLIN but when pcap checks the mmaped memory it finds TP_STATUS_USER is not set. >From what I can see the only thing poll (net/packet/af_packet.c:net/packet/af_packet.c) does is check if TP_STATUS_USER is set. So, could it be that pcap is not looking in the correct place? Even in this case I can't explain why after a while all the packets appear to pcap. ps. it's using TPACKET_V2 On 11 September 2013 11:25, Cristian Morales Vega wrote: > I am having a problem using libpcap in my program and I would like a > bit of guidance before I try to understand how Linux PACKET_MMAP > works. > > Using an unpatched libpcap 1.4.0 (and a OpenWRT patched 1.1.1) I find > this call: > > pcap_dispatch(pcap_descr, -1, placeholder, NULL); > > after a blocking, successful, read() sometimes doesn't return any packet. > > Adding a few printf() to libpcap I found that in > pcap_read_linux-mmap() sometimes, > a) The first pcap_get_ring_frame() returns NULL > b) poll() immediately returns 1 (pcap_descr is non blocking) > c) The pcap_get_ring_frame() in the while returns NULL in the first iteration > > Since poll() says there is a packet, shouldn't pcap_get_ring_frame > return it? I mean, shouldn't be 100% guaranteed? > > The behaviour I am seeing is that for some periods all pcap_dispatch() > calls return 1 without even calling poll(). But for some other > periods, that can last *minutes* hundreds of pcap_dispatch() calls > return 0 just to then get all these missing packets in a single > pcap_dispatch() call. > > > The program is running in one of these things: > http://wiki.openwrt.org/toh/tp-link/tl-wdr3600. I don't discard the > possibility of a problem in the network driver. But what kind of > problem would make read() and poll() see the packets, but not > pcap_get_ring_frame()? > > There is a bug here (probably not in libpcap) or is all this expected? > > > Thanks. > > -- > Cristian Morales Vega > > Email crist...@samknows.com > Office +44 (0) 20 3111 4330 > Web: www.samknows.com > > > This email is sent for and on behalf of SamKnows Limited. > > This email and any attachments are confidential, legally privileged > and protected by copyright. If you are not the intended recipient > dissemination or copying of this email is prohibited. If you have > received this in error, please notify the sender by replying by email > and then delete the email completely from your system. > > SamKnows Limited, Registered Number: 06510477, Registered Office: Hill > House, 1 Little New Street, London, EC4A 3TR. Registered in England > and Wales. Trade Mark 2507103 -- Cristian Morales Vega Email crist...@samknows.com Office +44 (0) 20 3111 4330 Web: www.samknows.com This email is sent for and on behalf of SamKnows Limited. This email and any attachments are confidential, legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. SamKnows Limited, Registered Number: 06510477, Registered Office: Hill House, 1 Little New Street, London, EC4A 3TR. Registered in England and Wales. Trade Mark 2507103 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
