[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tcpdump-workers
Subject:    Re: [tcpdump-workers] [libpcap] arpwatch 100% cpu with libpcap >=1.5.1 (#333)
From:       Michael Richardson <mcr () sandelman ! ca>
Date:       2013-12-08 15:46:43
Message-ID: 27770.1386517603 () sandelman ! ca
[Download RAW message or body]


Sébastien Luttringer <notifications@github.com> wrote:
    > I found a regression in libpcap between 1.4.0 and >=1.5.1 which cause arpwatch
    > to consume 100% of CPU and stop working when listening on a bridge interface on
    > i686.

    > I'm currently not able to reproduce it on another computer (vm).

    > I tested with fresh 1.5.2 and regression is still present.
    > I also tested with different linux kernel version 3.9, 3.10, 3.11 and 3.12.
    > All of this is tested on i686 archlinux host which act as router/firewall.

    > strace and ltrace give nothing. No output when process is running at 100%. So I
    > guess the process run in loop inside a library call.

So, my guess is that it is cycling through the receive ring without stop, not
detecting when the ring is empty, when it should return into the select()
loop.

I know little about the TPACKET_V3 code, so this is a guess.

Clearly, you need to have an interface on the bridge interface so that at
least one packet arrives.  I am unclear if dhclient is critical: can you say?
dhclient uses pcap, likely not TPACKET_v3 though, to read/write traffic.
Maybe different TPACKET_* versions do not mix well.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
	

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[prev in list] [next in list] [prev in thread] [next in thread]