ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] udhcpc gets different addr


From: Michael Jones
Subject: Re: [Ltib] udhcpc gets different addr
Date: Thu, 19 Nov 2009 14:32:47 +0100
User-agent: Thunderbird 2.0.0.23 (X11/20090817)

Hi Stuart,

According to linux/Documentation/nfsroot.txt, you can just change the "ip=...eth0:off" part of your command line to "ip=...eth0:dhcp" or "ip=...eth0:bootp" (I'm using bootp). You can also just replace the whole 'ip=...' part with just 'ip=dhcp' or 'ip=bootp'.

I'm using a version of RedBoot which annoyingly _always_ prepends the 'ip' argument itself, filling in the addresses with RedBoot variables which I can set. I can only choose between 'bootp' and 'off', and I can't use the nice, tidy, 'ip=dhcp' form. In fact, maybe using bootp here has something to do with why my udhcpc gets a different IP address.

Also, you need kernel config options CONFIG_IP_PNP and e.g. CONFIG_IP_PNP_BOOTP enabled.

Glad to hear you like the suggestion :)

-Michael

Stuart Hughes wrote:
Hi Michael,

I like this suggestion and I'm trying to test it. However I need some help. Normally for NFS booting (u-boot), I use the example line for the boot args (all one line)

=> setenv bootargs root=/dev/nfs rw nfsroot=192.168.0.10:/data/seh/Src/ltib_bsps/savannah_ltib/rootfs ip=target_ip:192.168.0.10::255.255.255.0::eth0:off console=ttyS0,115200

192.168.0.10 is my NFS server. Where I've written target_ip is where I'd normally give a static IP address for the target.

What's the correct kernel command line to say "dynamically get the target IP address"?

Regards, Stuart

Michael Jones wrote:
Hi Stuart,

Now that I've got a hold of skell and merge, I've made some progress on this JFFS2/NFS DHCP problem...

Stuart Hughes wrote:
Hi Michael,

You can do what you're trying to do without this patch, but it does need a config change. Here's what's happening:

In the BSP you have, the config is probably setup to use dhcp to get the IP address. You can verify this by running ./ltib -m config and checking in: Target System Configuration / Network setup / If the option: "get network parameters using dhcp" is checked then the network rc script will call ucdhcp. The problem you're runing into happens to me, that is if I use NFS deployment and forget to set the IP address to something static, then I get a load of "rpc 101..." as the IP address from dhcpd is different to the one the kernel got. I guess this maybe a bug in udhcpcd, not really sure.
Yes, my config was setup to use DHCP, so I first considered disabling this. But I don't want to set a static IP address, either, since it was already configured by the kernel. So I just disabled the whole section, "Enable Interface 0". Admittedly, my LTIB config is then misleading, since it looks like eth0 is not enabled.

I quite like your solution. I think though it might be possible to improve it. Rather than having to disable the network interface, it could be left on and in the network script you can test the deployment style and if it's NFS and dhcp is enabled, it could use your method instead to get the correctly assigned dynamic IP that the kernel has.
But it's this existing test for DEPLOYMENT_STYLE that's throwing me off. Because I'm trying to get NFS to work even when DEPLOYMENT_STYLE="jffs2". So really I'm trying to get NFS to work regardless of DEPLOYMENT_STYLE.

The patch below is my new suggestion. I use 'mount' to determine if / is mounted on NFS and change DEPLOYMENT_STYLE to NFS if it is, which will then skip DHCP. I think this achieves what you're suggesting. I like it more than checking eth0's IP address because if it boots into jffs2, it will still do a udhcpc DHCP request like the user configured in LTIB. But... * I'm unsure though whether my grep regex test for the mount rootfs line is appropriate in all cases. * maybe you prefer checking for an existing IP address to decide whether or not to do DHCP?

diff --exclude CVS --exclude .git -uNr skell-1.16/etc/rc.d/init.d/network skell-1.16.modified/etc/rc.d/init.d/network --- skell-1.16/etc/rc.d/init.d/network 2007-06-18 15:45:44.000000000 +0200 +++ skell-1.16.modified/etc/rc.d/init.d/network 2009-11-18 14:13:19.000000000 +0100
@@ -34,6 +34,15 @@
        sleep 2
    fi

+    # if rootfs is mounted via NFS, DEPLOYMENT_STYLE is NFS regardless
+    # whether LTIB built it for JFFS2.
+    rootmnt=`mount | grep "^/dev/root on / type" |\
+        sed -e "s/^.* type \([a-zA-Z0-9]*\).*/\1/"`;
+    if [ "$rootmnt" = "nfs" ]
+    then
+        DEPLOYMENT_STYLE=NFS;
+    fi
+
    if [ "$SYSCFG_IFACE0" = "y" ]
    then
        echo "Setting up networking on $INTERFACE0: "
The nice thing about this is it means you don't have to fiddle around with the configuration of the image, which means both jffs2 and NFS work without re-build/changes.
Yes, that's exactly what I'd like to achieve. With the patch above it works like this for me. I'm interested in your feedback.

thanks,
Michael

If you get what I mean maybe you could try this and send a patch? if not I could try to look at this when time permits.

Thanks for the patch.

Regards, Stuart

Michael Jones wrote:
Hi LTIBbers,

I have had the problem that I can't boot into the rootfs/ directory using NFS if LTIB built "rootfs/" destined for a jffs2 image, because of a problem with DHCP. I can only use NFS if I tell LTIB that I want Target image: "NFS only". But I would like to be able to always build the jffs2 image and still have the option of mounting via NFS.

Here's the problem: in my kernel config, I have CONFIG_IP_PNP_BOOTP=y. This is necessary for NFS to work, to get an IP address before trying to mount the root FS. After mounting rootfs/, if DEPLOYMENT_STYLE is anything but "NFS", udhcp is called to get an IP. Because my kernel config already got me an IP, this should just be a (safe) redundant step, but for some reason, my DHCP server gives me a _different_ IP address than I was given during kernel boot. As soon as my IP changes, my NFS is of course hosed.

With the assurance that my kernel will take care of configuring the IP address before mounting the RFS, I'm unchecking "Enable interface 0" in LTIB (SYSCFG_IFACE0=n), but then I get the misleading warning from "/etc/rc.d/init.d/network" that "Warning: no IPADDR is set, ...". I've added the following patch below to my skell package so I don't get this message unless "ifconfig" doesn't have an address for eth0.

I don't mean to complain of a problem with LTIB here, because it seems my DHCP server is misbehaving. Does anybody have a suggestion why the kernel DHCP and the udhcpc requests yield different addresses? Do you think my skell fix is hideous or problematic?

thanks,
Michael


$ diff -u rpm/BUILD/skell-1.16/etc/rc.d/init.d/network rootfs/etc/rc.d/init.d/network --- rpm/BUILD/skell-1.16/etc/rc.d/init.d/network 2007-06-18 15:45:44.000000000 +0200 +++ rootfs/etc/rc.d/init.d/network 2009-11-11 16:18:45.000000000 +0100
@@ -24,7 +24,9 @@
    #
    # set up the network interfaces
    #
-    if [ "$IPADDR0" = "" ]
+        ipaddr=`ifconfig eth0 | grep "\<inet addr\>" |\
+                sed -e "s/^.*\<inet addr:\([0-9.]*\) .*/\1/"`;
+    if [ "$IPADDR0" = "" ] && [ $ipaddr = "" ]
    then
        echo ""
echo "Warning: no IPADDR is set, please set this from the ltib"



MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, 
Hans-Joachim Reich




reply via email to

[Prev in Thread] Current Thread [Next in Thread]