udhcpc: dont use BPF filter, users report problems (bugs 4598, 6746), commit e4785ca653d0e219926692c229673b2c1b8d6ac4
cristian.ionescu-idbohrn at axis.com
Thu Feb 6 18:01:18 UTC 2014
On Thu, 6 Feb 2014, Denys Vlasenko wrote:
> On Wed, Feb 5, 2014 at 9:51 PM, Mike Frysinger <vapier at gentoo.org> wrote:
> > On Wednesday, February 05, 2014 16:41:15 Cristian Ionescu-Idbohrn wrote:
> >> On Wed, 5 Feb 2014, Denys Vlasenko wrote:
> >> > On Tue, Feb 4, 2014 at 8:48 PM, Cristian Ionescu-Idbohrn <cristian.ionescu-idbohrn at axis.com> wrote:
> >> > > The backside of this, IIRC, is that udhcpc will eat up huge chunks of
> >> > > CPU parsing "uninteresting" packets, on "heavy" loaded networks.
> >> >
> >> > udhcpc does not listen to the network after it established a lease.
> >> As I said, it's not the wait to get a lease that is a problem but the
> >> high CPU load (parsing packets).
> > what is using the high CPU load ? not udhcpc, but the kernel itself ?
> > what kernel are you using exactly ? what arch ?
> udhcpc uses raw socket to receive *all IPv4 packets* when it waits
> for initial DHCP server responses. Therefore, it can get potentially
> lots and lots of unrelated packets, and needs to check and
> discard each of them.
Yes. Thanks for that explanation.
> I am not convinced this is a problem in practice.
Well, it is. At least for the company that pays me.
> I want to avoid fixing a non-existing problem. We "fixed" it once
> with BPF filter, creating a real problem: for some people,
> presence of that filter broke udhcpc. (For me it worked).
Yes. "Some people" that, supposedly, may run kernels with BPF filter
disabled, or some such, I guess.
What I can reveal (which is also public knowledge to anyone motivated
to look for) is that the linux kernels date back to (at least) 2.6.x
and the archs are arm, cris and mips, 100-400 Mhz.
More information about the busybox