Busybox Update Problem

[Denys Vlasenko]

On Fri, Sep 26, 2008 at 12:07 AM, Michael Davis <mdavis at dtlcontrols.com> 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