The attached patch enhances the kernel's DHCP client support (in
net/ipv4/ipconfig.c) to set the interface MTU if provided by the DHCP server.
Without this patch, it's difficult to netboot on a network that uses jumbo
frames. The patch is based on 2.6.10, but I'll update it to the latest
testing kernel if that would expedite its inclusion in the kernel.
More background: it's currently difficult to netboot on a jumbo frame network
because when clients try to mount the root partition, they are still
configured with a small MTU and therefore reject packets sent by the
jumbo-frame-enabled NFS server. Linux needs to set the client MTU before
mounting any NFS shares. Fortunately, the DHCP protocol already supports
setting the MTU; this patch just integrates that feature into the kernel.
Incidentally, ipconfig.c doesn't appear to do enough bounds checking on byte 1
of DHCP/BOOTP extension fields (the length field). It looks like a malicious
DHCP server could mess with kernel memory that way. I could try to fix the
hole, but maybe someone more experienced with this code would like to verify
there's a problem first.
Shane
Shane Hathaway <[email protected]> wrote:
>
> The attached patch enhances the kernel's DHCP client support (in
> net/ipv4/ipconfig.c) to set the interface MTU if provided by the DHCP server.
> Without this patch, it's difficult to netboot on a network that uses jumbo
> frames. The patch is based on 2.6.10, but I'll update it to the latest
> testing kernel if that would expedite its inclusion in the kernel.
Have you looked at using initramfs and running the DHCP client in
user space? You'll get a lot more freedom that way.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Herbert Xu wrote:
> Shane Hathaway <[email protected]> wrote:
>
>>The attached patch enhances the kernel's DHCP client support (in
>>net/ipv4/ipconfig.c) to set the interface MTU if provided by the DHCP server.
>>Without this patch, it's difficult to netboot on a network that uses jumbo
>>frames. The patch is based on 2.6.10, but I'll update it to the latest
>>testing kernel if that would expedite its inclusion in the kernel.
>
>
> Have you looked at using initramfs and running the DHCP client in
> user space? You'll get a lot more freedom that way.
Hey, that's a good idea. I'll explore it.
Shane
Followup to: <[email protected]>
By author: Herbert Xu <[email protected]>
In newsgroup: linux.dev.kernel
>
> Have you looked at using initramfs and running the DHCP client in
> user space? You'll get a lot more freedom that way.
>
Note that the klibc distribution already contains a working dhcp
client. The only thing missing is just "putting the backwards into
backwards compatible", i.e. handling *all* the (sometimes weird)
kernel behaviours for full compatibility.
-hpa
On Thursday 03 February 2005 06:47, Shane Hathaway wrote:
> The attached patch enhances the kernel's DHCP client support (in
> net/ipv4/ipconfig.c) to set the interface MTU if provided by the DHCP server.
> Without this patch, it's difficult to netboot on a network that uses jumbo
> frames. The patch is based on 2.6.10, but I'll update it to the latest
> testing kernel if that would expedite its inclusion in the kernel.
>
> More background: it's currently difficult to netboot on a jumbo frame network
> because when clients try to mount the root partition, they are still
> configured with a small MTU and therefore reject packets sent by the
> jumbo-frame-enabled NFS server. Linux needs to set the client MTU before
> mounting any NFS shares. Fortunately, the DHCP protocol already supports
> setting the MTU; this patch just integrates that feature into the kernel.
>
> Incidentally, ipconfig.c doesn't appear to do enough bounds checking on byte 1
> of DHCP/BOOTP extension fields (the length field). It looks like a malicious
> DHCP server could mess with kernel memory that way. I could try to fix the
> hole, but maybe someone more experienced with this code would like to verify
> there's a problem first.
Long term solution is to use approptiately configured initramfs or initrd image
and do above mentioned stuff in userspace.
--
vda
Hi Shane,
On Thursday 03 February 2005 05:47, Shane Hathaway wrote:
> The attached patch enhances the kernel's DHCP client support (in
> net/ipv4/ipconfig.c) to set the interface MTU if provided by the
> DHCP server. Without this patch, it's difficult to netboot on a
> network that uses jumbo frames. The patch is based on 2.6.10, but
> I'll update it to the latest testing kernel if that would expedite
> its inclusion in the kernel.
Well, I've been there before, and asked for exact the same back in
June 2003, but had much less luck, nobody of kernel fame even
responded:
http://marc.theaimsgroup.com/?l=linux-kernel&m=105624464918574&w=4
Only Ken Yap of etherboot fame told me:
> I have a feeling you will not get much sympathy for 2.[56] because
> there ipconfig in the kernel is deprecated in favour of userspace
> config from the initrd.
Well that's life.
For what is worth it, I ported my patch to current 2.6, which raised
some comments compared to yours:
- Is it really necessary to protect the dev_set_mtu call, since it is
just setting up the device?
- I prefer to call dev_set_mtu only, if a change mtu request is
sent..
- Are you sure, you got the endianess right?
Here's the "cost": ipconfig.o without my patch on x86:
3 .init.data 0000005a 00000000 00000000 00000220 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
4 .rodata.str1.1 000001a2 00000000 00000000 0000027a 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .rodata.str1.4 000003ad 00000000 00000000 0000041c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .init.text 00001a45 00000000 00000000 000007d0 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
With patch:
3 .init.data 0000005e 00000000 00000000 00000220 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
4 .rodata.str1.1 000001ab 00000000 00000000 0000027e 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .rodata.str1.4 000003e5 00000000 00000000 0000042c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .init.text 00001ab5 00000000 00000000 00000820 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
Difference: 181 Bytes (padding ignored)
The whole module takes about 9K, compared to dhcp in initrd, which
takes a few hundred K! Hmm.
> Incidentally, ipconfig.c doesn't appear to do enough bounds
> checking on byte 1 of DHCP/BOOTP extension fields (the length
> field). It looks like a malicious DHCP server could mess with
> kernel memory that way. I could try to fix the hole, but maybe
> someone more experienced with this code would like to verify
> there's a problem first.
That's an interesting question. Please keep me informed on any new
perceptions in this respect.
May the linux gods indulge on this topic one day or remove the
ipconfig module completely.
--- linux-2.6/net/ipv4/ipconfig.c.orig 2005-02-04 15:59:42.430518242 +0100
+++ linux-2.6/net/ipv4/ipconfig.c 2005-02-04 17:07:14.526384702 +0100
@@ -29,6 +29,10 @@
*
* Multiple Nameservers in /proc/net/pnp
* -- Josef Siemes <[email protected]>, Aug 2002
+ *
+ * Support for MTU selection via DHCP
+ * -- Hans-Peter Jansen <[email protected]>, June 2003
+ * redone for 2.6 in February 2005
*/
#include <linux/config.h>
@@ -151,6 +155,9 @@
/* Protocols supported by available interfaces */
static int ic_proto_have_if __initdata = 0;
+/* MTU of device (if requested) */
+static int ic_dev_mtu __initdata = 0;
+
#ifdef IPCONFIG_DYNAMIC
static DEFINE_SPINLOCK(ic_recv_lock);
static volatile int ic_got_reply __initdata = 0; /* Proto(s) that replied */
@@ -322,6 +329,12 @@
printk(KERN_ERR "IP-Config: Unable to set interface broadcast address (%d).\n", err);
return -1;
}
+ if (ic_dev_mtu) {
+ if ((err = dev_set_mtu(ic_dev, ic_dev_mtu)) < 0)
+ printk(KERN_ERR "IP-Config: Unable to set interface mtu to %d (%d).\n",
+ ic_dev_mtu, err);
+ /* Don't error out because set mtu failure, just notice the operator */
+ }
return 0;
}
@@ -609,6 +622,7 @@
12, /* Host name */
15, /* Domain name */
17, /* Boot path */
+ 26, /* MTU */
40, /* NIS domain name */
};
@@ -812,6 +826,9 @@
if (!root_server_path[0])
ic_bootp_string(root_server_path, ext+1, *ext, sizeof(root_server_path));
break;
+ case 26: /* MTU */
+ ic_dev_mtu = ntohs(*(u16 *)(ext+1));
+ break;
case 40: /* NIS Domain name (_not_ DNS) */
ic_bootp_string(system_utsname.domainname, ext+1, *ext, __NEW_UTS_LEN);
break;
@@ -1363,6 +1380,8 @@
*/
printk("IP-Config: Complete:");
printk("\n device=%s", ic_dev->name);
+ if (ic_dev_mtu)
+ printk(", mtu=%d", ic_dev_mtu);
printk(", addr=%u.%u.%u.%u", NIPQUAD(ic_myaddr));
printk(", mask=%u.%u.%u.%u", NIPQUAD(ic_netmask));
printk(", gw=%u.%u.%u.%u", NIPQUAD(ic_gateway));
Compile tested. Any takers?
Cheers,
Pete
On Fri, 4 Feb 2005, Hans-Peter Jansen wrote:
> On Thursday 03 February 2005 05:47, Shane Hathaway wrote:
> > The attached patch enhances the kernel's DHCP client support (in
> > net/ipv4/ipconfig.c) to set the interface MTU if provided by the
> > DHCP server. Without this patch, it's difficult to netboot on a
> > network that uses jumbo frames. The patch is based on 2.6.10, but
> > I'll update it to the latest testing kernel if that would expedite
> > its inclusion in the kernel.
What will this code do at the (increasingly common) misconfigured sites
- many places (hotels, airports, etc) return a MTU of 64... to which the
DHCP3 client faithfully attempts to set, only to receive:
SIOCSIFMTU: Invalid argument
And is one of the easiest issues I've had during my travels - thankfully
I don't do it all that often; trying to tell the helpdesk folk that
their DHCP server is handing out bogus DNS servers, MTU, even networks
is an exercise in futility.
--
Rick Nelson
"Absolutely nothing should be concluded from these figures except that
no conclusion can be drawn from them."
(By Joseph L. Brothers, Linux/PowerPC Project)
On Friday 04 February 2005 19:22, Richard A Nelson wrote:
>
> What will this code do at the (increasingly common) misconfigured
> sites - many places (hotels, airports, etc) return a MTU of 64...
> to which the DHCP3 client faithfully attempts to set, only to
> receive:
> SIOCSIFMTU: Invalid argument
Well, the ip auto configuration is mainly intended for diskless
setups, not something, one will use in an uncontrolled environment.
I doubt, it will behave different, as well as usual distribution
kernels will never enable this by default..
Pete
Hans-Peter Jansen wrote:
> On Thursday 03 February 2005 05:47, Shane Hathaway wrote:
>
>>The attached patch enhances the kernel's DHCP client support (in
>>net/ipv4/ipconfig.c) to set the interface MTU if provided by the
>>DHCP server. Without this patch, it's difficult to netboot on a
>>network that uses jumbo frames. The patch is based on 2.6.10, but
>>I'll update it to the latest testing kernel if that would expedite
>>its inclusion in the kernel.
>
>
> Well, I've been there before, and asked for exact the same back in
> June 2003, but had much less luck, nobody of kernel fame even
> responded:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=105624464918574&w=4
I wish I had found your patch before I went to the trouble of writing my
own! Yours is just as good as mine.
> For what is worth it, I ported my patch to current 2.6, which raised
> some comments compared to yours:
>
> - Is it really necessary to protect the dev_set_mtu call, since it is
> just setting up the device?
Without rtnl_shlock(), something complains about RTNL not being locked.
I don't know much beyond that.
> - I prefer to call dev_set_mtu only, if a change mtu request is
> sent..
Yes, I can see that. Either way is fine by me.
> - Are you sure, you got the endianess right?
On the MTU parameter? Yes, it's network byte order, big-endian.
> Here's the "cost": ipconfig.o without my patch on x86:
>
> 3 .init.data 0000005a 00000000 00000000 00000220 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 4 .rodata.str1.1 000001a2 00000000 00000000 0000027a 2**0
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 5 .rodata.str1.4 000003ad 00000000 00000000 0000041c 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 6 .init.text 00001a45 00000000 00000000 000007d0 2**4
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>
> With patch:
>
> 3 .init.data 0000005e 00000000 00000000 00000220 2**2
> CONTENTS, ALLOC, LOAD, RELOC, DATA
> 4 .rodata.str1.1 000001ab 00000000 00000000 0000027e 2**0
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 5 .rodata.str1.4 000003e5 00000000 00000000 0000042c 2**2
> CONTENTS, ALLOC, LOAD, READONLY, DATA
> 6 .init.text 00001ab5 00000000 00000000 00000820 2**4
> CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>
> Difference: 181 Bytes (padding ignored)
>
> The whole module takes about 9K, compared to dhcp in initrd, which
> takes a few hundred K! Hmm.
It's probably better to compare your patch with its apparent successor,
however. The tiny DHCP client in the klibc package already supports
setting the MTU.
> May the linux gods indulge on this topic one day or remove the
> ipconfig module completely.
A friend of mine just had the misfortune of running into the exact same
problem, but then he had the fortune of finding your patch. So at least
the curse has a temporary remedy. :-) The long-term solution is klibc,
I hope. klibc in initramfs could ease a lot of pain.
Shane
Hans-Peter Jansen <[email protected]> writes:
> Hi Shane,
>
> Difference: 181 Bytes (padding ignored)
>
> The whole module takes about 9K, compared to dhcp in initrd, which
> takes a few hundred K! Hmm.
And the kinit from the klibc package (A static executable that
does everything the kernel currently does for mounting root
including handling what ipconfig handles it in only 35K (uncompressed).
> That's an interesting question. Please keep me informed on any new
> perceptions in this respect.
>
> May the linux gods indulge on this topic one day or remove the
> ipconfig module completely.
Well that actually is the goal. A major problem is that there
are enough policy issues that the kernel simply cannot get it right,
for all users.
Eric