[tcpdump-workers] libpcap capture performance drop
Hello, I am experiencing the same problem as described in http://news.gmane.org/find-root.php?message_id=%3c972613.6039.qm%40web59701.mail.ac4.yahoo.com%3e I have written a software that captures Ethernet frames and forwards them to different interfaces. On Ubuntu 8.10 the software is able to handle 100 Mbit/s without drops on a Intel Core 2 Duo System. When upgrading to any other version of Ubuntu, I experience between 0.5 and 3% packet loss on the same system and also on systems using Intel Core 2 Quad CPUs. The libpcap version of Ubuntu 8.10 was 0.9.8 and it was upgraded with later Ubuntu versions. I wanted to try to disable mmap (using libpcap-1.1.1) as suggested in the previous post "for Linux, after running the configure script, get rid of the definition of HAVE_PACKET_RING in config.h;" But I could not find HAVE_PACKET_RING in the created config.h and also nothing related in the ./configure output. Has this been changed? All the best, Bernd - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap capture performance drop
Hi, thanks for the advice. If I use libpcap 1.1.1 compiled with the HAVE_PACKET_RING stuff commented out, the my softare performs very well. Ubuntu currently ships with 1.0.0.6 I think. If I use that version my application has problems capturing 100 Mbit/s of traffic. If I change to the custom build version of libpcap then I can capture 1 Gbit/s of traffic and problem occur only for small packet sizes (<100 Byte). Any idea why mmap is slowing everything down? I am using pcap_dispatch to capture packet by packet. > Subject: Re: [tcpdump-workers] libpcap capture performance drop > From: g...@alum.mit.edu > Date: Fri, 13 Aug 2010 14:00:22 -0700 > To: tcpdump-workers@lists.tcpdump.org > > > On Aug 10, 2010, at 3:35 AM, Doktor Bernd wrote: > > > I am experiencing the same problem as described in > > http://news.gmane.org/find-root.php?message_id=%3c972613.6039.qm%40web59701.mail.ac4.yahoo.com%3e > > > > I have written a software that captures Ethernet frames and forwards them > > to different interfaces. > > > > On Ubuntu 8.10 the software is able to handle 100 Mbit/s without drops on a > > Intel Core 2 Duo System. When upgrading to any other version of Ubuntu, I > > experience between 0.5 and 3% packet loss on the same system and also on > > systems using Intel Core 2 Quad CPUs. > > > > The libpcap version of Ubuntu 8.10 was 0.9.8 and it was upgraded with later > > Ubuntu versions. > > > > I wanted to try to disable mmap (using libpcap-1.1.1) as suggested in the > > previous post > > "for Linux, after running the configure script, get rid of the definition > > of HAVE_PACKET_RING in config.h;" > > > > But I could not find HAVE_PACKET_RING in the created config.h and also > > nothing related in the ./configure output. > > Has this been changed? > > No. I forgot that the availability of the memory-mapped pcap mechanism isn't > determined by the configure script, it's determined by what the system > includes offer. > > Instead, in pcap-linux.c, just #if 0 out the > > /* check for memory mapped access avaibility. We assume every needed > * struct is defined if the macro TPACKET_HDRLEN is defined, because it > * uses many ring related structs and macros */ > # ifdef TPACKET_HDRLEN > # define HAVE_PACKET_RING > # ifdef TPACKET2_HDRLEN > # define HAVE_TPACKET2 > # else > # define TPACKET_V1 0 > # endif /* TPACKET2_HDRLEN */ > # endif /* TPACKET_HDRLEN */ > #endif /* PF_PACKET */ > > stuff, so that HAVE_PACKET_RING isn't defined.- > 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] libpcap capture performance drop
Hi, back from vacation I had some time to test libpcap again > > thanks for the advice. If I use libpcap 1.1.1 compiled with the > > HAVE_PACKET_RING stuff commented out, the my softare performs very well. > > Ubuntu currently ships with 1.0.0.6 I think. If I use that version my > > application has problems capturing 100 Mbit/s of traffic. If I change to > > the custom build version of libpcap then I can capture 1 Gbit/s of traffic > > and problem occur only for small packet sizes (<100 Byte). > > What happens if you build 1.1.1 with no changes (i.e., with the > HAVE_PACKET_RING stuff *not* commented out) and use that version? That's the > cleanest test of mmap vs. non-mmap. If I recompile with the HAVE_PACKET_RING stuff *not* commented out I get the bad performance as with the packaged versions from Ubuntu. So the performance drop is caused by that part of libpcap. > > Any idea why mmap is slowing everything down? I am using pcap_dispatch to > > capture packet by packet. > > (That means you're not using pcap_next() or pcap_next_ex(), correct?) correct > What are you passing as the second argument to pcap_dispatch()? 1 > And how are you measuring the packet loss? Are you using the figures from > pcap_stats(), or are you determining in some other fashion that packets > weren't captured?- I am generating my own packets and compare sent vs. received numbers. For generating the packets another PC is used. Bernd - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] pcap_setdirection not working anymore?
Hi,
I have a software that captures packets from an interface and also injects
packets on the same interface.
When I wrote the software I was using Ubuntu 8.10 with pcap 0.9 something.
Today I wanted to use it again and tried to run it on Ubuntu 10.04 with pcap
1.1.1, but the software now captures the injected packets.
This is my statement for setting the capture direction, which seem to get
executed without error.
#ifdef __LINUX__
//capture direction is not available on windows
if(pcap_setdirection(sniffhandle, PCAP_D_IN)==-1)
{
std::strcpy(errormessage, pcap_geterr(sniffhandle));
throw std::runtime_error(getErrormessage().c_str());
}
#endif
To check what happens I print a CRC for each captured and injected packet which
e.g. results in:
Captured CRC: 3a112bb
Injected CRC: 3a112bb
Captured CRC: 3a112bb
Injected CRC: 3a112bb
Captured CRC: 3a112bb
Captured CRC: 3a112bb
Injected CRC: 3a112bb
Captured CRC: 3a112bb
Injected CRC: 3a112bb
Captured CRC: 3a112bb
...
So the software captures its own packets and gets stuck in a loop.
Has there been a change to this part of pcap?
How can I prevent the software from capturing its own packets? (using filter
rules will not work in my case, because the packets look all the same)
Thanks for reading,
Bernd
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_setdirection not working anymore?
Hi again,
I noticed that for pcap_setdirection HAVE_PF_PACKET_SOCKETS must be defined.
But it is not defined for my build.
What do I need for HAVE_PF_PACKET_SOCKETS to be defined when I compile libpcap
on my own?
Bernd
> From: doktorbe...@hotmail.com
> To: tcpdump-workers@lists.tcpdump.org
> Subject: [tcpdump-workers] pcap_setdirection not working anymore?
> Date: Tue, 19 Oct 2010 12:46:54 +
>
>
> Hi,
>
> I have a software that captures packets from an interface and also injects
> packets on the same interface.
> When I wrote the software I was using Ubuntu 8.10 with pcap 0.9 something.
> Today I wanted to use it again and tried to run it on Ubuntu 10.04 with pcap
> 1.1.1, but the software now captures the injected packets.
>
> This is my statement for setting the capture direction, which seem to get
> executed without error.
>
> #ifdef __LINUX__
> //capture direction is not available on windows
> if(pcap_setdirection(sniffhandle, PCAP_D_IN)==-1)
> {
> std::strcpy(errormessage, pcap_geterr(sniffhandle));
> throw std::runtime_error(getErrormessage().c_str());
> }
> #endif
>
> To check what happens I print a CRC for each captured and injected packet
> which e.g. results in:
>
> Captured CRC: 3a112bb
> Injected CRC: 3a112bb
> Captured CRC: 3a112bb
> Injected CRC: 3a112bb
> Captured CRC: 3a112bb
> Captured CRC: 3a112bb
> Injected CRC: 3a112bb
> Captured CRC: 3a112bb
> Injected CRC: 3a112bb
> Captured CRC: 3a112bb
> ...
>
> So the software captures its own packets and gets stuck in a loop.
>
> Has there been a change to this part of pcap?
> How can I prevent the software from capturing its own packets? (using filter
> rules will not work in my case, because the packets look all the same)
>
> Thanks for reading,
> Bernd
> -
> 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] pcap_setdirection not working anymore?
Ok, my problem is solved.
The libpcap from Ubuntu (version 1.0. something) was interfering with my self
compiled libpcap 1.1.1.
Now I have removed the Ubuntu compiled version and everything is fine.
So I think pcap_setdirection is not working in the Ubuntu packaged version, but
compiling my own package is fine for me.
Bernd
> From: doktorbe...@hotmail.com
> To: tcpdump-workers@lists.tcpdump.org
> Subject: Re: [tcpdump-workers] pcap_setdirection not working anymore?
> Date: Tue, 19 Oct 2010 14:00:13 +
>
>
> Hi again,
>
> I noticed that for pcap_setdirection HAVE_PF_PACKET_SOCKETS must be defined.
> But it is not defined for my build.
> What do I need for HAVE_PF_PACKET_SOCKETS to be defined when I compile
> libpcap on my own?
>
> Bernd
>
>
> > From: doktorbe...@hotmail.com
> > To: tcpdump-workers@lists.tcpdump.org
> > Subject: [tcpdump-workers] pcap_setdirection not working anymore?
> > Date: Tue, 19 Oct 2010 12:46:54 +
> >
> >
> > Hi,
> >
> > I have a software that captures packets from an interface and also injects
> > packets on the same interface.
> > When I wrote the software I was using Ubuntu 8.10 with pcap 0.9 something.
> > Today I wanted to use it again and tried to run it on Ubuntu 10.04 with
> > pcap 1.1.1, but the software now captures the injected packets.
> >
> > This is my statement for setting the capture direction, which seem to get
> > executed without error.
> >
> > #ifdef __LINUX__
> > //capture direction is not available on windows
> > if(pcap_setdirection(sniffhandle, PCAP_D_IN)==-1)
> > {
> > std::strcpy(errormessage, pcap_geterr(sniffhandle));
> > throw std::runtime_error(getErrormessage().c_str());
> > }
> > #endif
> >
> > To check what happens I print a CRC for each captured and injected packet
> > which e.g. results in:
> >
> > Captured CRC: 3a112bb
> > Injected CRC: 3a112bb
> > Captured CRC: 3a112bb
> > Injected CRC: 3a112bb
> > Captured CRC: 3a112bb
> > Captured CRC: 3a112bb
> > Injected CRC: 3a112bb
> > Captured CRC: 3a112bb
> > Injected CRC: 3a112bb
> > Captured CRC: 3a112bb
> > ...
> >
> > So the software captures its own packets and gets stuck in a loop.
> >
> > Has there been a change to this part of pcap?
> > How can I prevent the software from capturing its own packets? (using
> > filter rules will not work in my case, because the packets look all the
> > same)
> >
> > Thanks for reading,
> > Bernd
> > -
> > 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.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap capture performance drop
Thanx for that information! I think I have used something big like 65535. But using 1514 should be enough in my case (CRC is dropped). I hope I will find some time to play around with the snap_len in the next weeks and let you know what happens. All the best, Bernd > Subject: Re: [tcpdump-workers] libpcap capture performance drop > From: g...@alum.mit.edu > Date: Fri, 20 May 2011 12:02:42 -0700 > To: tcpdump-workers@lists.tcpdump.org > > > On Sep 6, 2010, at 11:45 AM, Doktor Bernd wrote: > > > If I recompile with the HAVE_PACKET_RING stuff *not* commented out I get > > the bad performance as with the packaged versions from Ubuntu. So the > > performance drop is caused by that part of libpcap. > > The packet-ring stuff has fixed-length slots, which means that the number of > slots is the buffer size divided by the size of the slots. > > The slot size is calculated from the snapshot length; what snapshot length > are you using? If, for example, this is on Ethernet, and your snapshot > length is > 1518 (1518 just in case the CRC is delivered as part of the > packet; it is with BPF in Mac OS X, for example, and I think on some other > BPF platforms, but it might not be on Linux), that might reduce the number of > ring buffer slots and thus increase the number of packet drops, especially if > the snapshot length is, for example, the tcpdump/Wireshark default of 65535.- > 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] Influence of pcap_open_live parameters on pcap_sendpacket
Hi, I am trying to optimize my program by adjusting the parameters of pcap_open_live(). In my program, I am opening the same interface twice and use one handle in a thread for capturing packets and the other handle in a second thread for writing Two questions: - Do the two pcap_open_live() calls influence the hardware in anyway and have side effects on each other or are they bound to the handle and I can rely on the parameters I give to be set? - Do the parameters influence pcap_sendpacket() in any way? From the documentation I assume that they are only for capturing from that interface. All the best, Bernd - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Influence of pcap_open_live parameters on
Hi, thanks for the answers, the caveat of capturing the sent packets when capturing on the same interface is well known to me ;-) So I defenitely use filtering on the capture interface (pcap_setdirection() is not always available) All the best, Bernd > Subject: Re: [tcpdump-workers] Influence of pcap_open_live parameters on > pcap_sendpacket > From: g...@alum.mit.edu > Date: Tue, 16 Aug 2011 09:34:37 -0700 > To: tcpdump-workers@lists.tcpdump.org > > > On Aug 16, 2011, at 5:10 AM, Doktor Bernd wrote: > > > Two questions: > > - Do the two pcap_open_live() calls influence the hardware in anyway and > > have side effects on each other or are they bound to the handle and I can > > rely on the parameters I give to be set? > > For LAN hardware, the "promisc" argument to pcap_open_live() affects whether > the interface is put in promiscuous mode; all handles will be in promiscuous > mode if any are (or, for that matter, if any other process has turned on > promiscuous mode directly rather than through libpcap). > > > - Do the parameters influence pcap_sendpacket() in any way? From the > > documentation I assume that they are only for capturing from that interface. > > None of them should affect pcap_sendpacket() directly; perhaps running in > promiscuous mode will, for example, cause the network adapter to be busier, > which might slow down its sending of packets to some degree.- > 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] libpcap capture performance drop
I had time to play around with my packet capturing stuff. Using a snapshot length of 1524 (i added a few bytes just to be safe) seems to give the same performance in both versions, so I can go back and use the packages delivered with Ubuntu. Great! Btw. I experienced the biggest performance increase by changing the 32bit Lubuntu 11.04 to an 64bit Ubuntu 11.04 on the same machine. All the best, Bernd > From: doktorbe...@hotmail.com > To: tcpdump-workers@lists.tcpdump.org > Subject: Re: [tcpdump-workers] libpcap capture performance drop > Date: Thu, 26 May 2011 09:18:19 + > > > Thanx for that information! > > I think I have used something big like 65535. But using 1514 should be enough > in my case (CRC is dropped). > > I hope I will find some time to play around with the snap_len in the next > weeks and let you know what happens. > > All the best, > Bernd > > > Subject: Re: [tcpdump-workers] libpcap capture performance drop > > From: g...@alum.mit.edu > > Date: Fri, 20 May 2011 12:02:42 -0700 > > To: tcpdump-workers@lists.tcpdump.org > > > > > > On Sep 6, 2010, at 11:45 AM, Doktor Bernd wrote: > > > > > If I recompile with the HAVE_PACKET_RING stuff *not* commented out I get > > > the bad performance as with the packaged versions from Ubuntu. So the > > > performance drop is caused by that part of libpcap. > > > > The packet-ring stuff has fixed-length slots, which means that the number > > of slots is the buffer size divided by the size of the slots. > > > > The slot size is calculated from the snapshot length; what snapshot length > > are you using? If, for example, this is on Ethernet, and your snapshot > > length is > 1518 (1518 just in case the CRC is delivered as part of the > > packet; it is with BPF in Mac OS X, for example, and I think on some other > > BPF platforms, but it might not be on Linux), that might reduce the number > > of ring buffer slots and thus increase the number of packet drops, > > especially if the snapshot length is, for example, the tcpdump/Wireshark > > default of 65535.- > > 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. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
