On Fri, Sep 26, 2008 at 12:07 AM, Michael Davis <[EMAIL PROTECTED]> wrote: > Denys Vlasenko wrote: >> On Wednesday 24 September 2008 00:19, Michael Davis wrote: >> >>> I started messing around with the rc.sysinit file thinking that maybe >>> something had changed between the different versions. >>> I found the problem was with this section >>> >>> if [ "x`grep ip= /proc/cmdline`" = "x" ] >>> then >>> udhcpc -i eth0 -b -p /var/run/udhcpc.eth0.pid >/dev/null 2>&1 >>> fi >>> >>> So I tested the udhcpc with the above command in a normal terminal and >>> it doesn't go to the background. >>> I then tested it without sending the output to /dev/null. I get this >>> output. >>> udhcpc (v1.11.2) started >>> Sending discover... >>> Sending select for 192.168.1.169... >>> Sending select for 192.168.1.169... >>> Sending select for 192.168.1.169... >>> Sending discover... >>> Sending select for 192.168.1.169... >>> Sending select for 192.168.1.169... >>> Sending select for 192.168.1.169... >>> >> >> This is interesting. Your DHCP server _does_ offer you an IP, >> but then it doesn't ACK it. udhcpc does not expect such a loop, >> and never invokes >> "-b,--background Background if lease is not immediately obtained" >> code. >> >> Can you capture "tcpdump -nlieth0 -s0 port 67 or port 68" output >> while it runs? >> >> Please try attached patch, does it make udhcpc background? >> >> On a side note, the way you do network config is fragile. >> Don't you see that hardcoding eth0 interface name is asking >> for trouble in multihomed case? What will happen if >> /proc/cmdline would accidentally contain e.g. "turnip=big" >> substring? >> >> -- >> vda >> > Output of tcpdump is as follows. Repeating on forever of course. > 16:48:49.033831 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 00:ba:d0:0b:ad:00, length 548 > 16:48:52.101304 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 00:ba:d0:0b:ad:00, length 548 > 16:48:55.238251 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 00:ba:d0:0b:ad:00, length 548 > 16:48:55.538411 IP 192.168.1.1.bootps > 255.255.255.255.bootpc: > BOOTP/DHCP, Reply, length 300 > 16:48:55.577928 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 00:ba:d0:0b:ad:00, length 548 > 16:48:58.655093 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 00:ba:d0:0b:ad:00, length 548 > 16:49:01.721297 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 00:ba:d0:0b:ad:00, length 548 > 16:49:04.878192 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, > Request from 00:ba:d0:0b:ad:00, length 548 > 16:49:05.178964 IP 192.168.1.1.bootps > 255.255.255.255.bootpc: > BOOTP/DHCP, Reply, length 300 > > Patch didn't make any difference that I could see.
Patch should have made udhcpc background (due to -b) after select failed to get any resoponse: Sending discover... Sending select for 192.168.1.169... Sending select for 192.168.1.169... Sending select for 192.168.1.169... <=== after this Did this happen? > Cirrus has a lot of problems with their environment so it doesn't > surprise me their configuration sucks. > I don't think they really intended it for multihomed environment any ways. > My udhcpc is already disabled and that config is taken out. Just > helping the bug hunting effort at this point. :P Thanks, can you try again with this? tcpdump -nl -ieth0 -s0 -vvv port 67 or port 68 It should parse DHCP packets with gobs of details. Please sent the output as attachment to prevent line wraps and such. -- vda _______________________________________________ busybox mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/busybox
