From s.moeding@setuid.de  Wed Jul 12 18:08:18 2006
Return-Path: <s.moeding@setuid.de>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 3727616A4DE
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 12 Jul 2006 18:08:18 +0000 (UTC)
	(envelope-from s.moeding@setuid.de)
Received: from pima.hostsharing.net (pima.hostsharing.net [212.42.230.40])
	by mx1.FreeBSD.org (Postfix) with ESMTP id B810B43D7C
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 12 Jul 2006 18:08:02 +0000 (GMT)
	(envelope-from s.moeding@setuid.de)
Received: from elan.setuid.de (p50887A99.dip.t-dialin.net [80.136.122.153])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by pima.hostsharing.net (Postfix) with ESMTP id 9DCAAB05DD1D
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 12 Jul 2006 20:07:03 +0200 (CEST)
Received: from esprit.setuid.de (esprit.setuid.de [192.168.9.2])
	by elan.setuid.de (8.13.7/8.13.7) with ESMTP id k6CI7vVq021634
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 12 Jul 2006 20:07:58 +0200 (CEST)
	(envelope-from sm@setuid.de)
Received: from esprit.setuid.de (localhost [127.0.0.1])
	by esprit.setuid.de (8.13.6/8.13.4) with ESMTP id k6CI7vEx009329
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 12 Jul 2006 20:07:57 +0200 (CEST)
	(envelope-from sm@esprit.setuid.de)
Received: (from sm@localhost)
	by esprit.setuid.de (8.13.6/8.13.4/Submit) id k6CI7vcK009328;
	Wed, 12 Jul 2006 20:07:57 +0200 (CEST)
	(envelope-from sm)
Message-Id: <200607121807.k6CI7vcK009328@esprit.setuid.de>
Date: Wed, 12 Jul 2006 20:07:57 +0200 (CEST)
From: Stefan Moeding <sm@kill-9.net>
Reply-To: Stefan Moeding <sm@kill-9.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Transfer of large file fails with host is down message
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         100172
>Category:       kern
>Synopsis:       Transfer of large file fails with host is down message
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    glebius
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jul 12 18:10:15 GMT 2006
>Closed-Date:    Thu Mar 22 10:55:47 GMT 2007
>Last-Modified:  Thu Mar 22 11:00:09 GMT 2007
>Originator:     Stefan Moeding <sm@kill-9.net>
>Release:        FreeBSD 6.1-STABLE i386
>Organization:
>Environment:
System: FreeBSD elan.setuid.de 6.1-STABLE FreeBSD 6.1-STABLE #7: Fri Jul  7 21:29:43 CEST 2006     root@elan.setuid.de:/usr/obj/usr/src/sys/ELAN  i386
System: FreeBSD eclat.setuid.de 6.1-STABLE FreeBSD 6.1-STABLE #0: Sat Jul  8 19:39:21 CEST 2006     root@eclat.setuid.de:/usr/obj/usr/src/sys/ECLAT  i386

Use a network interface with a second address as alias.

>Description:

I'm experiencing network failures during the transfer of large files
(>500MB).  Initially I've seen failures with my Amanda backups, but
I've checked different transfer protocols (NFS, scp, ftp, rsync) and
I'm unable to transfer a larger file.  Transfering the file from a
FreeBSD Samba server to a Win2K host is also not possible.  The error
messages always gives "Write failed: Host is down".

This happens at different times during the transfer.  Sometimes I'm
able to copy 500MB over the network while the next time it breaks
after 50MB.  Strangly enough the failure only happens when sending the
file into one direction.  The same host can receive the large file
without any error.  In the meantime I've used different network cards
(tx, fxp, xl, em) without any improvement.

The hosts are connected with a switched 100MB ethernet.  All the hosts
are using a customized kernel without INET6.  Otherwise no unusual
configuration (no netgraph, no bridging, ...).  sysctl.conf or
loader.conf contain no additional setting.  The kernel configs can be
downloaded here:

http://www.kill-9.net/ELAN.txt
http://www.kill-9.net/ECLAT.txt

>How-To-Repeat:

Using tcpdump for analysis revealed something that doesn't seem to be
a coincidence.  I can reproduce the failure now using the following
recipe:

I'm using two boxes with 6.1-STABLE but I've seen this when I was
running 6.0-STABLE as well.  Both machines have one network interface
with one IP address and they are connect over 100MB switched ethernet.
In this setup host eclat will be the sending host where the problem
occurs.  Start by initiating a large transfer from eclat to the local
hgost (esprit in my case):

esprit% (ssh eclat cat /dev/zero ) | cat >/dev/null ; date

This should run till eternity.  The date command will show the exact
time when the transfer breaks later.

Now start tcpdump on the sending side to monitor ARP requests:

eclat# tcpdump -vv -i dc0 arp
tcpdump: listening on dc0, link-type EN10MB (Ethernet), capture size 96 bytes
13:38:04.001409 arp who-has esprit.setuid.de tell eclat.setuid.de
13:38:04.001568 arp reply esprit.setuid.de is-at 00:02:b3:2a:45:5a (oui Unknown)
13:58:00.000763 arp who-has esprit.setuid.de tell eclat.setuid.de
13:58:00.001267 arp reply esprit.setuid.de is-at 00:02:b3:2a:45:5a (oui Unknown)

This shows updates roughly every 20 minutes (this matches to
net.link.ether.inet.max_age).  During all this time the transfer
continues to run.

Now simply activate an IP alias on the interface of the sending system:

eclat# ifconfig -a
dc0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
	options=8<VLAN_MTU>
	inet 192.168.9.33 netmask 0xffffff00 broadcast 192.168.9.255
	ether 00:08:c7:03:88:12
	media: Ethernet autoselect (100baseTX <full-duplex>)
	status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	inet 127.0.0.1 netmask 0xff000000 

eclat# date; ifconfig dc0 inet 10.10.10.10 alias
Sun Jul  9 14:02:06 CEST 2006


From this moment the ARP request will show every 5 minutes:

14:02:06.550107 arp who-has 10.10.10.10 tell 10.10.10.10
14:02:54.473083 arp who-has esprit.setuid.de tell eclat.setuid.de
14:02:54.473245 arp reply esprit.setuid.de is-at 00:02:b3:2a:45:5a (oui Unknown)
14:07:53.472684 arp who-has esprit.setuid.de tell eclat.setuid.de
14:07:53.472866 arp reply esprit.setuid.de is-at 00:02:b3:2a:45:5a (oui Unknown)
14:12:52.474264 arp who-has esprit.setuid.de tell eclat.setuid.de
14:12:52.474389 arp reply esprit.setuid.de is-at 00:02:b3:2a:45:5a (oui Unknown)
14:17:51.474580 arp who-has esprit.setuid.de tell eclat.setuid.de
14:17:51.474708 arp reply esprit.setuid.de is-at 00:02:b3:2a:45:5a (oui Unknown)
14:22:50.473488 arp who-has esprit.setuid.de tell eclat.setuid.de
14:22:50.473605 arp reply esprit.setuid.de is-at 00:02:b3:2a:45:5a (oui Unknown)
14:27:49.474955 arp who-has esprit.setuid.de tell eclat.setuid.de
14:27:49.475124 arp reply esprit.setuid.de is-at 00:02:b3:2a:45:5a (oui Unknown)
14:32:48.475158 arp who-has esprit.setuid.de tell eclat.setuid.de
14:32:48.475326 arp reply esprit.setuid.de is-at 00:02:b3:2a:45:5a (oui Unknown)
14:37:47.540016 arp who-has esprit.setuid.de tell eclat.setuid.de
14:37:47.540166 arp reply esprit.setuid.de is-at 00:02:b3:2a:45:5a (oui Unknown)
14:42:46.663505 arp who-has esprit.setuid.de tell eclat.setuid.de
14:42:46.663703 arp reply esprit.setuid.de is-at 00:02:b3:2a:45:5a (oui Unknown)
14:47:45.474979 arp who-has esprit.setuid.de tell eclat.setuid.de
14:47:45.475167 arp reply esprit.setuid.de is-at 00:02:b3:2a:45:5a (oui Unknown)
14:52:44.476128 arp who-has esprit.setuid.de tell eclat.setuid.de
14:52:44.476299 arp reply esprit.setuid.de is-at 00:02:b3:2a:45:5a (oui Unknown)

At the same time I start getting the network failures at exactly the
time when the 5 minute ARP timer is due.  While this doesn't seem to
happen all the time, it doesn't look like a coincidence to me.
Restarting the transfer a couple of times I got the following output:

esprit% (ssh eclat cat /dev/zero ) | cat >/dev/null ; date
Connection to eclat.setuid.de closed by remote host.
Sun Jul  9 14:07:53 CEST 2006
esprit% (ssh eclat cat /dev/zero ) | cat >/dev/null ; date
Connection to eclat.setuid.de closed by remote host.
Sun Jul  9 14:17:51 CEST 2006
esprit% (ssh eclat cat /dev/zero ) | cat >/dev/null ; date
Connection to eclat.setuid.de closed by remote host.
Sun Jul  9 14:27:49 CEST 2006
esprit% (ssh eclat cat /dev/zero ) | cat >/dev/null ; date
Connection to eclat.setuid.de closed by remote host.
Sun Jul  9 14:32:48 CEST 2006
esprit% (ssh eclat cat /dev/zero ) | cat >/dev/null ; date
Connection to eclat.setuid.de closed by remote host.
Sun Jul  9 14:37:47 CEST 2006
esprit% (ssh eclat cat /dev/zero ) | cat >/dev/null ; date
Connection to eclat.setuid.de closed by remote host.
Sun Jul  9 14:42:46 CEST 2006
esprit% (ssh eclat cat /dev/zero ) | cat >/dev/null ; date
Connection to eclat.setuid.de closed by remote host.
Sun Jul  9 14:52:44 CEST 2006

Notice how the time of the error message matches the timestamp from
the ARP requests.

>Fix:

A fix is unknown.

As a workaround I'm using a static ARP entry on the sending box.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Wed Jul 12 22:53:21 UTC 2006 
Responsible-Changed-Why:  
Perhaps the networking folks can take a look at this, especially because it 
seems to be repeatable. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=100172 
Responsible-Changed-From-To: freebsd-net->glebius 
Responsible-Changed-By: andre 
Responsible-Changed-When: Wed Sep 6 17:23:25 UTC 2006 
Responsible-Changed-Why:  
Send over to Gleb Smirnoff, he's our ARP hacker. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=100172 
State-Changed-From-To: open->feedback 
State-Changed-By: glebius 
State-Changed-When: Sat Oct 14 12:23:13 UTC 2006 
State-Changed-Why:  
I can't reproduce this. You said, that you tried different network 
cards. Have you tried to reproduce this on the other FreeBSd 
installation? For example trying to send from esprit to eclat? 

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

From: Stefan Moeding <sm@kill-9.net>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/100172: [arp] Transfer of large file fails with host is down message
Date: Sun, 22 Oct 2006 19:28:07 +0200

 Finally I was able to also reproduce this with reversed directions.  I
 think I'm closer to the real cause now.  Probably you weren't able to
 reproduce this because there seems to be another part involved.
 
 I use routed(8) and according to the output of 'route monitor' there
 also seems to be a correlation between the connection failure and
 routing events.  The monitor command shows the following events at the
 same time the connection fails:
 
 got message of size 131 on Sun Oct 22 18:19:04 2006
 RTM_CHANGE: Change Metrics or flags: len 131, pid: 1107, seq 63, errno 0, flags:<DONE>
 locks:  inits: <hopcount>
 sockaddrs: <DST,GATEWAY,NETMASK>
  LAN eclat (0) 0 ffff ff
 
 got message of size 236 on Sun Oct 22 18:19:04 2006
 RTM_ADD: Add Route: len 236, pid: 0, seq 0, errno 0, flags:<UP,HOST,DONE,LLINFO,WASCLONED>
 locks:  inits: 
 sockaddrs: <DST,GATEWAY,IFP,IFA>
  esprit  dc0:0.8.c7.3.88.12 dyn0
 
 
 During normal operation these events happen every 5 minutes.  The
 connection failures happen at exactily the same time.  This would
 explain why I see those 5 minute intervals when arp itself does not
 have any 5 minute timeouts.
 
 I checked that the route events above only appear when the interface
 has an additional alias.  I got the impression that routed(8) removes
 the host route every 5 minutes (RTM_CHANGE) causing an arp request to
 recreate the route entry (RTM_ADD).  The existing connection probably
 fails when it tries to send a packet down the wire before the arp
 request has been answered.  So the arp requests would only be a
 symptom and not the cause of the real problem.
 
 Maybe you can reproduce this when you also start routed(8)?  I used
 this with an empty /etc/gateways and router_flags="-q" which is the
 default.  
 
 I also tried to decrease the 5 minute timeout for routed(8):
 
 # cd /usr/src/sbin/routed
 # vi defs.h
 
 Locate the line
 
 #define CHECK_QUIET_INTERVAL    300
 
 and change this to maybe 2 for a two second interval. Then rebuild and
 start the new binary:
 
 # make
 # /usr/obj/usr/src/sbin/routed/routed -q
 
 
 After this the above routing events appear every two seconds.  With
 this new routed(8) the data connection repeatedly fails after only a
 couple of seconds in my setup.
 
 -- 
 Stefan
 
State-Changed-From-To: feedback->open 
State-Changed-By: glebius 
State-Changed-When: Mon Oct 23 10:30:11 UTC 2006 
State-Changed-Why:  
Feedback received. The tag of the PR changed to [routed]. 

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

From: "Andrew - Supernews" <andrew@supernews.net>
To: bug-followup@FreeBSD.org
Cc: ade@freebsd.org
Subject: Re: kern/100172: [routed] Transfer of large file fails with host is
 down message
Date: Fri, 10 Nov 2006 09:48:06 +0000

 We also encountered this bug. It is more severe than it appears at
 first sight, because it can cause data corruption with some common
 applications (we noticed it with PostgreSQL) due to violating TCP
 reliability semantics. This is nothing to do with routed or routing
 protocols.
 
 We can reproduce this at will by deleting the relevent ARP entry while
 temporarily partitioning the network for a few seconds to induce an
 ARP failure.  (Established TCP connections should not break as a
 result of a connectivity failure of this duration, even over a local
 network.)
 
 The bug appears to have become visible as a side effect of:
 
 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/if_ether.c?only_with_tag=RELENG_6#rev1.137.2.5
 
 caused by the ultimate callers of arpresolve not expecting, or not
 properly handling, an EHOSTDOWN return. An EHOSTDOWN return from
 rt_check in net/route.c may also be able to provoke the same problem.
 However, I believe this is really a bug either in tcp_output, or in
 tcp_usr_send (and some other callers of tcp_output, such as
 tcp_ctloutput).
 
 The scenario that seems to cause the problem is as follows:
 
 Application writes to TCP socket, the call goes down through the
 socket layer to tcp_usr_send which calls tcp_output.
 
 tcp_output calls ip_output which calls ether_output (via the
 interface's output function pointer). ether_output calls arpresolve,
 which can return EHOSTDOWN either from its own logic or from a
 call to rt_check. That error gets returned by ether_output and
 ip_output, so we're back to tcp_output.
 
 tcp_output has this logic in the relevent part of its error-handling
 path:
 
                 if ((error == EHOSTUNREACH || error == ENETDOWN)
                     && TCPS_HAVERCVDSYN(tp->t_state)) {
                         tp->t_softerror = error;
                         return (0);
                 }
                 return (error);
 
 Since EHOSTDOWN is not listed above, it is returned by tcp_output,
 and where that was called from tcp_usr_send, the error is simply
 returned up the stack again, and eventually the user application
 sees it returned from write().
 
 It's important to note in this context that almost all callers of
 tcp_output completely ignore any error return; any error that occurs
 is either a soft error, which should not be returned to the user, or
 it should cause the TCP connection to be broken. The path described
 above does neither of these: it returns an error to the caller while
 keeping the connection alive, which is a violation of TCP's
 reliability semantics.
 
 It seems to me as though there are two possible fixes:
 
 1) tcp_output could absorb the EHOSTDOWN and return success if
 TCPS_HAVERCVDSYN is true, as per the logic used for EHOSTUNREACH;
 
 2) or tcp_usr_send, tcp_ctloutput, etc. could absorb the error from
 tcp_output and return success (possibly unless tcp_usr_send did the
 implied connection attempt, in which case the error should probably be
 returned - but it would be necessary to ensure that the connection was
 properly aborted in this case).
 
 Solution (1) alone strikes me as being fragile, in that it assumes
 complete knowledge of the possible errors from ip_output (which is
 arguably how the bug appeared in the first place).
 
 -- 
 Andrew, Supernews
 http://www.supernews.com
 

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: Andrew - Supernews <andrew@supernews.net>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/100172: [routed] Transfer of large file fails with host is down message
Date: Fri, 10 Nov 2006 14:12:26 +0300

 On Fri, Nov 10, 2006 at 09:50:21AM +0000, Andrew - Supernews wrote:
 A>  We also encountered this bug. It is more severe than it appears at
 A>  first sight, because it can cause data corruption with some common
 A>  applications (we noticed it with PostgreSQL) due to violating TCP
 A>  reliability semantics. This is nothing to do with routed or routing
 A>  protocols.
 A>  
 A>  We can reproduce this at will by deleting the relevent ARP entry while
 A>  temporarily partitioning the network for a few seconds to induce an
 A>  ARP failure.  (Established TCP connections should not break as a
 A>  result of a connectivity failure of this duration, even over a local
 A>  network.)
 A>  
 A>  The bug appears to have become visible as a side effect of:
 A>  
 A>  http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/if_ether.c?only_with_tag=RELENG_6#rev1.137.2.5
 
 That's strange, because even before this change the arpresolve() could
 return EHOSTDOWN.
 
 A>  caused by the ultimate callers of arpresolve not expecting, or not
 A>  properly handling, an EHOSTDOWN return. An EHOSTDOWN return from
 A>  rt_check in net/route.c may also be able to provoke the same problem.
 A>  However, I believe this is really a bug either in tcp_output, or in
 A>  tcp_usr_send (and some other callers of tcp_output, such as
 A>  tcp_ctloutput).
 A>  
 A>  The scenario that seems to cause the problem is as follows:
 A>  
 A>  Application writes to TCP socket, the call goes down through the
 A>  socket layer to tcp_usr_send which calls tcp_output.
 A>  
 A>  tcp_output calls ip_output which calls ether_output (via the
 A>  interface's output function pointer). ether_output calls arpresolve,
 A>  which can return EHOSTDOWN either from its own logic or from a
 A>  call to rt_check. That error gets returned by ether_output and
 A>  ip_output, so we're back to tcp_output.
 A>  
 A>  tcp_output has this logic in the relevent part of its error-handling
 A>  path:
 A>  
 A>                  if ((error == EHOSTUNREACH || error == ENETDOWN)
 A>                      && TCPS_HAVERCVDSYN(tp->t_state)) {
 A>                          tp->t_softerror = error;
 A>                          return (0);
 A>                  }
 A>                  return (error);
 A>  
 A>  Since EHOSTDOWN is not listed above, it is returned by tcp_output,
 A>  and where that was called from tcp_usr_send, the error is simply
 A>  returned up the stack again, and eventually the user application
 A>  sees it returned from write().
 A>  
 A>  It's important to note in this context that almost all callers of
 A>  tcp_output completely ignore any error return; any error that occurs
 A>  is either a soft error, which should not be returned to the user, or
 A>  it should cause the TCP connection to be broken. The path described
 A>  above does neither of these: it returns an error to the caller while
 A>  keeping the connection alive, which is a violation of TCP's
 A>  reliability semantics.
 A>  
 A>  It seems to me as though there are two possible fixes:
 A>  
 A>  1) tcp_output could absorb the EHOSTDOWN and return success if
 A>  TCPS_HAVERCVDSYN is true, as per the logic used for EHOSTUNREACH;
 A>  
 A>  2) or tcp_usr_send, tcp_ctloutput, etc. could absorb the error from
 A>  tcp_output and return success (possibly unless tcp_usr_send did the
 A>  implied connection attempt, in which case the error should probably be
 A>  returned - but it would be necessary to ensure that the connection was
 A>  properly aborted in this case).
 A>  
 A>  Solution (1) alone strikes me as being fragile, in that it assumes
 A>  complete knowledge of the possible errors from ip_output (which is
 A>  arguably how the bug appeared in the first place).
 
 Well, I agree with 1). I think we should add EHOSTDOWN and ENETUNREACH
 to the list of soft errors. TCP should be driven by its own timeouts,
 no the errors that are returned from network.
 
 P.S. I have an old desire to make a switch() block to handle the errors
 from ip_output() in tcp_output().
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE

