"Can't read stream because the TCP connection..."
Wed, 17 Jul 2002 21:16:02 -0700
On Fri, 12 Jul 2002 10:10:00 -0400 in message <010401c229ad$d540a5e0$0560a8c0@RKRATOCHWILL>, "Rodney Kratochwill" <email@example.com> wrote:
> Not sure if this is related to the problem Doc is having, but there is an
> article on MacFixit about MTU settings causing problems in some cases,
> especially with PPPoE connections. Not sure whether your cable connection
> is using PPPoE or not but thought I'd mention it just in case.
A co-worker just ran into this in a win2k/MSIE client -> osx server (8.05, 10.1.5). Connections would just appear to hang on the w2k side of things.
>From the osx machine, I see: (netstat -n | head -n 10)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 500 0 192.168.1.89.80 192.168.1.101.1300 ESTABLISHED
tcp 502 0 192.168.1.89.80 192.168.1.101.1299 ESTABLISHED
Which indicates 2 connections that have a recieve queue of about half a K. This state was maintained for a little while, long enough to find terminal.app and run the commands.
This would _seem_ to indicate that it's an OS level problem and not something that's isolated to either a radio client or a win2k server. According to him, this happens at no predictable interval, but usually once a day or so. Quitting and restarting frontier seems to clear things up. This would seem to indicate that there is some interaction with the app that makes a difference. The frontier server is running on a kernel port forwarded setup.
Lan layout in this case is that both machines are connected to the same 100bT hub (not a switch), so there is no duplex issue to contend with.
>From the fact that there are items in the queue, I'm not sure that that indicates that there might be a dropped packet problem, as people have been theorizing in this thread. It would seem that if that was the case, then there wouldn't be data in the queue. It's possible that the kernel is wating for a tcp packet fragment to reassemble into a full packet before forwarding to the port frontier is listening on, although I'm not sure how a packet would get fragmented on a lan.
I'll probably be looking at this in a little more detail the next time it happens.