Our system is based on FreeBSD 8.1. In some tests, we were having
issues caused by connections of this form (more details below):
TCP4 0 0 0/ 0/ 0127.0.0.1.665 127.0.0.1.665
FIN_WAIT_1
TCP4 0 0 0/ 0/ 0127.0.0.1.637 127.0.0.1.637
FIN_WAIT_1
In some of our tests, we noticed some duplicate pure ACKs (not window
updates), most of which the duplicates were coming from this tcp_output()
call in tcp_do_segment() (line 2534):
2508 } else if (V_tcp_do_rfc3042) {
2509
already know what else needs to
be done for that).
Just let us know if you want us to prepare the rest of the patch for that
new stat or not.
Thanks,
Matt
On Mon, Apr 8, 2013 at 8:13 AM, Andre Oppermann an...@freebsd.org wrote:
On 05.04.2013 13:09, Matt Miller wrote:
Hey Rick,
I believe Juan
Hey Rick,
I believe Juan and I have root caused this crash recently. The t_state =
0x1, TCPS_LISTEN, in the link provided at the time of the assertion.
In tcp_input(), if we're in TCPS_LISTEN, SO_ACCEPTCONN should be set on the
socket and we should never enter tcp_do_segment() for this state.
If we have a connection that has received a SYN and ip_output()
returns, say, EHOSTUNREACH, is there anything that guarantees the
connection would always eventually be dropped if the condition
persists?
E.g., similar to this case for ENOBUFS:
On Wed, Mar 13, 2013 at 3:35 PM, Chuck Swiger cswi...@mac.com wrote:
Hi--
On Mar 13, 2013, at 8:21 AM, Matt Miller wrote:
If we have a connection that has received a SYN and ip_output()
returns, say, EHOSTUNREACH, is there anything that guarantees the
connection would always eventually
In an OOM condition, we noticed a couple of mem_alloc handling bugs in
this file. Please let me know if a PR should be opened for these.
- No NULL checks after mem_alloc()'s:
SVCXPRT *
svc_xprt_alloc()
{
SVCXPRT *xprt;
SVCXPRT_EXT *ext;
xprt =