From: "Andrew - Supernews" <andrew@supernews.net>
To: Gleb Smirnoff <glebius@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/100172: [routed] Transfer of large file fails with host is
 down message
Date: Fri, 10 Nov 2006 12:54:42 +0000

 >>>>> "Gleb" == Gleb Smirnoff <glebius@FreeBSD.org> writes:
 
  A> It seems to me as though there are two possible fixes:
  A> 
  A> 1) tcp_output could absorb the EHOSTDOWN and return success if
  A> TCPS_HAVERCVDSYN is true, as per the logic used for EHOSTUNREACH;
  A> 
  A> 2) or tcp_usr_send, tcp_ctloutput, etc. could absorb the error from
  A> tcp_output and return success (possibly unless tcp_usr_send did the
  A> implied connection attempt, in which case the error should probably be
  A> returned - but it would be necessary to ensure that the connection was
  A> properly aborted in this case).
  A> 
  A> Solution (1) alone strikes me as being fragile, in that it assumes
  A> complete knowledge of the possible errors from ip_output (which is
  A> arguably how the bug appeared in the first place).
 
  Gleb> Well, I agree with 1). I think we should add EHOSTDOWN and
  Gleb> ENETUNREACH to the list of soft errors. TCP should be driven by
  Gleb> its own timeouts, no the errors that are returned from network.
 
 While I agree with making that change, I still think the logic in
 tcp_usr_send is wrong.
 
 Looking at the code from HEAD, rather than RELENG_6, there's an
 immediate example of this problem in the handling of EPERM; tcp_output
 does not break the connection because the error could be transient due
 to a firewall rule change, but as the code stands, it will potentially
 get returned to the user via tcp_usr_send. This is wrong; the user
 should never see transient errors when sending on a TCP connection.
 
 It should not be possible for tcp_usr_send to return errors other than
 EWOULDBLOCK to its caller unless the connection has been broken (or did
 not get created).
 
 -- 
 Andrew, Supernews
 http://www.supernews.com
 
