On Tuesday, Feb 28, 2006, at 03:36 Australia/Sydney, matthew sporleder 
wrote:

> Does this ever make it into FIN_WAIT_2?

Both sockets eventually get cleaned up - whether it goes to
FIN_WAIT_2 or to CLOSING I don't know, I've never managed to
catch it in the act.

> Is it possibly related to the sysctl: net.inet.tcp.keepidle ?

I'd hope not - there is data queued, and a willing and waiting
reader. The data just never makes it to the other socket.

Why this only happens after ~20 days uptime seems, well, very
strange.

> On 2/27/06, Paul Ripke <stix@stix.id.au> wrote:
>> I have a system, with a PPPoE link to the 'net, running apache, and a
>> bunch of other junk. I've found, after about 20 days of uptime, I can
>> no longer access my web-server from the local machine's IP address on
>> the pppoe0 interface. Coming from anywhere else, it works fine. This
>> happens even when telneting to port 80. I see the socket pairs in the
>> following state, after issuing a http GET on the web-server root:
>>
>> Proto Recv-Q Send-Q  Local Address          Foreign Address        
>> State
>> tcp        0   3905  220.233.66.183.80      220.233.66.183.54061
>> FIN_WAIT_1
>> tcp        0      0  220.233.66.183.54061   220.233.66.183.80
>> ESTABLISHED
>>
>> To me, this looks wrong. The 3905 on the send-q pretty much matches
>> the size of the text I'd expect apache to return.
>>
>> The same query to port 80 on localhost works fine. The same query to
>> the private internal ethernet address also works fine. Likewise
>> to the wireless address.
>>
>> I normally have squid running, with an ipnat rule for transparent
>> proxying, but I've disabled all that after it stopped working.
>>
>> I do have ipf on the PPPoE interface, but disabling or flushing its
>> tables makes no difference. I also have altq on the PPPoE interface,
>> and stopping it doesn't appear to make any difference, either.
>>
>> Also, my 'net access seems fine, both in and out, NATed and direct,
>> via PPPoE.
>>
>> Anyone seen this before, or can give me any hints as to what to look
>> at? I have a matching netbsd.gdb, so online debugging is possible.
>>
>> BTW: System is pretty much stock NetBSD 3.0 x86, MULTIPROCESSOR
>> enabled, but hyperthreading disabled, so only 1 CPU.
>>
>> --
>> stix
>>
>>
>
>
--
stix