From nobody@FreeBSD.org  Sun Jan  4 12:15:57 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 6CAF1106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Sun,  4 Jan 2009 12:15:57 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 50C418FC08
	for <freebsd-gnats-submit@FreeBSD.org>; Sun,  4 Jan 2009 12:15:57 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n04CFvRx089037
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 4 Jan 2009 12:15:57 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n04CFveA089036;
	Sun, 4 Jan 2009 12:15:57 GMT
	(envelope-from nobody)
Message-Id: <200901041215.n04CFveA089036@www.freebsd.org>
Date: Sun, 4 Jan 2009 12:15:57 GMT
From: Luiz Otavio O Souza <loos.br@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [patch] ppp fail to correctly set routes
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         130159
>Category:       bin
>Synopsis:       [patch] ppp(8) fails to correctly set routes
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    brian
>State:          patched
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jan 04 12:20:03 UTC 2009
>Closed-Date:    
>Last-Modified:  Tue Jan 05 14:10:49 UTC 2010
>Originator:     Luiz Otavio O Souza
>Release:        7_STABLE
>Organization:
>Environment:
FreeBSD server.rede.int.br 7.0-STABLE FreeBSD 7.0-STABLE #1: Tue Jul  8 22:05:33 BRT 2008     root@server.rede.int.br:/usr/src/sys/i386/compile/FW  i386

>Description:
When ppp is used on server side, it is mangling the route table,
preventing connections from work.

When ppp receive and accept a new connection (after the protocol
handshake) it allocate a new tun interface and set the connection IP on
this interface. Until here everything is ok, even the route to this new
connection is correct (the route is inserted when ppp set an ip on tun).

But then the ppp tries to set the correct mtu on interface (need by pppoe
and others protocols - l2tp). This is done on rtUpdate() and the actual
code does not set the interface on route message and this breaks the
route (that was correct).

This patch fix this and fix another two ppp pr: kern/125079 and
kern/122068 (and may be bin/126892).
>How-To-Repeat:
Any ppp server config is generating bad routes at connection
>Fix:
apply this patch

Patch attached with submission follows:

diff -u ipcp.c.orig ipcp.c
--- ipcp.c.orig	2005-01-27 12:09:33.000000000 -0200
+++ ipcp.c	2008-12-02 19:12:49.000000000 -0200
@@ -690,7 +690,7 @@
   if (bundle->ncp.cfg.sendpipe > 0 || bundle->ncp.cfg.recvpipe > 0) {
     ncprange_getsa(&myrange, &ssgw, &ssmask);
     ncpaddr_getsa(&hisncpaddr, &ssdst);
-    rt_Update(bundle, sadst, sagw, samask);
+    rt_Update(bundle, sadst, sagw, samask, NULL, NULL);
   }
 
   if (Enabled(bundle, OPT_SROUTES))
diff -ur ipv6cp.c.orig ipv6cp.c
--- ipv6cp.c.orig	2005-01-27 12:09:33.000000000 -0200
+++ ipv6cp.c	2008-12-02 19:12:58.000000000 -0200
@@ -245,7 +245,7 @@
       ncpaddr_getsa(&ipv6cp->hisaddr, &ssdst);
     else
       sadst = NULL;
-    rt_Update(bundle, sadst, sagw, samask);
+    rt_Update(bundle, sadst, sagw, samask, NULL, NULL);
   }
 
   if (Enabled(bundle, OPT_SROUTES))
diff -ur route.c.orig route.c
--- route.c.orig	2005-01-10 09:12:36.000000000 -0200
+++ route.c	2008-12-03 10:09:09.000000000 -0200
@@ -524,7 +524,8 @@
                    " mtu %lu\n", rtm->rtm_index, Index2Nam(rtm->rtm_index),
                    ncprange_ntoa(&dst), bundle->iface->mtu);
       }
-      rt_Update(bundle, sa[RTAX_DST], sa[RTAX_GATEWAY], sa[RTAX_NETMASK]);
+      rt_Update(bundle, sa[RTAX_DST], sa[RTAX_GATEWAY], sa[RTAX_NETMASK],
+                sa[RTAX_IFP], sa[RTAX_IFA]);
     }
   }
 
