[patch] [rfc] udhcpc eating too much cpu

[Cristian Ionescu-Idbohrn]

On Wed, 23 Jan 2008, Stefan Rompf wrote:

> Am Freitag, 18. Januar 2008 21:54 schrieb Cristian Ionescu-Idbohrn:
>
> > Makes me happy too ;)  But the credit should go to a collegue of
> > mine (Bcc:ed) who checked the code and suggested that.
>
> I can credit to "unknown colleague of Cristian Ionescu-Idbohrn" ;-)

I'll notify my secret collegue of your nice remark ;)

> > By the way, you wodn't happen to be excited over cotributing your
> > netlink code (adjusted) to busybox needs?
>
> Feel free, but from looking at udhcpc, our codebases are quite
> different so that it will be mostly recoding the idea. Important
> points that come to my mind:
>
> -When doing RFC4436 like address validation by arping the default
> gateway, there should be a time limit, e.g. don't do this when the
> interface has been down for longer than 60 seconds. Main reason is
> that the MAC address isn't that unique when rundancy protocols like
> VRRP or HSRP are used. Using a time limit, you can guess whether the
> down/up sequence is from roaming between access points of one ESSID,
> or a real network disconnection. Existing problem: On suspend to
> disk/RAM, many drivers report the down/up after resume.

Good point.  We'll have a look at that.

> -Kernel 2.4 compatibility: 2.4 already has the IFF_RUNNING, and some
> drivers set it, but there is no notification. So for 2.4, you either
> have to poll the kernel or completely ignore the flag.

Alright.

> -You should at least migrate read_interface() to use the same
> netlink socket as the notification to avoid race conditions.

Ok.

> Anything left... surely, I'll mail you when I remember it.

Please do.


Cheers,

-- 
Cristian