Michael Richardson
2013-12-08 15:46:43 UTC
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, notto 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.
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 [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [