From nobody@FreeBSD.org  Thu Sep 28 14:45:39 2006
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id BA7C516A415
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 28 Sep 2006 14:45:39 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [216.136.204.117])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 4906F43D45
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 28 Sep 2006 14:45:31 +0000 (GMT)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id k8SEjSD6004440
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 28 Sep 2006 14:45:28 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id k8SEjSih004439;
	Thu, 28 Sep 2006 14:45:28 GMT
	(envelope-from nobody)
Message-Id: <200609281445.k8SEjSih004439@www.freebsd.org>
Date: Thu, 28 Sep 2006 14:45:28 GMT
From: Dominic Blais <dblais@interplex.ca>
To: freebsd-gnats-submit@FreeBSD.org
Subject: some tun interfaces with a mtu of 1500 while i should never exceed 1472 with ppp 
X-Send-Pr-Version: www-2.3

>Number:         103762
>Category:       bin
>Synopsis:       ppp(8): some tun interfaces with a mtu of 1500 while i should never exceed 1472 with ppp
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Sep 28 14:50:21 GMT 2006
>Closed-Date:    
>Last-Modified:  Sun Jan 20 04:18:00 UTC 2008
>Originator:     Dominic Blais
>Release:        FreeBSD RELEASE-6.3-p7
>Organization:
Interplex Telecom
>Environment:
FreeBSD chapdelaine.ipx.gw.interplex.ca 6.1-RELEASE-p7 FreeBSD 6.1-RELEASE-p7 #0: Thu Sep 21 16:11:35 EDT 2006     admin@chapdelaine.rt.interplex.ca:/usr/src/sys/i386/compile/CHAPDELAINE  i386
>Description:
We have multiple FreeBSD systems across our network acting as PPPoE
server for Internet access to our customers. All these systems have this
configuration included in ppp.conf:

 set mru max 1472
 set mtu max 1472

On every systems but one the mtu never exceeds 1472. It seems that the
ppp processes associated with the tun interfaces with an mtu of 1500 are
freezed. I mean, they never stop and are avoid limited IP addresses from
being used again by new pppoe authentication. 
 
Example:
<QUOTE>
tun87: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1472
        inet 10.0.0.1 --> 10.0.0.254 netmask 0xffffffff
        Opened by PID 57916
tun88: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1472
        inet 10.0.0.1 --> 10.0.0.220 netmask 0xffffffff
        Opened by PID 76102
tun89: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1472
        inet 10.0.0.1 --> 10.0.0.215 netmask 0xffffffff
        Opened by PID 76229
tun90: flags=8010<POINTOPOINT,MULTICAST> mtu 1500
tun91: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        inet 10.0.0.1 --> 10.0.0.232 netmask 0xffffffff
        Opened by PID 58042
</QUOTE>

The interface tun91 is locked by the ppp process with the 58042 PID. It
will never be freed if I'm not killing it.

Since it's happening on only one of our servers, my guess is that it is
triggered by something received on this specific network.

I made a script which kills these processes so that it can free the
locked IP addresses but that's an ugly workaround.
>How-To-Repeat:
Start a pppoe server on my network ;) I'm kidding but as I said, it only
happen on one of our networks even thought we're using FreeBSD 6.1-p7 on
each of them.


>Fix:

>Release-Note:
>Audit-Trail:

From: "Dominic Blais" <dblais@interplex.ca>
To: bug-followup@FreeBSD.org,
 dblais@interplex.ca
Cc:  
Subject: Re: bin/103762: some tun interfaces with a mtu of 1500 while i 
     should never exceed 1472 with ppp
Date: Tue, 3 Oct 2006 14:30:42 -0400 (EDT)

 I got some new informations about this problem. We noticed that it was
 triggered by 3 specific customers which all had Linksys BEFSR41 routers.
 It seems that forcing an mtu of 1472 on it fix the problem. So maybe
 there's a problem with mtu size negotiation with this router? It would be
 nice to fix the FreeBSD side of this in order to cope with these router
 models... I don't know what's wrong exactly but try with this kind of
 router, hardware version 4.0 and it should do the same thing after some
 hours.
 
 --
 Dominic Blais
 

From: Bruce M Simpson <bms@incunabulum.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc: Dominic Blais <dblais@interplex.ca>
Subject: Re: bin/103762: some tun interfaces with a mtu of 1500 while i should
 never exceed 1472 with ppp
Date: Sat, 03 Feb 2007 03:19:50 +0000

 Hi,
 
 I'm a FreeBSD committer looking into this PR.
 Not having access to your network infrastructure, I can't really 
 reproduce the problem.
 
 This does not appear to be a tun(4) problem, however; it should simply 
 do what it's told via the TUNSIFINFO ioctl or SIOCSIFMTU interface ioctl.
 
 It sounds like you're using pppoed(8) to serve PPPoE sessions. It relies 
 on Netgraph to do the low-level plumbing, then forks ppp(8) to handle 
 the PPP session itself.
 
 I would draw your attention to the following in the ppp(8) man page:
 
          set mru [max[imum]] [value]
              The default MRU (Maximum Receive Unit) is 1500.  If it is
              increased, the other side *may* increase its MTU.  In theory
              there is no point in decreasing the MRU to below the default as
              the PPP protocol says implementations *must* be able to accept
              packets of at least 1500 octets.
 
 It's entirely possible there's a bug in ppp(8) and its MRU/MTU 
 negotiation, however I lack the time and resources to track that down.
 
 Perhaps try using mpd from ports instead?
 
 Regards,
 BMS
>Unformatted:
