[ On Mon, January 13, 1997 at 09:48:48 (+0000), Philip Hazel wrote: ]
> Subject: Re: Paniclog contents?
>
> Now that I think about it, of course, I remember that TCP/IP is a
> two-way independently routed protocol, and it is presumably possible for
> an incoming packet to arrive and the response to fail in these ways.
> Apologies for not thinking of this when I wrote the code - in fact what
> I did was to copy the code that is in smail, which (I've just checked)
> does exactly the same thing. It contains the following comment:
>
> /*
> * for some reason, accept() fails badly (and repeatedly)
> * on some systems. To prevent the paniclog from filling
> * up, exit if this happens too many times.
> */
>
> I don't know if this is still the case on modern OS, but I copied the
> logic just in case. There is a pause of 5 seconds after each such error.
Philip, your explanation sounds plausible, but not for 4BSD I think.
In reading TCP/IP Illustrated V2, and the NetBSD source code, I note
that there's an undocumented error return: ECONNABORTED, which occurs
if the socket state becomes SS_CANTRCVMORE.
According to Stevens' description though, the socket layer shouldn't be
notified of an incoming connection until after the three-way handshake
has been successfully completed. To me this implies that accept() will
never awaken if the routing is asymetric and the reply SYN&ACK cause a
"host unreachable".
All he says about asynchronous errors during the accept is that they can
occur, but no further details of what they might be, how, why, etc.
--
Greg A. Woods
+1 416 443-1734 VE3TCP robohack!woods
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
