Re: [tcpdump-workers] libpcap & poll()

2008-11-13 Thread Aaron Turner
> My code is ported to windows/cygwin. Unfortunately, my only windows > box is via a Parallels VM on OSX so performance just sucks in general. > If you feel sufficiently motivated feel free to give it a spin: Actually... I forgot... libpcap/winpcap doesn't support getting the MAC address of the

Re: [tcpdump-workers] libpcap & poll()

2008-11-13 Thread Aaron Turner
On Thu, Nov 13, 2008 at 9:38 PM, Ben Greear <[EMAIL PROTECTED]> wrote: > Aaron Turner wrote: >> >> On Thu, Nov 13, 2008 at 8:15 PM, Ben Greear <[EMAIL PROTECTED]> >> wrote: >> >>> >>> I guess you have some way of knowing you are reading a packet you just >>> wrote >>> so that you don't do this in a

Re: [tcpdump-workers] libpcap & poll()

2008-11-13 Thread Ben Greear
Aaron Turner wrote: On Thu, Nov 13, 2008 at 8:15 PM, Ben Greear <[EMAIL PROTECTED]> wrote: I guess you have some way of knowing you are reading a packet you just wrote so that you don't do this in a loop? Yep. Basically it's a software bridge (two interfaces, copying all packets from

Re: [tcpdump-workers] libpcap & poll()

2008-11-13 Thread Aaron Turner
On Thu, Nov 13, 2008 at 8:15 PM, Ben Greear <[EMAIL PROTECTED]> wrote: > I guess you have some way of knowing you are reading a packet you just wrote > so that you don't do this in a loop? Yep. Basically it's a software bridge (two interfaces, copying all packets from one interface to the other)

Re: [tcpdump-workers] libpcap & poll()

2008-11-13 Thread Ben Greear
Aaron Turner wrote: On Thu, Nov 13, 2008 at 1:31 PM, Eloy Paris <[EMAIL PROTECTED]> wrote: [snip] One possible reason for high CPU when using poll() or select() is spurious readiness notifications - in this case the program is not sleeping waiting for data but is instead running, causing high

Re: [tcpdump-workers] libpcap & poll()

2008-11-13 Thread Aaron Turner
On Thu, Nov 13, 2008 at 1:31 PM, Eloy Paris <[EMAIL PROTECTED]> wrote: [snip] > One possible reason for high CPU when using poll() or select() is > spurious readiness notifications - in this case the program is not > sleeping waiting for data but is instead running, causing high CPU. > > Both the p

Re: [tcpdump-workers] Linux input layer evdev capturing

2008-11-13 Thread David Gibson
On Thu, Nov 13, 2008 at 09:22:33AM -0500, Michael Richardson wrote: > > > "David" == David Gibson <[EMAIL PROTECTED]> writes: > >> I was thinking DLT_LINUX_EVDEV just to clarify that it's a > Linux-internal > >> protocol, but I'm not fussed by DLT_EVDEV either. > > David> Uh.. so

Re: [tcpdump-workers] libpcap & poll()

2008-11-13 Thread Ben Greear
Eloy Paris wrote: Hi Ben, On Thu, Nov 13, 2008 at 03:13:05PM -0800, Ben Greear wrote: [...] The code above works on Solaris, but does not work on Windows since there is nothing to poll() on windows. Windows has select() but it is my understanding that you can't use it on a packet capture de

Re: [tcpdump-workers] libpcap & poll()

2008-11-13 Thread Eloy Paris
Hi Ben, On Thu, Nov 13, 2008 at 03:13:05PM -0800, Ben Greear wrote: [...] > The code above works on Solaris, but does not work on Windows since > there is nothing to poll() on windows. Windows has select() but it is my understanding that you can't use it on a packet capture descriptor. At least

Re: [tcpdump-workers] libpcap & poll()

2008-11-13 Thread Eloy Paris
Hi Aaron, On Thu, Nov 13, 2008 at 12:57:00PM -0800, Aaron Turner wrote: > I've been told by an end user under Linux 2.6.x at least that, he's > seeing very high CPU utilization numbers with tcpbridge which uses > libpcap to read packets. Sounds like the cause of the issue is that > I'm using pol

Re: [tcpdump-workers] libpcap & poll()

2008-11-13 Thread Eloy Paris
Hi Aaron, On Thu, Nov 13, 2008 at 02:32:21PM -0800, Aaron Turner wrote: [...] > basically: > > int keep_processing = 1; > > pcap_setnonblock(pcap1, 1, errbuf); > pcap_setnonblock(pcap2, 1, errbuf); > do { >pcap_dispatch(pcap1, -1, &callback, &keep_processing); >pcap_dispatch(pcap2, -1,

Re: [tcpdump-workers] libpcap & poll()

2008-11-13 Thread Ben Greear
Aaron Turner wrote: On Thu, Nov 13, 2008 at 1:34 PM, Ben Greear <[EMAIL PROTECTED]> wrote: Aaron Turner wrote: I've been told by an end user under Linux 2.6.x at least that, he's seeing very high CPU utilization numbers with tcpbridge which uses libpcap to read packets. Sounds like the cause o

Re: [tcpdump-workers] libpcap & poll()

2008-11-13 Thread Aaron Turner
On Thu, Nov 13, 2008 at 1:34 PM, Ben Greear <[EMAIL PROTECTED]> wrote: > Aaron Turner wrote: >> >> I've been told by an end user under Linux 2.6.x at least that, he's >> seeing very high CPU utilization numbers with tcpbridge which uses >> libpcap to read packets. Sounds like the cause of the issu

Re: [tcpdump-workers] libpcap & poll()

2008-11-13 Thread Ben Greear
Aaron Turner wrote: I've been told by an end user under Linux 2.6.x at least that, he's seeing very high CPU utilization numbers with tcpbridge which uses libpcap to read packets. Sounds like the cause of the issue is that I'm using poll() to determine when to read from libpcap. I'm using poll(

[tcpdump-workers] libpcap & poll()

2008-11-13 Thread Aaron Turner
I've been told by an end user under Linux 2.6.x at least that, he's seeing very high CPU utilization numbers with tcpbridge which uses libpcap to read packets. Sounds like the cause of the issue is that I'm using poll() to determine when to read from libpcap. I'm using poll() because my code list

Re: [tcpdump-workers] Linux input layer evdev capturing

2008-11-13 Thread Michael Richardson
> "David" == David Gibson <[EMAIL PROTECTED]> writes: >> I was thinking DLT_LINUX_EVDEV just to clarify that it's a Linux-internal >> protocol, but I'm not fussed by DLT_EVDEV either. David> Uh.. so, what's the next step here? I thought Guy already allocated one. /* * David

Re: [tcpdump-workers] Linux input layer evdev capturing

2008-11-13 Thread David Gibson
On Mon, Nov 10, 2008 at 08:58:19AM +, David Gibson wrote: > Michael Richardson sandelman.ottawa.on.ca> writes: > > > "Guy" == Guy Harris alum.mit.edu> writes: > > Guy> The name evdev is, as far as I know, a Linuxism, so DLT_EVDEV > > Guy> might suffice as a name, unless fill-in-th