I wonder why there is no feedback to the sugested DHCP patch to
linux/net/ipv4/ipconfig.c Am I wrong with the interpretation of
RFC2131 section about the contents of a clients DHCPDISCOVER
packet? If not I would assume that the behaviour of the kernels
DHCP should be changed.
Thanks,
Marcel
the original mail:
http://lkml.org/lkml/2008/2/21/171
====== original patch =========
This patch fixes a DHCP issue of the kernel: some DHCP servers
(i.e. in the Linksys WRT54Gv5) are very strict about the contents
of the DHCPDISCOVER packet they receive from clients. Table 5 in RFC2131
page 36 requests the fields 'ciaddr' and 'siaddr' MUST be set to '0'.
These DHCP servers ignore Linux kernel's DHCP discovery packets with these two
fields set to '255.255.255.255' (in contrast to popular DHCP clients, such as
'dhclient' or 'udhcpc'). This leads to a not booting system.
I tested this on a ARM embedded device mounting rootfs over NFS obtaining
its IP from a Linksys WRT54Gv5 Router running VxWorks and a PC based Server
running a Linux. Changing the two fields to '0.0.0.0' worked.
Please CC me personaly when answering this message.
Thanks,
Marcel
--- linux-2.6.24.2/net/ipv4/ipconfig.c 2008-02-21 15:27:47.250890963 +0100
+++ linux/net/ipv4/ipconfig.c 2008-02-21 15:36:12.686735925 +0100
@@ -29,6 +29,10 @@
*
* Multiple Nameservers in /proc/net/pnp
* -- Josef Siemes <[email protected]>, Aug 2002
+ *
+ * Bugfix: Not getting an IP from some DHCP servers: RFC2131 page 36
+ * Table 5 requests DHCPDISCOVER fields ciaddr and siaddr MUST be '0'.
+ * -- [email protected]
*/
#include <linux/types.h>
@@ -103,6 +107,7 @@
- '3' from resolv.h */
#define NONE __constant_htonl(INADDR_NONE)
+#define ZERO __constant_htonl(((unsigned long int) 0x00000000))
/*
* Public IP configuration
@@ -740,8 +745,8 @@
b->htype = dev->type; /* can cause undefined behavior */
}
b->hlen = dev->addr_len;
- b->your_ip = NONE;
- b->server_ip = NONE;
+ b->your_ip = ZERO;
+ b->server_ip = ZERO;
memcpy(b->hw_addr, dev->dev_addr, dev->addr_len);
b->secs = htons(jiffies_diff / HZ);
b->xid = d->xid;
--
Marcel Wappler
Bridgeco AG
CH-8600 D?bendorf
Switzerland
Wappler Marcel wrote:
> --- linux-2.6.24.2/net/ipv4/ipconfig.c 2008-02-21 15:27:47.250890963 +0100
> +++ linux/net/ipv4/ipconfig.c 2008-02-21 15:36:12.686735925 +0100
> @@ -29,6 +29,10 @@
> *
> * Multiple Nameservers in /proc/net/pnp
> * -- Josef Siemes <[email protected]>, Aug 2002
> + *
> + * Bugfix: Not getting an IP from some DHCP servers: RFC2131 page 36
> + * Table 5 requests DHCPDISCOVER fields ciaddr and siaddr MUST be '0'.
> + * -- [email protected]
> */
Please don't add changelogs to source files, git keeps track of
them.
> #include <linux/types.h>
> @@ -103,6 +107,7 @@
> - '3' from resolv.h */
>
> #define NONE __constant_htonl(INADDR_NONE)
> +#define ZERO __constant_htonl(((unsigned long int) 0x00000000))
This should probably use INADDR_ANY.
-----Original Message-----
>> #include <linux/types.h>
>> @@ -103,6 +107,7 @@
>> - '3' from resolv.h */
>>
>> #define NONE __constant_htonl(INADDR_NONE)
>> +#define ZERO __constant_htonl(((unsigned long int) 0x00000000))
>This should probably use INADDR_ANY.
My first try went in this direction. But at a second look I thought
that the names ANY (255.255.255.255) and NONE (0.0.0.0) are indirect
leading to confusion. The interpretation of the zero addresses in
the DHCPDISCOVER packet is in the kind of 'no address' and not of
'any addressee'. So the meaning and usage of INADDR_ANY and ZERO
may be totally different in this file.
In my opinion it is necessary to distinguish between INADDR_ANY
and the ZERO address which ist requested to be in the DHCPDISCOVER
packet.
Marcel
--
Marcel Wappler
Bridgeco AG
CH-8600 D?bendorf
Switzerland
On Wed, 27 Feb 2008 14:11:55 +0100
"Wappler Marcel" <[email protected]> wrote:
> -----Original Message-----
> >> #include <linux/types.h>
> >> @@ -103,6 +107,7 @@
> >> - '3' from resolv.h */
> >>
> >> #define NONE __constant_htonl(INADDR_NONE)
> >> +#define ZERO __constant_htonl(((unsigned long int) 0x00000000))
> >This should probably use INADDR_ANY.
> My first try went in this direction. But at a second look I thought
> that the names ANY (255.255.255.255) and NONE (0.0.0.0) are indirect
> leading to confusion. The interpretation of the zero addresses in
> the DHCPDISCOVER packet is in the kind of 'no address' and not of
> 'any addressee'. So the meaning and usage of INADDR_ANY and ZERO
> may be totally different in this file.
> In my opinion it is necessary to distinguish between INADDR_ANY
> and the ZERO address which ist requested to be in the DHCPDISCOVER
> packet.
>
Just delete the lines and the address will be zero because of
earlier memset().
-----Original Message-----
>> In my opinion it is necessary to distinguish between INADDR_ANY and
>> the ZERO address which ist requested to be in the DHCPDISCOVER packet.
>Just delete the lines and the address will be zero because of earlier memset().
>From my personal point of view it is important to document the requirement of the
two addresses to be 0.0.0.0 either through the code itself or through a comment
which states clear the side effect of memset'ting the structure.
Both roads lead to Rome :-)
Marcel
--
Marcel Wappler
Bridgeco AG
CH-8600 D?bendorf
Switzerland
From: "Wappler Marcel" <[email protected]>
Date: Wed, 27 Feb 2008 13:23:48 +0100
> I wonder why there is no feedback to the sugested DHCP patch to
> linux/net/ipv4/ipconfig.c
I just haven't gotten around to it because I have been
travelling, seeing doctors, and generally being backlogged.
Please be patient.