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

Cristian Ionescu-Idbohrn cristian.ionescu-idbohrn at axis.com
Wed Feb 5 15:41:15 UTC 2014


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

Yes.  But imagine the usecase where you get a power outage and a farm
of embedded systems fight to get a lease.  Also, every time a lease
renew occurs CPU gets wasted parsing "uninteresting" packets.

> It just sleeps, usually for hours, waiting for 1/2 of the lease time
> to expire. No network sockets are open during that time:
>
> # ls -l /proc/1412/fd
> total 0
> lr-x------ 1 root root 64 Feb  5 15:08 0 -> /dev/null
> l-wx------ 1 root root 64 Feb  5 15:08 1 -> pipe:[16588]
> l-wx------ 1 root root 64 Feb  5 15:08 2 -> pipe:[16588]
> lr-x------ 1 root root 64 Feb  5 15:08 3 -> pipe:[22350]
> l-wx------ 1 root root 64 Feb  5 15:08 4 -> pipe:[22350]
>
> fds 1 and 2 are stdout/err (in my case, directed to a logger),
> fds 3 and 4 is the internal signal pipe.

Yes.  I understand that.  Still, would you accept a patch that makes
the BPF filter an option?


Cheers,

-- 
Cristian


More information about the busybox mailing list