Hello,
As I understand it, the -r option of udhcpc allows to tell the DHCP
client that it should try to use the given IP address and suggest it to
the DHCP server. However, it seems I can't get it to work (Busybox
1.18.4 is used) :
# udhcpc -r 192.168.0.51
udhcpc (v1.18.4) started
Sending discover for 192.168.0.51...
eth0: link up (100/Full)
Sending discover for 192.168.0.51...
Sending select for 192.168.0.55...
Lease of 192.168.0.55 obtained, lease time 43200
deleting routers
route: SIOCDELRT: No such process
adding dns 192.168.0.254
I have asked for 192.168.0.51, but I got 192.168.0.55, even if the
192.168.0.51 IP address is definitely available. The thing that sounds
strange is that udhcpc itself sends a select to the DHCP server with
the 192.168.0.55 IP address.
(Note: the IP address added in the "Sending discover for..." messages
as been added by me, trying to debug the issue).
Now, in the reception of the DHCP_OFFER, I have the impression that the
IP address that the user has passed as -r option is completely ignored.
So I tried to use the following patch :
--- busybox-1.18.4.orig/networking/udhcp/dhcpc.c 2011-03-13
02:45:40.000000000 +0100
+++ busybox-1.18.4/networking/udhcp/dhcpc.c 2011-08-02 18:03:32.419364336
+0200
@@ -1377,8 +1379,8 @@
/* it IS unaligned sometimes, don't "optimize"
*/
move_from_unaligned32(server_addr, temp);
/*xid = packet.xid; - already is */
- requested_ip = packet.yiaddr;
-
+ if (requested_ip == 0)
+ requested_ip = packet.yiaddr;
/* enter requesting state */
state = REQUESTING;
timeout = 0;
This should keep the IP address requested by the user on the command line.
It gives the following results :
# udhcpc -r 192.168.0.63
udhcpc (v1.18.4) started
Sending discover for 192.168.0.63...
eth0: link up (100/Full)
Sending discover for 192.168.0.63...
Sending select for 192.168.0.63...
Sending select for 192.168.0.63...
Sending select for 192.168.0.63...
Sending discover for 192.168.0.63...
Sending select for 192.168.0.63...
Lease of 192.168.0.63 obtained, lease time 43200
deleting routers
route: SIOCDELRT: No such process
adding dns 192.168.0.254
So it actually was able to get the 192.168.0.63, but it took a very
long amount of time: the client had to send multiple DHCP SELECT
queries before getting a reply from the server. A normal request with
no -r option passed is very quick, and a single DHCP SELECT query is
needed:
# udhcpc
udhcpc (v1.18.4) started
Sending discover for 0.0.0.0...
Sending select for 192.168.0.46...
Lease of 192.168.0.46 obtained, lease time 43200
deleting routers
route: SIOCDELRT: No such process
adding dns 192.168.0.254
And now, when trying to request an IP address that is actually used, I
would expect the DHCP client to give up with the suggested IP address
and use a dynamically allocated IP address. But udhcpc just keeps
trying with the suggested IP address:
# udhcpc -r 192.168.0.14
udhcpc (v1.18.4) started
Sending discover for 192.168.0.14...
Sending select for 192.168.0.14...
Sending select for 192.168.0.14...
Sending select for 192.168.0.14...
Sending discover for 192.168.0.14...
Sending select for 192.168.0.14...
Sending select for 192.168.0.14...
Sending select for 192.168.0.14...
Sending discover for 192.168.0.14...
Sending select for 192.168.0.14...
Sending select for 192.168.0.14...
Sending select for 192.168.0.14...
Sending discover for 192.168.0.14...
Sending select for 192.168.0.14...
Sending select for 192.168.0.14...
Sending select for 192.168.0.14...
Sending discover for 192.168.0.14...
Sending select for 192.168.0.14...
Sending select for 192.168.0.14...
Sending select for 192.168.0.14...
Sending discover for 192.168.0.14...
[...]
Is it my understanding of the -r option that is incorrect, or the
behavior of udhcpc ?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
