Re: [PATCH] Configure MTU via kernel DHCP
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Configure MTU via kernel DHCP
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.data005a 0220 2**2 CONTENTS, ALLOC, LOAD, RELOC, DATA 4 .rodata.str1.1 01a2 027a 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .rodata.str1.4 03ad 041c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .init.text1a45 07d0 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE With patch: 3 .init.data005e 0220 2**2 CONTENTS, ALLOC, LOAD, RELOC, DATA 4 .rodata.str1.1 01ab 027e 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .rodata.str1.4 03e5 042c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .init.text1ab5 0820 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Configure MTU via kernel DHCP
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Configure MTU via kernel DHCP
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) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Configure MTU via kernel DHCP
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.data005a 0220 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
4 .rodata.str1.1 01a2 027a 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .rodata.str1.4 03ad 041c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .init.text1a45 07d0 2**4
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
With patch:
3 .init.data005e 0220 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
4 .rodata.str1.1 01ab 027e 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .rodata.str1.4 03e5 042c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .init.text1ab5 0820 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
@@ -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(syste
Re: [PATCH] Configure MTU via kernel DHCP
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Configure MTU via kernel DHCP
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Configure MTU via kernel DHCP
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Configure MTU via kernel DHCP
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Configure MTU via kernel DHCP
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
--- ipconfig.c.orig 2005-02-02 17:23:35.175853560 -0700
+++ ipconfig.c 2005-02-02 19:10:39.843155672 -0700
@@ -126,6 +126,7 @@
int ic_host_name_set __initdata = 0; /* Host name set by us? */
+u16 ic_mtu = 0; /* Interface MTU */
u32 ic_myaddr = INADDR_NONE; /* My IP address */
u32 ic_netmask = INADDR_NONE; /* Netmask for local subnet */
u32 ic_gateway = INADDR_NONE; /* Gateway IP address */
@@ -322,6 +323,13 @@
printk(KERN_ERR "IP-Config: Unable to set interface broadcast address (%d).\n", err);
return -1;
}
+ rtnl_shlock();
+ err = dev_set_mtu(ic_dev, ic_mtu);
+ rtnl_shunlock();
+ if (err < 0) {
+ printk(KERN_ERR "IP-Config: Unable to set interface MTU (%d).\n", err);
+ return -1;
+ }
return 0;
}
@@ -609,6 +617,7 @@
12, /* Host name */
15, /* Domain name */
17, /* Boot path */
+ 26, /* MTU */
40, /* NIS domain name */
};
@@ -812,6 +821,9 @@
if (!root_server_path[0])
ic_bootp_string(root_server_path, ext+1, *ext, sizeof(root_server_path));
break;
+ case 26: /* Interface MTU */
+ ic_mtu = (((u16) ext[1]) << 8) | ext[2];
+ break;
case 40: /* NIS Domain name (_not_ DNS) */
ic_bootp_string(system_utsname.domainname, ext+1, *ext, __NEW_UTS_LEN);
break;
@@ -1362,8 +1374,9 @@
* Clue in the operator.
*/
printk("IP-Config: Complete:");
- printk("\n device=%s", ic_dev->name);
- printk(", addr=%u.%u.%u.%u", NIPQUAD(ic_myaddr));
+ printk("\n device=%s", ic_dev->name);
+ printk(", mtu=%u", (unsigned int)ic_mtu);
+ printk(",\n 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));
printk(",\n host=%s, domain=%s, nis-domain=%s",