State-Changed-From-To: open->patched 
State-Changed-By: glebius 
State-Changed-When: Wed Feb 28 12:49:05 UTC 2007 
State-Changed-Why:  
Andrew's suggestion has been committed to HEAD. 

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

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/100172: commit references a PR
Date: Wed, 28 Feb 2007 12:47:58 +0000 (UTC)

 glebius     2007-02-28 12:47:49 UTC
 
   FreeBSD src repository
 
   Modified files:
     sys/netinet          tcp_output.c 
   Log:
   Add EHOSTDOWN and ENETUNREACH to the list of soft errors, that shouldn't
   be returned up to the caller.
   
   PR:             100172
   Submitted by:   "Andrew - Supernews" <andrew supernews.net>
   Reviewed by:    rwatson, bms
   
   Revision  Changes    Path
   1.124     +2 -0      src/sys/netinet/tcp_output.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: patched->closed 
State-Changed-By: glebius 
State-Changed-When: Thu Mar 22 10:55:30 UTC 2007 
State-Changed-Why:  
Merged to RELENG_6. 

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

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/100172: commit references a PR
Date: Thu, 22 Mar 2007 10:55:19 +0000 (UTC)

 glebius     2007-03-22 10:55:13 UTC
 
   FreeBSD src repository
 
   Modified files:        (Branch: RELENG_6)
     sys/netinet          tcp_output.c 
   Log:
   Carefully merge revs 1.123, 1.124, omitting the 1.120 change. This
   should fix resets of the long living TCP connections with
   EHOSTDOWN message.
   
   PR:             100172
   Submitted by:   "Andrew - Supernews" <andrew supernews.net>
   
   Revision   Changes    Path
   1.112.2.1  +24 -26    src/sys/netinet/tcp_output.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
>Unformatted:
