Sockets stuck in SYN_RCVD (re(4), RELENG_7, i386)

[Oliver Fromme]

Pyun YongHyeon wrote:
 > On Tue, Nov 20, 2007 at 04:19:18PM +0100, Oliver Fromme wrote:
 > > Some additional information.
 > > 
 > > Today I have run the re(4) interface at 100 Mbps for a few
 > > hours.  The count did still increase, so it's not a GigE-
 > > only problem.
 > > 
 > > The I disabled RXCSUM,TXCSUM on the interface.  Again, the
 > > counter still increased.  So hardware checksumming isn't
 > > the cause of the problem either.
 > > 
 > > Anything else I could try?
 > 
 > re(4) is not smart enough to analyze packet payload. The hardware
 > also doesn't have a feature like TCP header split so I think re(4)
 > wouldn't have influence with TCP traffics by itself.

I see.  So it does not seem to be a bug in re(4).

My first suspect were the IPFW rules.  But they're quite
simple (only 20 rules) and I'm sure they're correct.
Apart from that, if it was a faulty rule that blocks
SYN+ACK packets or similar, then no TCP connections would
work at all.  And even in that case, the default timeout
for SYN_RCVD is very short (45 seconds I think), but not
several days.

So my current suspect is a bug in the syncache code.
That bug is probably triggered by something exceptional,
because I don't see the problem on any other machine,
not even on the one which is almost identical in hardware
and OS.

I would like to ask everybody to have a look at the
output from "sysctl net.inet.tcp.syncache.count".
Does anybody else have a non-zero value that slowly
increases?  If so, it would be interesting to find out
if there are any similarities with my machine.

 > Your dmesg indicates that you're using slightly old rgephy(4) on 7.0.
 > I touched rgephy(4) to support a newer PHY and fixed several bugs. If
 > speed/duplex mismatch was the cause of the issue you can see lots
 > of input errors from the output of "netstat -ndi" output. If so, try
 > latest rgephy(4).

I don't think that's the cause.  I tried with and without
auto-select, forcing the interface to 100 and GigE, and
all of that did not affect the behaviour at all.  The
error counters are all zero:

Name  Mtu Network  Address    Ipkts Ierrs    Opkts Oerrs  Coll Drop
re0  1500 <Link#1> [...]   28363007     0 25430349     0     0    0

 > > > net.inet.tcp.syncache.count: 702
 > > 
 > > It's now at 731.

And now at 832.  So it grows by more than 100 entries per
day.

Best regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd

 > Can the denizens of this group enlighten me about what the
 > advantages of Python are, versus Perl ?
"python" is more likely to pass unharmed through your spelling
checker than "perl".
        -- An unknown poster and Fredrik Lundh