On Thu, Feb 6, 2014 at 7:01 PM, Cristian Ionescu-Idbohrn <[email protected]> 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. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