@@ -862,7 +863,8 @@
 
 void
 rt_Update(struct bundle *bundle, const struct sockaddr *dst,
-          const struct sockaddr *gw, const struct sockaddr *mask)
+          const struct sockaddr *gw, const struct sockaddr *mask,
+          const struct sockaddr *ifp, const struct sockaddr *ifa)
 {
   struct ncprange ncpdst;
   struct rtmsg rtmes;
@@ -909,6 +911,13 @@
     p += memcpy_roundup(p, mask, mask->sa_len);
   }
 
+  if (ifp && ifp->sa_family == AF_LINK && ifa) {
+    rtmes.m_rtm.rtm_addrs |= RTA_IFP;
+    p += memcpy_roundup(p, ifp, ifp->sa_len);
+    rtmes.m_rtm.rtm_addrs |= RTA_IFA;
+    p += memcpy_roundup(p, ifa, ifa->sa_len);
+  }
+
   rtmes.m_rtm.rtm_msglen = p - (char *)&rtmes;
 
   wb = ID0write(s, &rtmes, rtmes.m_rtm.rtm_msglen);
diff -ur route.h.orig route.h
--- route.h.orig	2001-08-15 23:01:05.000000000 -0300
+++ route.h	2008-12-03 10:07:30.000000000 -0200
@@ -70,4 +70,5 @@
 extern int rt_Set(struct bundle *, int, const struct ncprange *,
                   const struct ncpaddr *, int, int);
 extern void rt_Update(struct bundle *, const struct sockaddr *,
+                      const struct sockaddr *, const struct sockaddr *,
                       const struct sockaddr *, const struct sockaddr *);


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sun Jan 4 15:25:14 UTC 2009 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=130159 

From: Brett Glass <brett@lariat.net>
To: bug-followup@FreeBSD.org, loos.br@gmail.com
Cc:  
Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes
Date: Mon, 23 Mar 2009 11:48:50 -0600

 Patch appears to work properly. Please commit.
 

From: Brett Glass <brett@lariat.net>
To: bug-followup@FreeBSD.org, loos.br@gmail.com
Cc:  
Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes
Date: Sun, 12 Apr 2009 18:41:27 -0600

 Note: With the patch as written, the "gateway" (G) flag is set in 
 the routing table entry. This does not seem to cause problems, but 
 the flag should not be set because the "tun" interface is acting as 
 a bridge, not a gateway.
 

From: "Luiz Otavio O Souza" <loos.br@gmail.com>
To: "Qing Li" <qingli@freebsd.org>,
	"Brett Glass" <brett@lariat.net>,
	<bug-followup@FreeBSD.org>
Cc:  
Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes
Date: Mon, 13 Apr 2009 09:01:21 -0300

 > Note: With the patch as written, the "gateway" (G) flag is set in the 
 > routing table entry. This does not seem to cause problems, but the flag 
 > should not be set because the "tun" interface is acting as a bridge, not a 
 > gateway.
 
 Brett,
 
 This patch doesn't fix or change the gateway flag, it only set the interface 
 in route update message.
 
 The gateway problem was fixed in r186308 by Qing Li 
 (http://svn.freebsd.org/viewvc/base/head/usr.sbin/ppp/route.c?sortdir=down&r1=186119&r2=186308&sortby=rev 
  - check the commit log)
 
 Thanks,
 Luiz 
 

From: Brett Glass <brett@lariat.net>
To: "Luiz Otavio O Souza" <loos.br@gmail.com>, "Qing Li" <qingli@freebsd.org>,
        <bug-followup@freebsd.org>
Cc:  
Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes
Date: Mon, 13 Apr 2009 08:20:40 -0600

 At 06:01 AM 4/13/2009, Luiz Otavio O Souza wrote:
 
 >>Note: With the patch as written, the "gateway" (G) flag is set in 
 >>the routing table entry. This does not seem to cause problems, 
 >>but the flag should not be set because the "tun" interface is 
 >>acting as a bridge, not a gateway.
 >
 >Brett,
 >
 >This patch doesn't fix or change the gateway flag, it only set the 
 >interface in route update message.
 >
 >The gateway problem was fixed in r186308 by Qing Li 
 >(http://svn.freebsd.org/viewvc/base/head/usr.sbin/ppp/route.c?sortdir=down&r1=186119&r2=186308&sortby=rev 
 >- check the commit log)
 >
 >Thanks,
 >Luiz
 
 Luiz, Qing Li's patch must not have made it into 7.1-RELEASE, 
 because I had to apply it manually. All three patches (your two 
 plus Qing Li's) should be committed and MFCed before 7.2-RELEASE, 
 because we (and others, I'm sure) really need PPP to work properly.
 
 --Brett Glass
 
 
 

From: Brett Glass <brett@lariat.net>
To: "Luiz Otavio O Souza" <loos.br@gmail.com>, "Qing Li" <qingli@freebsd.org>,
        <bug-followup@freebsd.org>
Cc:  
Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes
Date: Mon, 13 Apr 2009 08:27:08 -0600

 P.S. -- I am still seeing the gateway flag on PPP interfaces after 
 installing Qing Li's patch. Here is the output of "netstat -ran" 
 (note the bottom entries):
 
 Internet:
 Destination        Gateway            Flags    Refs      Use  Netif Expire
 default            66.119.58.1        UGS         0      488    xl0
 66.119.58.0/24     link#1             UC          0        0    xl0
 66.119.58.1        00:02:b3:66:03:63  UHLW        2        0    xl0   1198
 66.119.58.13       88:17:20:22:38:11  UHLW        1       97    xl0   1102
 66.119.58.254      00:02:b3:66:03:63  UHLW        1       63    xl0    921
 127.0.0.1          127.0.0.1          UH          0       34    lo0
 172.17.0.0/16      link#2             UC          0        0    dc0
 172.17.0.2/32      link#2             UC          0        0    dc0
 172.17.0.3/32      link#2             UC          0        0    dc0
 172.17.0.4/32      link#2             UC          0        0    dc0
 172.17.2.53        00:60:b3:5e:20:bb  UHLW        1      131    dc0    994
 172.17.250.21      00:19:3b:80:36:68  UHLW        1        2    dc0   1093
 172.17.250.22      00:19:3b:80:37:c6  UHLW        1     2035    dc0   1163
 172.17.250.23      00:19:3b:80:37:c2  UHLW        1        2    dc0   1128
 172.18.0.1         172.18.0.1         UH          2        0    lo0
 172.18.5.1         172.18.0.1         UGH         0      128   tun0
 172.18.217.33      172.18.0.1         UGH         0      596   tun2
 172.18.217.62      172.18.0.1         UGH         0       18   tun1
 
 The last two entries are PPTP sessions. They should say "UH", not "UGH".
 
 --Brett
 
Responsible-Changed-From-To: freebsd-net->bz 
Responsible-Changed-By: bz 
Responsible-Changed-When: Mon Apr 13 17:30:40 UTC 2009 
Responsible-Changed-Why:  
I promised re@ to look but I cannot promise that it'll make 7.2-R. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=130159 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/130159: commit references a PR
Date: Mon, 13 Apr 2009 20:46:06 +0000 (UTC)

 Author: bz
 Date: Mon Apr 13 20:19:28 2009
 New Revision: 191014
 URL: http://svn.freebsd.org/changeset/base/191014
 
 Log:
   MFC r186308 by qingli:
   
     The ppp application relies on the if_tun interface to properly
     install a ptp host route between the end points. The ppp module
     upates this router based on user configuration later on. The
     rt_Update() seems to always set the RTF_GATEWAY flag, which is
     broken.
   
   PR:		bin/130159
   Approved by:	re (kensmith)
 
 Modified:
   stable/7/usr.sbin/ppp/   (props changed)
   stable/7/usr.sbin/ppp/route.c
 
 Modified: stable/7/usr.sbin/ppp/route.c
 ==============================================================================
 --- stable/7/usr.sbin/ppp/route.c	Mon Apr 13 19:54:33 2009	(r191013)
 +++ stable/7/usr.sbin/ppp/route.c	Mon Apr 13 20:19:28 2009	(r191014)
 @@ -902,8 +902,10 @@ rt_Update(struct bundle *bundle, const s
      p += memcpy_roundup(p, dst, dst->sa_len);
    }
  
 -  rtmes.m_rtm.rtm_addrs |= RTA_GATEWAY;
 +  if (gw != NULL && (gw->sa_family != AF_LINK))
 +    rtmes.m_rtm.rtm_addrs |= RTA_GATEWAY;
    p += memcpy_roundup(p, gw, gw->sa_len);
 +
    if (mask) {
      rtmes.m_rtm.rtm_addrs |= RTA_NETMASK;
      p += memcpy_roundup(p, mask, mask->sa_len);
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/130159: commit references a PR
Date: Mon, 20 Apr 2009 14:39:03 +0000 (UTC)

 Author: bz
 Date: Mon Apr 20 14:38:48 2009
 New Revision: 191316
 URL: http://svn.freebsd.org/changeset/base/191316
 
 Log:
   Conditionally add the interface name and address if available
   so that a ppp running in `receiver' (server) mode can properly
   update routes, for example to update the MTU.
   
   Submitted by:	loos.br gmail.com (Luiz Otavio O Souza)
   PR:		bin/130159
   PR:		kern/125079, kern/122068, bin/126892
   MFC after:	3 days
 
 Modified:
   head/usr.sbin/ppp/ipcp.c
   head/usr.sbin/ppp/ipv6cp.c
   head/usr.sbin/ppp/route.c
   head/usr.sbin/ppp/route.h
 
 Modified: head/usr.sbin/ppp/ipcp.c
 ==============================================================================
 --- head/usr.sbin/ppp/ipcp.c	Mon Apr 20 14:36:01 2009	(r191315)
 +++ head/usr.sbin/ppp/ipcp.c	Mon Apr 20 14:38:48 2009	(r191316)
 @@ -692,7 +692,7 @@ ipcp_SetIPaddress(struct ipcp *ipcp, str
    if (bundle->ncp.cfg.sendpipe > 0 || bundle->ncp.cfg.recvpipe > 0) {
      ncprange_getsa(&myrange, &ssgw, &ssmask);
      ncpaddr_getsa(&hisncpaddr, &ssdst);
 -    rt_Update(bundle, sadst, sagw, samask);
 +    rt_Update(bundle, sadst, sagw, samask, NULL, NULL);
    }
  
    if (Enabled(bundle, OPT_SROUTES))
 
 Modified: head/usr.sbin/ppp/ipv6cp.c
 ==============================================================================
 --- head/usr.sbin/ppp/ipv6cp.c	Mon Apr 20 14:36:01 2009	(r191315)
 +++ head/usr.sbin/ppp/ipv6cp.c	Mon Apr 20 14:38:48 2009	(r191316)
 @@ -245,7 +245,7 @@ ipcp_SetIPv6address(struct ipv6cp *ipv6c
        ncpaddr_getsa(&ipv6cp->hisaddr, &ssdst);
      else
        sadst = NULL;
 -    rt_Update(bundle, sadst, sagw, samask);
 +    rt_Update(bundle, sadst, sagw, samask, NULL, NULL);
    }
  
    if (Enabled(bundle, OPT_SROUTES))
 
 Modified: head/usr.sbin/ppp/route.c
 ==============================================================================
 --- head/usr.sbin/ppp/route.c	Mon Apr 20 14:36:01 2009	(r191315)
 +++ head/usr.sbin/ppp/route.c	Mon Apr 20 14:38:48 2009	(r191316)
 @@ -532,7 +532,8 @@ route_UpdateMTU(struct bundle *bundle)
                     " mtu %lu\n", rtm->rtm_index, Index2Nam(rtm->rtm_index),
                     ncprange_ntoa(&dst), bundle->iface->mtu);
        }
 -      rt_Update(bundle, sa[RTAX_DST], sa[RTAX_GATEWAY], sa[RTAX_NETMASK]);
 +      rt_Update(bundle, sa[RTAX_DST], sa[RTAX_GATEWAY], sa[RTAX_NETMASK],
 +                sa[RTAX_IFP], sa[RTAX_IFA]);
      }
    }
  
 @@ -870,7 +871,8 @@ failed:
  
  void
  rt_Update(struct bundle *bundle, const struct sockaddr *dst,
 -          const struct sockaddr *gw, const struct sockaddr *mask)
 +          const struct sockaddr *gw, const struct sockaddr *mask,
 +          const struct sockaddr *ifp, const struct sockaddr *ifa)
  {
    struct ncprange ncpdst;
    struct rtmsg rtmes;
 @@ -920,6 +922,13 @@ rt_Update(struct bundle *bundle, const s
      p += memcpy_roundup(p, mask, mask->sa_len);
    }
  
 +  if (ifa && ifp && ifp->sa_family == AF_LINK) {
 +    rtmes.m_rtm.rtm_addrs |= RTA_IFP;
 +    p += memcpy_roundup(p, ifp, ifp->sa_len);
 +    rtmes.m_rtm.rtm_addrs |= RTA_IFA;
 +    p += memcpy_roundup(p, ifa, ifa->sa_len);
 +  }
 +
    rtmes.m_rtm.rtm_msglen = p - (char *)&rtmes;
  
    wb = ID0write(s, &rtmes, rtmes.m_rtm.rtm_msglen);
 
 Modified: head/usr.sbin/ppp/route.h
 ==============================================================================
 --- head/usr.sbin/ppp/route.h	Mon Apr 20 14:36:01 2009	(r191315)
 +++ head/usr.sbin/ppp/route.h	Mon Apr 20 14:38:48 2009	(r191316)
 @@ -70,4 +70,5 @@ extern void route_ParseHdr(struct rt_msg
  extern int rt_Set(struct bundle *, int, const struct ncprange *,
                    const struct ncpaddr *, int, int);
  extern void rt_Update(struct bundle *, const struct sockaddr *,
 +                      const struct sockaddr *, const struct sockaddr *,
                        const struct sockaddr *, const struct sockaddr *);
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->patched 
State-Changed-By: bz 
State-Changed-When: Sat Apr 25 17:45:29 UTC 2009 
State-Changed-Why:  
The patch is in HEAD now and will br MFCed after 7.2-R. 
re@ and I agreed that it was too late to risk any further breakage in ppp. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=130159 

From: "Bjoern A. Zeeb" <bz@FreeBSD.org>
To: bug-followup@FreeBSD.org, loos.br@gmail.com, 
    Brett Glass <brett@lariat.net>, aragon@phat.za.net, tcs@kitty.2y.idv.tw, 
    just@rg3.net
Cc:  
Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes
Date: Thu, 7 May 2009 03:20:41 +0000 (UTC)

 Hi,
 
 Luiz: sorry for the duplicate (just that GNATS and the others has it):
 
 can you try this patch on stable/7 or 7.2-R and report back?
 
 http://people.freebsd.org/~bz/20090506-01-ppp-mfc.diff
 
 -- 
 Bjoern A. Zeeb                      The greatest risk is not taking one.

From: Brett Glass <brett@lariat.net>
To: "Bjoern A. Zeeb" <bz@FreeBSD.org>, bug-followup@FreeBSD.org,
        loos.br@gmail.com, aragon@phat.za.net, tcs@kitty.2y.idv.tw,
        just@rg3.net
Cc:  
Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes
Date: Wed, 06 May 2009 21:52:38 -0600

 Looks good, but the routing table entry should not have the 
 "gateway" flag set unless that instance of PPP is invoked by a PPP 
 a client that's doing NAT (in which case, the machine is serving as 
 its own NAT router and so is a gateway).
 
 In the case of a PPPoE, PPTP, or dialupserver, the "tun" interface 
 is working just like any other LAN interface. (It's essentially 
 acting as a "half bridge.") The same with a client that's doing 
 dialup or acting as a PPPoE or PPTP client.
 
 --Brett Glass
 
 At 09:20 PM 5/6/2009, Bjoern A. Zeeb wrote:
 
 >Hi,
 >
 >Luiz: sorry for the duplicate (just that GNATS and the others has it):
 >
 >can you try this patch on stable/7 or 7.2-R and report back?
 >
 >http://people.freebsd.org/~bz/20090506-01-ppp-mfc.diff
 >
 >--
 >Bjoern A. Zeeb                      The greatest risk is not taking one.
 

From: "Bjoern A. Zeeb" <bz@FreeBSD.org>
To: Brett Glass <brett@lariat.net>
Cc: bug-followup@FreeBSD.org, loos.br@gmail.com, aragon@phat.za.net, 
    tcs@kitty.2y.idv.tw, just@rg3.net
Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes
Date: Thu, 7 May 2009 15:12:08 +0000 (UTC)

 On Wed, 6 May 2009, Brett Glass wrote:
 
 Hi,
 
 > Looks good, but the routing table entry should not have the "gateway" flag 
 > set unless that instance of PPP is invoked by a PPP a client that's doing NAT 
 > (in which case, the machine is serving as its own NAT router and so is a 
 > gateway).
 
 So to make a few things more clear here:
 
 1) ignore NAT, hasn't anything to do with this
 2) the gateway flag, as mentioned in one of the commit messages to
     HEAD at least, is not a problem of ppp; if you have a tun interface
     and you are going to use ifconfig to change things in a certain
     way, the flag will appear as well. It's a "problem" in the kernel
     in rtsock.c which people are pondering on how to fix.
 
 Note that to my `guessing' of things (without checking the entire
 kernel(, that's a "beauty error" and does not have any real impact unless
 you have software like a routing deamon running that check this flag and
 does decisions upon this.
 
 It will be handled but not along with these ppp fixes.
 
 I'll happily send a patch out to you though or notify you if it got
 fixed in HEAD.
 
 /bz
 
 -- 
 Bjoern A. Zeeb                      The greatest risk is not taking one.

From: Brett Glass <brett@lariat.net>
To: "Bjoern A. Zeeb" <bz@FreeBSD.org>
Cc: bug-followup@FreeBSD.org, loos.br@gmail.com, aragon@phat.za.net,
        tcs@kitty.2y.idv.tw, just@rg3.net
Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes
Date: Thu, 07 May 2009 09:54:39 -0600

 At 09:12 AM 5/7/2009, Bjoern A. Zeeb wrote:
 
 >Note that to my `guessing' of things (without checking the entire
 >kernel(, that's a "beauty error" and does not have any real impact unless
 >you have software like a routing deamon running that check this flag and
 >does decisions upon this.
 
 As far as I can tell, the unnecessary flag does not cause a 
 malfunction. But it  may cause extra cycles to be consumed.
 
 >I'll happily send a patch out to you though or notify you if it got
 >fixed in HEAD.
 
 Thank you. The top priority for me and for other users of PPTP and 
 PPPoE, though, is to have a well considered (and well tested) patch 
 that will make 7.1-RELEASE and 7.2-RELEASE systems work with PPPoE 
 and PPTP.  Neither release's ppp(8) will work properly with these 
 protocols "out of the box."
 
 --Brett Glass 
 

From: "Luiz Otavio O Souza" <loos.br@gmail.com>
To: "Bjoern A. Zeeb" <bz@FreeBSD.org>,
	<bug-followup@FreeBSD.org>,
	"Brett Glass" <brett@lariat.net>,
	<aragon@phat.za.net>,
	<tcs@kitty.2y.idv.tw>,
	<just@rg3.net>
Cc:  
Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes
Date: Sat, 9 May 2009 11:08:03 -0300

 > Hi,
 >
 > Luiz: sorry for the duplicate (just that GNATS and the others has it):
 >
 > can you try this patch on stable/7 or 7.2-R and report back?
 >
 > http://people.freebsd.org/~bz/20090506-01-ppp-mfc.diff
 >
 > -- 
 > Bjoern A. Zeeb                      The greatest risk is not taking one.
 
 
 Hi Bjoern,
 
 Sorry for delay, i need to update my system, but yes, i can confirm the 
 patch works:
 
 fw# netstat -rn | less
 Routing tables
 
 Internet:
 Destination        Gateway            Flags    Refs      Use  Netif Expire
 default            200.xxx.xxx.185    UGS         0   106077   bge1
 10.0.0.0/24        link#1             UC          0        0    em0
 10.0.0.5           00:0e:7f:b2:49:95  UHLW        1      512    em0   1056
 10.0.0.7           00:0e:7f:23:90:59  UHLW        1       82    em0   1140
 10.0.0.11          00:22:19:83:2c:10  UHLW        1       57    em0   1195
 10.0.0.27          00:15:17:1c:91:a8  UHLW        2       32    lo0
 10.0.0.103         10.0.0.27          UGH         0        2 
        ----> my pptp connection
 10.0.0.103         00:15:17:1c:91:a8  UHLS2       1        0 
        ----> the proxy arp entry
 10.0.0.126         00:21:5d:9c:0f:84  UHLW        1      320    em0   1166
 (...)
 
 fw# uname -a
 FreeBSD fw.xxxxxx.com.br 7.2-STABLE FreeBSD 7.2-STABLE #0: Fri May  8 
 13:35:37 BRT 2009     root@fw.xxxxxx.com.br:/usr/obj/usr/src/sys/FW  i386
 
 Many thanks for your help and support.
 
 Luiz 
 

From: Brett Glass <brett@lariat.net>
To: "Luiz Otavio O Souza" <loos.br@gmail.com>,
        "Bjoern A. Zeeb" <bz@FreeBSD.org>, <bug-followup@FreeBSD.org>,
        <aragon@phat.za.net>, <tcs@kitty.2y.idv.tw>, <just@rg3.net>
Cc:  
Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes
Date: Sat, 09 May 2009 08:46:42 -0600

 All looks good except for the (ugh!) UGH in the routing table. ;-) 
 Should be UH.
 
 --Brett
 
 At 08:08 AM 5/9/2009, Luiz Otavio O Souza wrote:
 
 >>Hi,
 >>
 >>Luiz: sorry for the duplicate (just that GNATS and the others has it):
 >>
 >>can you try this patch on stable/7 or 7.2-R and report back?
 >>
 >>http://people.freebsd.org/~bz/20090506-01-ppp-mfc.diff
 >>
 >>--
 >>Bjoern A. Zeeb                      The greatest risk is not taking one.
 >
 >
 >Hi Bjoern,
 >
 >Sorry for delay, i need to update my system, but yes, i can 
 >confirm the patch works:
 >
 >fw# netstat -rn | less
 >Routing tables
 >
 >Internet:
 >Destination        Gateway            Flags    Refs      Use  Netif Expire
 >default            200.xxx.xxx.185    UGS         0   106077   bge1
 >10.0.0.0/24        link#1             UC          0        0    em0
 >10.0.0.5           00:0e:7f:b2:49:95  UHLW        1      512    em0   1056
 >10.0.0.7           00:0e:7f:23:90:59  UHLW        1       82    em0   1140
 >10.0.0.11          00:22:19:83:2c:10  UHLW        1       57    em0   1195
 >10.0.0.27          00:15:17:1c:91:a8  UHLW        2       32    lo0
 >10.0.0.103         10.0.0.27          UGH         0        2 
 >----> my pptp connection
 >10.0.0.103         00:15:17:1c:91:a8  UHLS2       1        0 
 >----> the proxy arp entry
 >10.0.0.126         00:21:5d:9c:0f:84  UHLW        1      320    em0   1166
 >(...)
 >
 >fw# uname -a
 >FreeBSD fw.xxxxxx.com.br 7.2-STABLE FreeBSD 7.2-STABLE #0: Fri 
 >May  8 13:35:37 BRT 
 >2009     root@fw.xxxxxx.com.br:/usr/obj/usr/src/sys/FW  i386
 >
 >Many thanks for your help and support.
 >
 >Luiz
 

From: "Bjoern A. Zeeb" <bz@FreeBSD.org>
To: Brett Glass <brett@lariat.net>
Cc: Luiz Otavio O Souza <loos.br@gmail.com>, bug-followup@FreeBSD.org, 
    aragon@phat.za.net, tcs@kitty.2y.idv.tw, just@rg3.net
Subject: Re: bin/130159: [patch] ppp(8) fails to correctly set routes
Date: Sat, 9 May 2009 14:53:26 +0000 (UTC)

 At 08:08 AM 5/9/2009, Luiz Otavio O Souza wrote:
 On Sat, 9 May 2009, Brett Glass wrote:
 
 Hi,
 
 ok, I am going to MFC the changes to 7-STABLE then; I'll be travelling
 the next days but it'll happen.
 
 The "G" flag is really really really a different issue and a kernel
 bug and it is not forgotten.
 
 Thanks for testing and the feedback!
 
 /bz
 
 -- 
 Bjoern A. Zeeb                      The greatest risk is not taking one.
Responsible-Changed-From-To: bz->brian 
Responsible-Changed-By: bz 
Responsible-Changed-When: Tue Jan 5 14:10:39 UTC 2010 
Responsible-Changed-Why:  
Re-assign to brian; 
he was last looking into these but I do not know of the results. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=130159 
>Unformatted:
