Re: avoiding unnecessary route deletion in rt_fixchange()
Yay, cool! Unless Garrett commits this in a few days, I will
on Friday. And yes, this fixes the "mysterious" problem when
gwroute was not allocated when adding the "default" route.
Thanks!
On Wed, Jul 18, 2001 at 03:43:41PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:
> As commented in defined in sys/net/route.c, rt_fixchange() has a bad
> effect, which would cause unnecessary route deletion:
>
> * Unfortunately, this has the obnoxious
> * property of also triggering for insertion /above/ a pre-existing network
> * route and clones. Sigh. This may be fixed some day.
>
> The effect has been even worse, because recent versions of route.c set
> the parent rtentry for cloned routes from an interface-direct route.
> For example, suppose that we have an interface "ne0" that has an IPv4
> subnet "10.0.0.0/24". Then we may have a cloned route like 10.0.0.1
> on the interface, whose parent route is 10.0.0.0/24 (to the interface
> ne0). Now, when we add the default route (i.e. 0.0.0.0/0),
> rt_fixchange() will remove the cloned route 10.0.0.1. The (bad) effect
> also prevents rt_setgate from configuring rt_gwroute, which would not
> be an intended behavior.
>
> As suggested in the comments to rt_fixchange(), we need stricter check
> in the function, to prevent unintentional route deletion. The
> attached is a proposed fix to this problem (for FreeBSD4-STABLE).
> Please review it, and merge it to the repository if acceptable.
>
> This fix will also solve the "IPV6 panic?" problem which was recently
> reported in this list.
>
> Thanks,
>
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> [EMAIL PROTECTED]
>
> *** route.c.orig Wed Jul 18 15:13:18 2001
> --- route.c Wed Jul 18 15:18:15 2001
> ***
> *** 726,734
>* network route and (cloned) host routes. For this reason, a simple check
>* of rt->rt_parent is insufficient; each candidate route must be tested
>* against the (mask, value) of the new route (passed as before in vp)
> ! * to see if the new route matches it. Unfortunately, this has the obnoxious
> ! * property of also triggering for insertion /above/ a pre-existing network
> ! * route and clones. Sigh. This may be fixed some day.
>*
>* XXX - it may be possible to do fixdelete() for changes and reserve this
>* routine just for adds. I'm not sure why I thought it was necessary to do
> --- 726,732
>* network route and (cloned) host routes. For this reason, a simple check
>* of rt->rt_parent is insufficient; each candidate route must be tested
>* against the (mask, value) of the new route (passed as before in vp)
> ! * to see if the new route matches it.
>*
>* XXX - it may be possible to do fixdelete() for changes and reserve this
>* routine just for adds. I'm not sure why I thought it was necessary to do
> ***
> *** 747,754
> struct rtfc_arg *ap = vp;
> struct rtentry *rt0 = ap->rt0;
> struct radix_node_head *rnh = ap->rnh;
> ! u_char *xk1, *xm1, *xk2;
> ! int i, len;
>
> #ifdef DEBUG
> if (rtfcdebug)
> --- 745,752
> struct rtfc_arg *ap = vp;
> struct rtentry *rt0 = ap->rt0;
> struct radix_node_head *rnh = ap->rnh;
> ! u_char *xk1, *xm1, *xk2, *xmp;
> ! int i, len, mlen;
>
> #ifdef DEBUG
> if (rtfcdebug)
> ***
> *** 781,786
> --- 779,806
> xk1 = (u_char *)rt_key(rt0);
> xm1 = (u_char *)rt_mask(rt0);
> xk2 = (u_char *)rt_key(rt);
> +
> + /* avoid applying a less specific route */
> + xmp = (u_char *)rt_mask(rt->rt_parent);
> + mlen = ((struct sockaddr *)rt_key(rt->rt_parent))->sa_len;
> + if (mlen > ((struct sockaddr *)rt_key(rt0))->sa_len) {
> + #ifdef DEBUG
> + if (rtfcdebug)
> + printf("rt_fixchange: inserting a less "
> +"specific route\n");
> + #endif
> + return 0;
> + }
> + for (i = rnh->rnh_treetop->rn_offset; i < mlen; i++) {
> + if ((xmp[i] & ~(xmp[i] ^ xm1[i])) != xmp[i]) {
> + #ifdef DEBUG
> + if (rtfcdebug)
> + printf("rt_fixchange: inserting a less "
> +"specific route\n");
> + #endif
> + return 0;
> + }
> + }
>
> for (i = rnh->rnh_treetop->rn_offset; i < len; i++) {
> if ((xk2[i] & xm1[i]) != xk1[i]) {
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
MPLS
Will MPLS and MPLS-TE (and MPLS VPL L2 and L3) be implemented under FreeBSD ? I know that Juniper has implemented them and whole bunch of other neat thing over FreeBSD and that the latest JUNOS is a somewhat modified FreeBSD 4.x Is anyone (or maybe Juniper ? :)) working on implementing this under FreeBSD ? Also when will AltQ be part of the FreeBSD system ? -- === Christophe Prevotaux Email: [EMAIL PROTECTED] HEXANET SARLURL: http://www.hexanet.fr/ Z.A Farman Sud Tel: +33 (0)3 26 79 30 05 9 rue Roland Coffignot Direct: +33 (0)3 26 79 08 02 BP415 Fax: +33 (0)3 26 79 30 06 51689 Reims Cedex 2 FRANCE === To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: natd and ICMP 3.4 packets
On Fri, Jul 13, 2001 at 04:48:03PM +0300, Ruslan Ermilov wrote:
> On Fri, Jul 13, 2001 at 04:18:05PM +0300, Ari Suutari wrote:
> > > >
> > > > Doesn't sound good that IP header with private IP address
> > > > gets sent to internet. - after all, the 195.168.3.210 host on internet
> > knows
> > > > nothing about 10.10.1.2...
> > > >
> > > We have discussed this before with Brian and Charles, and have come
> > > up to an agreement that FIREWALL should block these packets, not NAT.
> > >
> >
> > There must be something I don't understand now ? How is the host
> > on the internet now going to know that smaller MTU is required when
> > it sends packets to host inside nat'ed network ?
> >
> Give me a few days guys, OK? I will come up with a solution.
>
OK, as was promised... Please try the attached patch.
You'll have to recompile/install both libalias and natd.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: alias.c
===
RCS file: /home/ncvs/src/lib/libalias/alias.c,v
retrieving revision 1.29
diff -u -p -r1.29 alias.c
--- alias.c 2001/06/04 15:09:51 1.29
+++ alias.c 2001/07/18 12:37:25
@@ -518,6 +518,10 @@ IcmpAliasOut2(struct ip *pip)
struct udphdr *ud;
struct tcphdr *tc;
struct alias_link *link;
+u_short *sptr;
+int accumulate;
+struct in_addr alias_address;
+u_short alias_port, alias_id;
ic = (struct icmp *) ((char *) pip + (pip->ip_hl << 2));
ip = &ic->icmp_ip;
@@ -546,11 +550,6 @@ IcmpAliasOut2(struct ip *pip)
{
if (ip->ip_p == IPPROTO_UDP || ip->ip_p == IPPROTO_TCP)
{
-u_short *sptr;
-int accumulate;
-struct in_addr alias_address;
-u_short alias_port;
-
alias_address = GetAliasAddress(link);
alias_port = GetAliasPort(link);
@@ -565,18 +564,6 @@ IcmpAliasOut2(struct ip *pip)
accumulate -= alias_port;
ADJUST_CHECKSUM(accumulate, ic->icmp_cksum);
-/*
- * Alias address in IP header if it comes from the host
- * the original TCP/UDP packet was destined for.
- */
- if (pip->ip_src.s_addr == ip->ip_dst.s_addr) {
- DifferentialChecksum(&pip->ip_sum,
-(u_short *) &alias_address,
-(u_short *) &pip->ip_src,
-2);
- pip->ip_src = alias_address;
- }
-
/* Alias address and port number of original IP packet
fragment contained in ICMP data section */
ip->ip_dst = alias_address;
@@ -584,11 +571,6 @@ fragment contained in ICMP data section
}
else if (ip->ip_p == IPPROTO_ICMP)
{
-u_short *sptr;
-int accumulate;
-struct in_addr alias_address;
-u_short alias_id;
-
alias_address = GetAliasAddress(link);
alias_id = GetAliasPort(link);
@@ -603,23 +585,25 @@ fragment contained in ICMP data section
accumulate -= alias_id;
ADJUST_CHECKSUM(accumulate, ic->icmp_cksum);
-/*
- * Alias address in IP header if it comes from the host
- * the original ICMP message was destined for.
- */
- if (pip->ip_src.s_addr == ip->ip_dst.s_addr) {
- DifferentialChecksum(&pip->ip_sum,
-(u_short *) &alias_address,
-(u_short *) &pip->ip_src,
-2);
- pip->ip_src = alias_address;
- }
-
/* Alias address of original IP packet and sequence number of
embedded ICMP datagram */
ip->ip_dst = alias_address;
ic2->icmp_id = alias_id;
}
+
+/*
+ * Alias address in IP header.
+ * If the message is from an intermediate router,
+ * make it look as if it comes from the NAT box.
+ */
+ if (pip->ip_src.s_addr != ip->ip_dst.s_addr)
+ alias_address = FindAliasAddress(pip->ip_src);
+ DifferentialChecksum(&pip->ip_sum,
+(u_short *) &alias_address,
+(u_short *) &pip->ip_src,
+2);
+ pip->ip_src = alias_address;
+
return(PKT_ALIAS_OK);
}
return(PKT_ALIAS_IGNORED);
Re: IPV6 panic?
If memory serves me right, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI= ?= wrote: > The essential point of this problem is not in the IPv6 stack, but in > net/route.c. > > The attached patch (which you may already have seen) would be a > complete fix to this problem. Please try it. OK. I un-did your workaround, applied the patch you posted to -net, and am now building up a new kernel.stay tuned. Thanks! Bruce. PGP signature
Re: 802.1q and multicasting
The vlan driver doesn't set up the multicast filters correctly on the underlying interface. I've got a patch sitting in my CVS tree that I should probably just commit... Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: 802.1q and multicasting
Actually, I guess I *did* commit them, in -current. I will look at merging them next week. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: MPLS
Monsieur Prevotaux, As of now, I do not believe FreeBSD has MPLS implemented. there is always vlan tagging though (802.1q). maybe someone will implement it in 5.x. bruce "Christophe Prévotaux" wrote: > > Will MPLS and MPLS-TE (and MPLS VPL L2 and L3) be implemented > under FreeBSD ? > > I know that Juniper has implemented them and whole bunch of other > neat thing over FreeBSD and that the latest JUNOS is a somewhat modified > FreeBSD 4.x > > Is anyone (or maybe Juniper ? :)) working on implementing this under FreeBSD ? > > Also when will AltQ be part of the FreeBSD system ? > > -- > === > Christophe Prevotaux Email: [EMAIL PROTECTED] > HEXANET SARLURL: http://www.hexanet.fr/ > Z.A Farman Sud Tel: +33 (0)3 26 79 30 05 > 9 rue Roland Coffignot Direct: +33 (0)3 26 79 08 02 > BP415 Fax: +33 (0)3 26 79 30 06 > 51689 Reims Cedex 2 > FRANCE > === > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: MPLS
Christophe Privotaux wrote: > > Will MPLS and MPLS-TE (and MPLS VPL L2 and L3) be implemented > under FreeBSD ? have-you had a look at the archives ? ISTR a post where someone announced work with MPLS > > I know that Juniper has implemented them and whole bunch of other > neat thing over FreeBSD and that the latest JUNOS is a somewhat modified > FreeBSD 4.x I would be very surprised (but very happy) if Juniper would make its routing software public : this is the core of their business and where they have a competitive advantage when compared to other startups (this includes MPLS, which may be tied to their routing ASIC, and BGP-4) TfH > > Is anyone (or maybe Juniper ? :)) working on implementing this under FreeBSD ? > > Also when will AltQ be part of the FreeBSD system ? > -- Thierry Herbelot To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Adding new files to netinet
Hi, I'm currently trying to modify some files and add others in the /usr/src/sys/netinet directory. I'm following the procedures of kernel compilation but, apparently, the files I've added don't seem to have compiled. How do I know that they have been compiled successfuly and what else should I do apart from the sequence "config/make depend/make/make install/reboot"? Do I have to change any specific makefile? Where? I'm new to all this stuff. I would really appreciate if someone could give me some guidance here. Thanks, -- Marcelo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: MPLS
On Wed, Jul 18, 2001 at 12:35:25PM +0200, Christophe Prévotaux wrote: > I know that Juniper has implemented them and whole bunch of other > neat thing yes (including mpls). > over FreeBSD mostly wrong. > and that the latest JUNOS is a somewhat modified > FreeBSD 4.x wrong. -- Bill Fumerola - security yahoo / Yahoo! inc. - [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: avoiding unnecessary route deletion in rt_fixchange()
Hi,
Applied. I'll let you (and the list) know if I have any issues.
Thanks,
skd
On Wed, Jul 18, 2001 at 03:43:41PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:
> As commented in defined in sys/net/route.c, rt_fixchange() has a bad
> effect, which would cause unnecessary route deletion:
>
> * Unfortunately, this has the obnoxious
> * property of also triggering for insertion /above/ a pre-existing network
> * route and clones. Sigh. This may be fixed some day.
>
> The effect has been even worse, because recent versions of route.c set
> the parent rtentry for cloned routes from an interface-direct route.
> For example, suppose that we have an interface "ne0" that has an IPv4
> subnet "10.0.0.0/24". Then we may have a cloned route like 10.0.0.1
> on the interface, whose parent route is 10.0.0.0/24 (to the interface
> ne0). Now, when we add the default route (i.e. 0.0.0.0/0),
> rt_fixchange() will remove the cloned route 10.0.0.1. The (bad) effect
> also prevents rt_setgate from configuring rt_gwroute, which would not
> be an intended behavior.
>
> As suggested in the comments to rt_fixchange(), we need stricter check
> in the function, to prevent unintentional route deletion. The
> attached is a proposed fix to this problem (for FreeBSD4-STABLE).
> Please review it, and merge it to the repository if acceptable.
>
> This fix will also solve the "IPV6 panic?" problem which was recently
> reported in this list.
>
> Thanks,
>
> JINMEI, Tatuya
> Communication Platform Lab.
> Corporate R&D Center, Toshiba Corp.
> [EMAIL PROTECTED]
>
> *** route.c.orig Wed Jul 18 15:13:18 2001
> --- route.c Wed Jul 18 15:18:15 2001
> ***
> *** 726,734
>* network route and (cloned) host routes. For this reason, a simple check
>* of rt->rt_parent is insufficient; each candidate route must be tested
>* against the (mask, value) of the new route (passed as before in vp)
> ! * to see if the new route matches it. Unfortunately, this has the obnoxious
> ! * property of also triggering for insertion /above/ a pre-existing network
> ! * route and clones. Sigh. This may be fixed some day.
>*
>* XXX - it may be possible to do fixdelete() for changes and reserve this
>* routine just for adds. I'm not sure why I thought it was necessary to do
> --- 726,732
>* network route and (cloned) host routes. For this reason, a simple check
>* of rt->rt_parent is insufficient; each candidate route must be tested
>* against the (mask, value) of the new route (passed as before in vp)
> ! * to see if the new route matches it.
>*
>* XXX - it may be possible to do fixdelete() for changes and reserve this
>* routine just for adds. I'm not sure why I thought it was necessary to do
> ***
> *** 747,754
> struct rtfc_arg *ap = vp;
> struct rtentry *rt0 = ap->rt0;
> struct radix_node_head *rnh = ap->rnh;
> ! u_char *xk1, *xm1, *xk2;
> ! int i, len;
>
> #ifdef DEBUG
> if (rtfcdebug)
> --- 745,752
> struct rtfc_arg *ap = vp;
> struct rtentry *rt0 = ap->rt0;
> struct radix_node_head *rnh = ap->rnh;
> ! u_char *xk1, *xm1, *xk2, *xmp;
> ! int i, len, mlen;
>
> #ifdef DEBUG
> if (rtfcdebug)
> ***
> *** 781,786
> --- 779,806
> xk1 = (u_char *)rt_key(rt0);
> xm1 = (u_char *)rt_mask(rt0);
> xk2 = (u_char *)rt_key(rt);
> +
> + /* avoid applying a less specific route */
> + xmp = (u_char *)rt_mask(rt->rt_parent);
> + mlen = ((struct sockaddr *)rt_key(rt->rt_parent))->sa_len;
> + if (mlen > ((struct sockaddr *)rt_key(rt0))->sa_len) {
> + #ifdef DEBUG
> + if (rtfcdebug)
> + printf("rt_fixchange: inserting a less "
> +"specific route\n");
> + #endif
> + return 0;
> + }
> + for (i = rnh->rnh_treetop->rn_offset; i < mlen; i++) {
> + if ((xmp[i] & ~(xmp[i] ^ xm1[i])) != xmp[i]) {
> + #ifdef DEBUG
> + if (rtfcdebug)
> + printf("rt_fixchange: inserting a less "
> +"specific route\n");
> + #endif
> + return 0;
> + }
> + }
>
> for (i = rnh->rnh_treetop->rn_offset; i < len; i++) {
> if ((xk2[i] & xm1[i]) != xk1[i]) {
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
