udhcpc: dont use BPF filter, users report problems (bugs 4598, 6746), commit e4785ca653d0e219926692c229673b2c1b8d6ac4

Denys Vlasenko vda.linux at googlemail.com
Fri Feb 7 16:48:06 UTC 2014


On Thu, Feb 6, 2014 at 7:01 PM, Cristian Ionescu-Idbohrn
<cristian.ionescu-idbohrn at axis.com> wrote:
>> >> > 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.

Please explain the problem. In particular:

Does udhcpc end up spending a lot of time (more than, say,
30 seconds) with raw socket open?

If yes: how it happens? As I see, it shouldn't happen
in normal scenario (when there *is* a working DHCP server).

If no: why do you think it's a problem to have a short
period of time of high CPU consumption?
Don't you think that having that many broadcast packets
on your network is already a problem? You can make
udhcpc to not receive them, yes, but your network card
still receives them all the time.

>> 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.

Disabled filter should result in SO_ATTACH_FILTER failure
and as a result, all packets being received.

Users report that they see that all packets get *dropped*.

> 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 mailing list