Re: [PATCH 001/001] ipv4: enable use of 240/4 address space
On Fri, Jan 18, 2008 at 12:04:06AM +0100, Jan Engelhardt wrote: > > On Jan 7 2008 17:10, Vince Fuller wrote: > >--- net/ipv4/devinet.c.orig 2007-04-12 10:16:23.0 -0700 > >+++ net/ipv4/devinet.c 2008-01-07 16:55:59.0 -0800 > >@@ -594,6 +594,8 @@ static __inline__ int inet_abc_len(__be3 > > rc = 16; > > else if (IN_CLASSC(haddr)) > > rc = 24; > >+else if (IN_CLASSE(haddr)) > >+rc = 24; > > } > > > > return rc; > > Any particular reason why 24? Using the same default as old-style "class-C" seemed to be the most expedient thing to do. In normal practice, the mask should be explicitly configured so this case should not be frequently encountered. --Vince -- 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 001/001] ipv4: enable use of 240/4 address space
On Jan 7 2008 17:10, Vince Fuller wrote: >--- net/ipv4/devinet.c.orig2007-04-12 10:16:23.0 -0700 >+++ net/ipv4/devinet.c 2008-01-07 16:55:59.0 -0800 >@@ -594,6 +594,8 @@ static __inline__ int inet_abc_len(__be3 > rc = 16; > else if (IN_CLASSC(haddr)) > rc = 24; >+ else if (IN_CLASSE(haddr)) >+ rc = 24; > } > > return rc; Any particular reason why 24? -- 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 001/001] ipv4: enable use of 240/4 address space
On Jan 7 2008 17:10, Vince Fuller wrote: --- net/ipv4/devinet.c.orig2007-04-12 10:16:23.0 -0700 +++ net/ipv4/devinet.c 2008-01-07 16:55:59.0 -0800 @@ -594,6 +594,8 @@ static __inline__ int inet_abc_len(__be3 rc = 16; else if (IN_CLASSC(haddr)) rc = 24; + else if (IN_CLASSE(haddr)) + rc = 24; } return rc; Any particular reason why 24? -- 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 001/001] ipv4: enable use of 240/4 address space
On Fri, Jan 18, 2008 at 12:04:06AM +0100, Jan Engelhardt wrote: On Jan 7 2008 17:10, Vince Fuller wrote: --- net/ipv4/devinet.c.orig 2007-04-12 10:16:23.0 -0700 +++ net/ipv4/devinet.c 2008-01-07 16:55:59.0 -0800 @@ -594,6 +594,8 @@ static __inline__ int inet_abc_len(__be3 rc = 16; else if (IN_CLASSC(haddr)) rc = 24; +else if (IN_CLASSE(haddr)) +rc = 24; } return rc; Any particular reason why 24? Using the same default as old-style class-C seemed to be the most expedient thing to do. In normal practice, the mask should be explicitly configured so this case should not be frequently encountered. --Vince -- 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 001/001] ipv4: enable use of 240/4 address space
On Jan 11 2008 17:49, David Miller wrote: >From: Vince Fuller <[EMAIL PROTECTED]> >Date: Fri, 11 Jan 2008 09:29:15 -0800 > >> I leave it up to you, the developers, to decide if you want to use these >> patches. > >Vince, please just ignore these turkeys who are dismissing >your patch and respin it against current sources as I asked >of you. > >I'll apply it, immediately, because it is the only correct >course of action. I strongly agree. Linux should set standards, or at least help them become one. -- 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 001/001] ipv4: enable use of 240/4 address space
On Jan 11 2008 17:49, David Miller wrote: From: Vince Fuller [EMAIL PROTECTED] Date: Fri, 11 Jan 2008 09:29:15 -0800 I leave it up to you, the developers, to decide if you want to use these patches. Vince, please just ignore these turkeys who are dismissing your patch and respin it against current sources as I asked of you. I'll apply it, immediately, because it is the only correct course of action. I strongly agree. Linux should set standards, or at least help them become one. -- 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 001/001] ipv4: enable use of 240/4 address space
Hello. In article <[EMAIL PROTECTED]> (at Mon, 7 Jan 2008 17:10:57 -0800), Vince Fuller <[EMAIL PROTECTED]> says: > #define IN_MULTICAST_NET 0xF000 > > +#define IN_CLASSE(a) long int) (a)) & 0xf000) == 0xf000) > +#define IN_CLASSE_NET 0xff00 > +#define IN_CLASSE_NSHIFT8 > +#define IN_CLASSE_HOST (0x & ~IN_CLASSE_NET) > + > +/* > + * these are no longer used > #define IN_EXPERIMENTAL(a) long int) (a)) & 0xf000) == > 0xf000) > #define IN_BADCLASS(a) IN_EXPERIMENTAL((a)) > +*/ Please do not remove this, but have these instead: #define IN_EXPERIMENTAL(a) IN_CLASSE((a)) #define IN_BADCASS(a) IN_CLASSE((a)) And, I think it is good to remove BADCLASS() (inside #ifdef __KERNEL__ .. #endif) because we do not have its users any longer, right? Regards, --yoshfuji -- 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 001/001] ipv4: enable use of 240/4 address space
In article <[EMAIL PROTECTED]> (at Fri, 11 Jan 2008 17:48:57 -0800 (PST)), David Miller <[EMAIL PROTECTED]> says: > From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> > Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST) > > > There is no positive consesus on this draft > > at the intarea meeting in Vancouver, right? > > > > We cannot / should not enable that space until we have reached > > a consensus on it. > > This is so incredibly incorrect. > > There is consensus on making network stacks able to use this > address space. And that is all that the patch does. No, we did never make consensus on it. > The consensus is only missing on whether to make the address > space public or private. > > This is also clearly spelled out in the draft. > > It is important to get as large of a head start on this as > possible because of how long it takes to deploy something > like this. Okay, though I am afraid this space will not be used widely, we should be ready for it. I'll make some more comments on the patch itself from another point view. --yoshfuji -- 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 001/001] ipv4: enable use of 240/4 address space
From: Vince Fuller <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 09:29:15 -0800 > I leave it up to you, the developers, to decide if you want to use these > patches. Vince, please just ignore these turkeys who are dismissing your patch and respin it against current sources as I asked of you. I'll apply it, immediately, because it is the only correct course of action. Thanks a lot. -- 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 001/001] ipv4: enable use of 240/4 address space
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST) > There is no positive consesus on this draft > at the intarea meeting in Vancouver, right? > > We cannot / should not enable that space until we have reached > a consensus on it. This is so incredibly incorrect. There is consensus on making network stacks able to use this address space. And that is all that the patch does. The consensus is only missing on whether to make the address space public or private. This is also clearly spelled out in the draft. It is important to get as large of a head start on this as possible because of how long it takes to deploy something like this. -- 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 001/001] ipv4: enable use of 240/4 address space
On Fri, Jan 11, 2008 at 12:17:02PM +0100, Andi Kleen wrote: > Vince Fuller <[EMAIL PROTECTED]> writes: > > > from Vince Fuller <[EMAIL PROTECTED]> > > > > This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 > > (aka "class-E") address space as consistent with the Internet Draft > > draft-fuller-240space-00.txt. > > Wouldn't it be wise to at least wait for it becoming an RFC first? There is reasonable consensus on making use of 240/4; some applications, such as ISAKMP and automatic ipv6-to-IPv4 tunneling, still need to determine if they should treat the space as "public" or "private" but that shouldn't affect whether kernel support is added. Solaris recently added support for 240/4 and OSX already has it. I thought the Linux kernel developers might appreciate having patches to do likewise. I leave it up to you, the developers, to decide if you want to use these patches. --Vince -- 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 001/001] ipv4: enable use of 240/4 address space
In article <[EMAIL PROTECTED]> (at Fri, 11 Jan 2008 12:17:02 +0100), Andi Kleen <[EMAIL PROTECTED]> says: > Vince Fuller <[EMAIL PROTECTED]> writes: > > > from Vince Fuller <[EMAIL PROTECTED]> > > > > This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 > > (aka "class-E") address space as consistent with the Internet Draft > > draft-fuller-240space-00.txt. > > Wouldn't it be wise to at least wait for it becoming an RFC first? I do think so, too. There is no positive consesus on this draft at the intarea meeting in Vancouver, right? We cannot / should not enable that space until we have reached a consensus on it. --yoshfuji -- 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 001/001] ipv4: enable use of 240/4 address space
Vince Fuller <[EMAIL PROTECTED]> writes: > from Vince Fuller <[EMAIL PROTECTED]> > > This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 > (aka "class-E") address space as consistent with the Internet Draft > draft-fuller-240space-00.txt. Wouldn't it be wise to at least wait for it becoming an RFC first? -Andi -- 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 001/001] ipv4: enable use of 240/4 address space
Vince Fuller [EMAIL PROTECTED] writes: from Vince Fuller [EMAIL PROTECTED] This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 (aka class-E) address space as consistent with the Internet Draft draft-fuller-240space-00.txt. Wouldn't it be wise to at least wait for it becoming an RFC first? -Andi -- 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 001/001] ipv4: enable use of 240/4 address space
In article [EMAIL PROTECTED] (at Fri, 11 Jan 2008 12:17:02 +0100), Andi Kleen [EMAIL PROTECTED] says: Vince Fuller [EMAIL PROTECTED] writes: from Vince Fuller [EMAIL PROTECTED] This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 (aka class-E) address space as consistent with the Internet Draft draft-fuller-240space-00.txt. Wouldn't it be wise to at least wait for it becoming an RFC first? I do think so, too. There is no positive consesus on this draft at the intarea meeting in Vancouver, right? We cannot / should not enable that space until we have reached a consensus on it. --yoshfuji -- 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 001/001] ipv4: enable use of 240/4 address space
On Fri, Jan 11, 2008 at 12:17:02PM +0100, Andi Kleen wrote: Vince Fuller [EMAIL PROTECTED] writes: from Vince Fuller [EMAIL PROTECTED] This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 (aka class-E) address space as consistent with the Internet Draft draft-fuller-240space-00.txt. Wouldn't it be wise to at least wait for it becoming an RFC first? There is reasonable consensus on making use of 240/4; some applications, such as ISAKMP and automatic ipv6-to-IPv4 tunneling, still need to determine if they should treat the space as public or private but that shouldn't affect whether kernel support is added. Solaris recently added support for 240/4 and OSX already has it. I thought the Linux kernel developers might appreciate having patches to do likewise. I leave it up to you, the developers, to decide if you want to use these patches. --Vince -- 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 001/001] ipv4: enable use of 240/4 address space
From: Vince Fuller [EMAIL PROTECTED] Date: Fri, 11 Jan 2008 09:29:15 -0800 I leave it up to you, the developers, to decide if you want to use these patches. Vince, please just ignore these turkeys who are dismissing your patch and respin it against current sources as I asked of you. I'll apply it, immediately, because it is the only correct course of action. Thanks a lot. -- 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 001/001] ipv4: enable use of 240/4 address space
In article [EMAIL PROTECTED] (at Fri, 11 Jan 2008 17:48:57 -0800 (PST)), David Miller [EMAIL PROTECTED] says: From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] Date: Fri, 11 Jan 2008 21:41:20 +0900 (JST) There is no positive consesus on this draft at the intarea meeting in Vancouver, right? We cannot / should not enable that space until we have reached a consensus on it. This is so incredibly incorrect. There is consensus on making network stacks able to use this address space. And that is all that the patch does. No, we did never make consensus on it. The consensus is only missing on whether to make the address space public or private. This is also clearly spelled out in the draft. It is important to get as large of a head start on this as possible because of how long it takes to deploy something like this. Okay, though I am afraid this space will not be used widely, we should be ready for it. I'll make some more comments on the patch itself from another point view. --yoshfuji -- 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 001/001] ipv4: enable use of 240/4 address space
From: Vince Fuller <[EMAIL PROTECTED]> Date: Mon, 7 Jan 2008 17:10:57 -0800 > from Vince Fuller <[EMAIL PROTECTED]> > > This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 > (aka "class-E") address space as consistent with the Internet Draft > draft-fuller-240space-00.txt. > > Signed-off-by: Vince Fuller <[EMAIL PROTECTED]> There has been more than 90K worth of changes to the files you are changing since 2.6.20 It is generally unwise to submit patches against such old kernel versions, they rarely apply, so please respin your patch against more current sources. Please also remove the trailing whitespace, like the one found here: +#defineIN_CLASSE_HOST (0x & ~IN_CLASSE_NET) + +/* ^ Thanks. -- 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 001/001] ipv4: enable use of 240/4 address space
From: Vince Fuller [EMAIL PROTECTED] Date: Mon, 7 Jan 2008 17:10:57 -0800 from Vince Fuller [EMAIL PROTECTED] This set of diffs modify the 2.6.20 kernel to enable use of the 240/4 (aka class-E) address space as consistent with the Internet Draft draft-fuller-240space-00.txt. Signed-off-by: Vince Fuller [EMAIL PROTECTED] There has been more than 90K worth of changes to the files you are changing since 2.6.20 It is generally unwise to submit patches against such old kernel versions, they rarely apply, so please respin your patch against more current sources. Please also remove the trailing whitespace, like the one found here: +#defineIN_CLASSE_HOST (0x ~IN_CLASSE_NET) + +/* ^ Thanks. -- 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 001/001] ipv4: enable use of 240/4 address space
from Vince Fuller <[EMAIL PROTECTED]>
This set of diffs modify the 2.6.20 kernel to enable use of the 240/4
(aka "class-E") address space as consistent with the Internet Draft
draft-fuller-240space-00.txt.
Signed-off-by: Vince Fuller <[EMAIL PROTECTED]>
---
--- include/linux/in.h.orig 2007-04-12 10:16:20.0 -0700
+++ include/linux/in.h 2008-01-07 16:54:38.0 -0800
@@ -215,8 +215,16 @@ struct sockaddr_in {
#defineIN_MULTICAST(a) IN_CLASSD(a)
#define IN_MULTICAST_NET 0xF000
+#define IN_CLASSE(a) long int) (a)) & 0xf000) == 0xf000)
+#defineIN_CLASSE_NET 0xff00
+#defineIN_CLASSE_NSHIFT8
+#defineIN_CLASSE_HOST (0x & ~IN_CLASSE_NET)
+
+/*
+ * these are no longer used
#defineIN_EXPERIMENTAL(a) long int) (a)) & 0xf000) ==
0xf000)
#defineIN_BADCLASS(a) IN_EXPERIMENTAL((a))
+*/
/* Address to accept any incoming messages. */
#defineINADDR_ANY ((unsigned long int) 0x)
--- net/ipv4/devinet.c.orig 2007-04-12 10:16:23.0 -0700
+++ net/ipv4/devinet.c 2008-01-07 16:55:59.0 -0800
@@ -594,6 +594,8 @@ static __inline__ int inet_abc_len(__be3
rc = 16;
else if (IN_CLASSC(haddr))
rc = 24;
+ else if (IN_CLASSE(haddr))
+ rc = 24;
}
return rc;
--- net/ipv4/fib_frontend.c.orig2007-06-07 10:47:08.0 -0700
+++ net/ipv4/fib_frontend.c 2008-01-07 16:55:59.0 -0800
@@ -152,7 +152,7 @@ unsigned inet_addr_type(__be32 addr)
struct fib_result res;
unsigned ret = RTN_BROADCAST;
- if (ZERONET(addr) || BADCLASS(addr))
+ if (ZERONET(addr) || addr == INADDR_BROADCAST)
return RTN_BROADCAST;
if (MULTICAST(addr))
return RTN_MULTICAST;
--- net/ipv4/ipconfig.c.orig2007-04-12 10:16:23.0 -0700
+++ net/ipv4/ipconfig.c 2008-01-07 16:55:59.0 -0800
@@ -379,6 +379,8 @@ static int __init ic_defaults(void)
ic_netmask = htonl(IN_CLASSB_NET);
else if (IN_CLASSC(ntohl(ic_myaddr)))
ic_netmask = htonl(IN_CLASSC_NET);
+ else if (IN_CLASSE(ntohl(ic_myaddr)))
+ ic_netmask = htonl(IN_CLASSE_NET);
else {
printk(KERN_ERR "IP-Config: Unable to guess netmask for
address %u.%u.%u.%u\n",
NIPQUAD(ic_myaddr));
--- net/ipv4/route.c.orig 2007-04-12 10:16:24.0 -0700
+++ net/ipv4/route.c2008-01-07 16:55:59.0 -0800
@@ -1140,7 +1140,7 @@ void ip_rt_redirect(__be32 old_gw, __be3
return;
if (new_gw == old_gw || !IN_DEV_RX_REDIRECTS(in_dev)
- || MULTICAST(new_gw) || BADCLASS(new_gw) || ZERONET(new_gw))
+ || MULTICAST(new_gw) || new_gw == INADDR_BROADCAST ||
ZERONET(new_gw))
goto reject_redirect;
if (!IN_DEV_SHARED_MEDIA(in_dev)) {
@@ -1617,7 +1617,7 @@ static int ip_route_input_mc(struct sk_b
if (in_dev == NULL)
return -EINVAL;
- if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr) ||
+ if (MULTICAST(saddr) || saddr == INADDR_BROADCAST || LOOPBACK(saddr) ||
skb->protocol != htons(ETH_P_IP))
goto e_inval;
@@ -1935,7 +1935,7 @@ static int ip_route_input_slow(struct sk
by fib_lookup.
*/
- if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr))
+ if (MULTICAST(saddr) || saddr == INADDR_BROADCAST || LOOPBACK(saddr))
goto martian_source;
if (daddr == htonl(0x) || (saddr == 0 && daddr == 0))
@@ -1947,7 +1947,7 @@ static int ip_route_input_slow(struct sk
if (ZERONET(saddr))
goto martian_source;
- if (BADCLASS(daddr) || ZERONET(daddr) || LOOPBACK(daddr))
+ if (ZERONET(daddr) || LOOPBACK(daddr))
goto martian_destination;
/*
@@ -2171,7 +2171,7 @@ static inline int __mkroute_output(struc
res->type = RTN_BROADCAST;
else if (MULTICAST(fl->fl4_dst))
res->type = RTN_MULTICAST;
- else if (BADCLASS(fl->fl4_dst) || ZERONET(fl->fl4_dst))
+ else if (ZERONET(fl->fl4_dst))
return -EINVAL;
if (dev_out->flags & IFF_LOOPBACK)
@@ -2391,7 +2391,7 @@ static int ip_route_output_slow(struct r
if (oldflp->fl4_src) {
err = -EINVAL;
if (MULTICAST(oldflp->fl4_src) ||
- BADCLASS(oldflp->fl4_src) ||
+ oldflp->fl4_src == INADDR_BROADCAST ||
ZERONET(oldflp->fl4_src))
goto out;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
[PATCH 001/001] ipv4: enable use of 240/4 address space
from Vince Fuller [EMAIL PROTECTED]
This set of diffs modify the 2.6.20 kernel to enable use of the 240/4
(aka class-E) address space as consistent with the Internet Draft
draft-fuller-240space-00.txt.
Signed-off-by: Vince Fuller [EMAIL PROTECTED]
---
--- include/linux/in.h.orig 2007-04-12 10:16:20.0 -0700
+++ include/linux/in.h 2008-01-07 16:54:38.0 -0800
@@ -215,8 +215,16 @@ struct sockaddr_in {
#defineIN_MULTICAST(a) IN_CLASSD(a)
#define IN_MULTICAST_NET 0xF000
+#define IN_CLASSE(a) long int) (a)) 0xf000) == 0xf000)
+#defineIN_CLASSE_NET 0xff00
+#defineIN_CLASSE_NSHIFT8
+#defineIN_CLASSE_HOST (0x ~IN_CLASSE_NET)
+
+/*
+ * these are no longer used
#defineIN_EXPERIMENTAL(a) long int) (a)) 0xf000) ==
0xf000)
#defineIN_BADCLASS(a) IN_EXPERIMENTAL((a))
+*/
/* Address to accept any incoming messages. */
#defineINADDR_ANY ((unsigned long int) 0x)
--- net/ipv4/devinet.c.orig 2007-04-12 10:16:23.0 -0700
+++ net/ipv4/devinet.c 2008-01-07 16:55:59.0 -0800
@@ -594,6 +594,8 @@ static __inline__ int inet_abc_len(__be3
rc = 16;
else if (IN_CLASSC(haddr))
rc = 24;
+ else if (IN_CLASSE(haddr))
+ rc = 24;
}
return rc;
--- net/ipv4/fib_frontend.c.orig2007-06-07 10:47:08.0 -0700
+++ net/ipv4/fib_frontend.c 2008-01-07 16:55:59.0 -0800
@@ -152,7 +152,7 @@ unsigned inet_addr_type(__be32 addr)
struct fib_result res;
unsigned ret = RTN_BROADCAST;
- if (ZERONET(addr) || BADCLASS(addr))
+ if (ZERONET(addr) || addr == INADDR_BROADCAST)
return RTN_BROADCAST;
if (MULTICAST(addr))
return RTN_MULTICAST;
--- net/ipv4/ipconfig.c.orig2007-04-12 10:16:23.0 -0700
+++ net/ipv4/ipconfig.c 2008-01-07 16:55:59.0 -0800
@@ -379,6 +379,8 @@ static int __init ic_defaults(void)
ic_netmask = htonl(IN_CLASSB_NET);
else if (IN_CLASSC(ntohl(ic_myaddr)))
ic_netmask = htonl(IN_CLASSC_NET);
+ else if (IN_CLASSE(ntohl(ic_myaddr)))
+ ic_netmask = htonl(IN_CLASSE_NET);
else {
printk(KERN_ERR IP-Config: Unable to guess netmask for
address %u.%u.%u.%u\n,
NIPQUAD(ic_myaddr));
--- net/ipv4/route.c.orig 2007-04-12 10:16:24.0 -0700
+++ net/ipv4/route.c2008-01-07 16:55:59.0 -0800
@@ -1140,7 +1140,7 @@ void ip_rt_redirect(__be32 old_gw, __be3
return;
if (new_gw == old_gw || !IN_DEV_RX_REDIRECTS(in_dev)
- || MULTICAST(new_gw) || BADCLASS(new_gw) || ZERONET(new_gw))
+ || MULTICAST(new_gw) || new_gw == INADDR_BROADCAST ||
ZERONET(new_gw))
goto reject_redirect;
if (!IN_DEV_SHARED_MEDIA(in_dev)) {
@@ -1617,7 +1617,7 @@ static int ip_route_input_mc(struct sk_b
if (in_dev == NULL)
return -EINVAL;
- if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr) ||
+ if (MULTICAST(saddr) || saddr == INADDR_BROADCAST || LOOPBACK(saddr) ||
skb-protocol != htons(ETH_P_IP))
goto e_inval;
@@ -1935,7 +1935,7 @@ static int ip_route_input_slow(struct sk
by fib_lookup.
*/
- if (MULTICAST(saddr) || BADCLASS(saddr) || LOOPBACK(saddr))
+ if (MULTICAST(saddr) || saddr == INADDR_BROADCAST || LOOPBACK(saddr))
goto martian_source;
if (daddr == htonl(0x) || (saddr == 0 daddr == 0))
@@ -1947,7 +1947,7 @@ static int ip_route_input_slow(struct sk
if (ZERONET(saddr))
goto martian_source;
- if (BADCLASS(daddr) || ZERONET(daddr) || LOOPBACK(daddr))
+ if (ZERONET(daddr) || LOOPBACK(daddr))
goto martian_destination;
/*
@@ -2171,7 +2171,7 @@ static inline int __mkroute_output(struc
res-type = RTN_BROADCAST;
else if (MULTICAST(fl-fl4_dst))
res-type = RTN_MULTICAST;
- else if (BADCLASS(fl-fl4_dst) || ZERONET(fl-fl4_dst))
+ else if (ZERONET(fl-fl4_dst))
return -EINVAL;
if (dev_out-flags IFF_LOOPBACK)
@@ -2391,7 +2391,7 @@ static int ip_route_output_slow(struct r
if (oldflp-fl4_src) {
err = -EINVAL;
if (MULTICAST(oldflp-fl4_src) ||
- BADCLASS(oldflp-fl4_src) ||
+ oldflp-fl4_src == INADDR_BROADCAST ||
ZERONET(oldflp-fl4_src))
goto out;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
