udhcpc: dont use BPF filter, users report problems (bugs 4598, 6746), commit e4785ca653d0e219926692c229673b2c1b8d6ac4
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