From mi@kot.ne.mediaone.net  Wed Dec 15 06:49:56 1999
Return-Path: <mi@kot.ne.mediaone.net>
Received: from kot.ne.mediaone.net (kot.ne.mediaone.net [24.218.15.190])
	by hub.freebsd.org (Postfix) with ESMTP id C457515498
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 15 Dec 1999 06:49:51 -0800 (PST)
	(envelope-from mi@kot.ne.mediaone.net)
Received: from rtfm.newton (rtfm.newton [10.10.0.1])
	by kot.ne.mediaone.net (8.9.3/8.9.1) with ESMTP id JAA62396
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 15 Dec 1999 09:46:04 -0500 (EST)
Received: (from mi@localhost)
	by rtfm.newton (8.9.3/8.9.3) id JAA32322;
	Wed, 15 Dec 1999 09:46:04 -0500 (EST)
	(envelope-from mi@kot.ne.mediaone.net)
Message-Id: <199912151446.JAA32322@rtfm.newton>
Date: Wed, 15 Dec 1999 09:46:04 -0500 (EST)
From: Mikhail Teterin <mi@kot.ne.mediaone.net>
Reply-To: mi@kot.ne.mediaone.net
To: FreeBSD-gnats-submit@freebsd.org
Subject: over-natd connections hang if MTUs are different
X-Send-Pr-Version: 3.2

>Number:         15494
>Category:       bin
>Synopsis:       over-natd connections hang if MTUs are different
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    ru
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Dec 15 06:50:00 PST 1999
>Closed-Date:    Thu Jan 27 09:03:55 PST 2000
>Last-Modified:  Thu Jan 27 09:07:39 PST 2000
>Originator:     Mikhail Teterin
>Release:        FreeBSD 3.3-STABLE i386
>Organization:
Virtual Estates, Inc.
>Environment:

	A gateway machine with two interfaces -- public and private
	running natd. A client machine with one interface.

	The problem observed with the FreeBSD-3.3 (x86) client and
	with the Linux Redhat-6.0 client (on Alpha).

>Description:

	The MTUs on the gateway's interfaces are set to 900 (seems
	to work better with this ancient 3Com ISA cards). The client's
	MTU was set to 1500.

	Any TCP connection made by the client (handled by the gateway's
	natd) would soon hang in the middle of data transfer.

>How-To-Repeat:

	See description
>Fix:
	
	Use the same MTU on the client.

>Release-Note:
>Audit-Trail:

From: Ruslan Ermilov <ru@FreeBSD.ORG>
To: Mikhail Teterin <mi@kot.ne.mediaone.net>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/15494: over-natd connections hang if MTUs are different
Date: Thu, 30 Dec 1999 15:11:36 +0200

 --sm4nu43k4a2Rpi4c
 Content-Type: text/plain; charset=us-ascii
 
 On Wed, Dec 15, 1999 at 09:46:04AM -0500, Mikhail Teterin wrote:
 > 
 > A gateway machine with two interfaces -- public and private
 > running natd. A client machine with one interface.
 > 
 > The problem observed with the FreeBSD-3.3 (x86) client and
 > with the Linux Redhat-6.0 client (on Alpha).
 > 
 > The MTUs on the gateway's interfaces are set to 900 (seems
 > to work better with this ancient 3Com ISA cards). The client's
 > MTU was set to 1500.
 > 
 > Any TCP connection made by the client (handled by the gateway's
 > natd) would soon hang in the middle of data transfer.
 > 
 I bet you have your aliasing address specified as an IP number
 (with -a option) rather than derived from an interface name (-n).
 Am I right?
 
 If yes, could you please try the following patch.
 
 -- 
 Ruslan Ermilov		Sysadmin and DBA of the
 ru@ucb.crimea.ua	United Commercial Bank,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.247.647	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
 
 --sm4nu43k4a2Rpi4c
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="natd.c.patch"
 
 Index: natd.c
 ===================================================================
 RCS file: /usr/FreeBSD-CVS/src/sbin/natd/natd.c,v
 retrieving revision 1.23
 diff -u -r1.23 natd.c
 --- natd.c	1999/10/13 09:00:16	1.23
 +++ natd.c	1999/12/30 13:00:45
 @@ -601,13 +601,15 @@
  		if (errno == ENOBUFS)
  			return;
  
 -		if (errno == EMSGSIZE) {
 -
 -			if (packetDirection == OUTPUT &&
 -			    ifMTU != -1)
 -				SendNeedFragIcmp (icmpSock,
 +		if (errno == EMSGSIZE && packetDirection == OUTPUT) {
 +			if (ifMTU != -1)
 +				SendNeedFragIcmp(icmpSock,
  						  (struct ip*) packetBuf,
  						  ifMTU - aliasOverhead);
 +			else
 +				SendNeedFragIcmp(icmpSock,
 +						  (struct ip*) packetBuf,
 +						  packetLen - aliasOverhead);
  		}
  		else {
  
 
 --sm4nu43k4a2Rpi4c--
 
State-Changed-From-To: open->feedback 
State-Changed-By: ru 
State-Changed-When: Thu Dec 30 05:28:36 PST 1999 
State-Changed-Why:  
Patch has been sent to originator. 


Responsible-Changed-From-To: freebsd-bugs->ru 
Responsible-Changed-By: ru 
Responsible-Changed-When: Thu Dec 30 05:28:36 PST 1999 
Responsible-Changed-Why:  
Over to maintainer. 

From: Mikhail Teterin <mi@kot.ne.mediaone.net>
To: Ruslan Ermilov <ru@FreeBSD.ORG>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/15494: over-natd connections hang if MTUs are different
Date: Thu, 30 Dec 1999 09:15:20 -0500 (EST)

 Ruslan Ermilov once stated:
 
 => A gateway machine  with two interfaces -- public  and private running
 => natd. A client machine with one interface.
 => 
 => The problem observed  with the FreeBSD-3.3 (x86) client  and with the
 => Linux Redhat-6.0 client (on Alpha).
 => 
 => The MTUs  on the gateway's interfaces  are set to 900  (seems to work
 => better with this ancient 3Com ISA cards). The client's MTU was set to
 => 1500.
 => 
 => Any TCP connection made by the client (handled by the gateway's natd)
 => would soon hang in the middle of data transfer.
 =>
 =I bet you have your aliasing address specified as an IP number (with -a
 =option) rather than derived from an interface name (-n). Am I right?
 
 Nope:
 	mi@aldan:~ (1) ps -ax | grep natd
 	50380  ??  Ss     2:47.03 /sbin/natd -u -s -n ep1
 
 Yours,
 
 	-mi
 
 =If yes, could you please try the following patch.
 [...]
 [Attachment, skipping...]
 
State-Changed-From-To: feedback->analyzed 
State-Changed-By: ru 
State-Changed-When: Thu Jan 6 04:33:36 PST 2000 
State-Changed-Why:  
Confirmed to be a real problem, working on a patch. 

From: Ruslan Ermilov <ru@ucb.crimea.ua>
To: Mikhail Teterin <mi@kot.ne.mediaone.net>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/15494: over-natd connections hang if MTUs are different
Date: Mon, 24 Jan 2000 10:46:43 +0200

 --UugvWAfsgieZRqgk
 Content-Type: text/plain; charset=us-ascii
 
 On Wed, Dec 15, 1999 at 09:46:04AM -0500, Mikhail Teterin wrote:
 > 
 > >Number:         15494
 > >Category:       kern
 > >Synopsis:       over-natd connections hang if MTUs are different
 
 Could you please test the following patch?
 And please don't forget -dynamic option!
 
 -- 
 Ruslan Ermilov		Sysadmin and DBA of the
 ru@ucb.crimea.ua	United Commercial Bank,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.247.647	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
 
 --UugvWAfsgieZRqgk
 Content-Type: message/rfc822
 
 Received: (from ru@localhost)
 	by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id QAA47617;
 	Wed, 19 Jan 2000 16:48:20 +0200 (EET)
 	(envelope-from ru)
 Date: Wed, 19 Jan 2000 16:48:20 +0200
 From: Ruslan Ermilov <ru@FreeBSD.ORG>
 To: Jim Flowers <jflowers@ezo.net>, Mikhail Teterin <mi@kot.ne.mediaone.net>,
         net@FreeBSD.ORG
 Subject: Re: Natd with Pmtu Discovery
 Message-ID: <20000119164820.A41863@relay.ucb.crimea.ua>
 Mail-Followup-To: Jim Flowers <jflowers@ezo.net>,
 	Mikhail Teterin <mi@kot.ne.mediaone.net>, net@FreeBSD.ORG
 References: <20000106143722.A2080@relay.ucb.crimea.ua> <Pine.BSI.3.91.1000106091555.29680A-100000@lily.ezo.net> <20000119145729.A11150@relay.ucb.crimea.ua>
 Mime-Version: 1.0
 Content-Type: multipart/mixed; boundary="s/l3CgOIzMHHjg/5"
 X-Mailer: Mutt 0.95.3i
 In-Reply-To: <20000119145729.A11150@relay.ucb.crimea.ua>; from Ruslan Ermilov on Wed, Jan 19, 2000 at 02:57:30PM +0200
 X-Operating-System: FreeBSD 3.3-STABLE i386
 
 
 --s/l3CgOIzMHHjg/5
 Content-Type: text/plain; charset=us-ascii
 
 On Wed, Jan 19, 2000 at 02:57:30PM +0200, Ruslan Ermilov wrote:
 > [Redirected to -net, Bcc'ed to -hackers]
 > 
 > On Thu, Jan 06, 2000 at 09:31:27AM -0500, Jim Flowers wrote:
 > > OK.  I followed this a little further.  The problem is that the natd read 
 > > of the interface mtu precedes the skip routine that modifies it.  
 > > Unfortunately, when the skip routine modifies the interface mtu it does 
 > > not send a message to the socket as it does when the address is changed 
 > > so the -dynamic flag doesn't help.
 > > 
 > > Currently, I moved the the initiation of natd to rc.local to follow the 
 > > skip change to the interface mtu but this is less than ideal.
 > > 
 > > A better approach would be to notify the natd module of any 
 > > interface mtu change via the socket, similar to when the address is 
 > > changed with the -dynamic flag set.  This would also pick of manual 
 > > changes.
 > > 
 > Hmm, I thought of this too, but this will not fix the problem with natd.
 > 
 Please try the following patch with -dynamic flag of natd(8)!
 This patch is for -stable, but could be trivially adopted for -current.
 
 > Consider the case when natd(8) is not bound to any specific interface,
 > and it sends packets via multiple interfaces (in my case, for example).
 > 
 This case is not fixed by this patch.
 
 -- 
 Ruslan Ermilov		Sysadmin and DBA of the
 ru@ucb.crimea.ua	United Commercial Bank,
 ru@FreeBSD.org		FreeBSD committer,
 +380.652.247.647	Simferopol, Ukraine
 
 http://www.FreeBSD.org	The Power To Serve
 http://www.oracle.com	Enabling The Information Age
 
 --s/l3CgOIzMHHjg/5
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename=p
 
 Index: src/sbin/natd/natd.c
 ===================================================================
 RCS file: /usr/FreeBSD-CVS/src/sbin/natd/natd.c,v
 retrieving revision 1.11.2.7
 diff -u -p -1 -3 -r1.11.2.7 natd.c
 --- natd.c	1999/10/28 18:55:35	1.11.2.7
 +++ natd.c	2000/01/19 14:14:07
 @@ -632,27 +632,27 @@ static void HandleRoutingInfo (int fd)
  		Warn ("read from routing socket failed");
  		return;
  	}
  
  	if (ifMsg.ifm_version != RTM_VERSION) {
  
  		Warn ("unexpected packet read from routing socket");
  		return;
  	}
  
  	if (verbose)
  		printf ("Routing message %X received.\n", ifMsg.ifm_type);
  
 -	if (ifMsg.ifm_type != RTM_NEWADDR)
 +	if (ifMsg.ifm_type != RTM_NEWADDR && ifMsg.ifm_type != RTM_IFINFO)
  		return;
  
  	if (verbose && ifMsg.ifm_index == ifIndex)
  		printf ("Interface address has changed.\n");
  
  	if (ifMsg.ifm_index == ifIndex)
  		assignAliasAddr = 1;
  }
  
  static void PrintPacket (struct ip* ip)
  {
  	printf ("%s", FormatPacket (ip));
  }
 Index: src/sys/net/if.c
 ===================================================================
 RCS file: /usr/FreeBSD-CVS/src/sys/net/if.c,v
 retrieving revision 1.64.2.1
 diff -u -p -1 -3 -r1.64.2.1 if.c
 --- /usr/src/sys/net/if.c	1999/08/29 16:28:14	1.64.2.1
 +++ /usr/src/sys/net/if.c	2000/01/19 14:20:34
 @@ -640,28 +640,30 @@ ifioctl(so, cmd, data, p)
  	case SIOCSIFMTU:
  		error = suser(p->p_ucred, &p->p_acflag);
  		if (error)
  			return (error);
  		if (ifp->if_ioctl == NULL)
  			return (EOPNOTSUPP);
  		/*
  		 * 72 was chosen below because it is the size of a TCP/IP
  		 * header (40) + the minimum mss (32).
  		 */
  		if (ifr->ifr_mtu < 72 || ifr->ifr_mtu > 65535)
  			return (EINVAL);
  		error = (*ifp->if_ioctl)(ifp, cmd, data);
 -		if (error == 0)
 +		if (error == 0) {
  			getmicrotime(&ifp->if_lastchange);
 +			rt_ifmsg(ifp);
 +		}
  		return(error);
  
  	case SIOCADDMULTI:
  	case SIOCDELMULTI:
  		error = suser(p->p_ucred, &p->p_acflag);
  		if (error)
  			return (error);
  
  		/* Don't allow group membership on non-multicast interfaces. */
  		if ((ifp->if_flags & IFF_MULTICAST) == 0)
  			return EOPNOTSUPP;
  
  		/* Don't let users screw up protocols' entries. */
 
 --s/l3CgOIzMHHjg/5--
 
 --UugvWAfsgieZRqgk--
 
State-Changed-From-To: analyzed->feedback 
State-Changed-By: ru 
State-Changed-When: Tue Jan 25 04:24:37 PST 2000 
State-Changed-Why:  
Fixed in 4.0-CURRENT (src/sys/net/if.c,v 1.83, src/sbin/natd/natd.c,v 1.24). 
State-Changed-From-To: feedback->closed 
State-Changed-By: ru 
State-Changed-When: Thu Jan 27 09:03:55 PST 2000 
State-Changed-Why:  
Fixed in 3.4-STABLE (sys/net/if.c,v 1.64.2.3, sbin/natd/natd.c,v 1.11.2.8). 
>Unformatted:
