other network problems with hosts at internic.net

Sun Nov 15 02:19:51 UTC 1998

[ On Fri, November 13, 1998 at 12:13:38 (-0800), Marc Slemko wrote: ]
> Subject: Re: other network problems with hosts at internic.net
>
> This same thing is happening to me, but in my case it is a bug in the
> InterNIC's whois server that must have just been introduced recently.

I have the same problem contacting their web server, and sometimes even
with telnet and ftp to their servers.

> AFAIK, the whois protocol is supposed to consist of a request terminated
> by a '\n'.  However, the InterNIC's server is sending a response as soon
> as it gets the first packet, even if there is no \n termination.

The NetBSD whois client uses stdio, and sends the last argument with a
single fprintf() call followed by an fflush().

BTW, the NetBSD client sends "\r\n" on the end of the data sent to the
server.

> There is at least one common whois replacement client that sends the \n in
> a separate packet.  What happens is the first packet with the request but
> without the \n arrives at the InterNIC, then they send a response and
> close the socket.  In the meantime, the second packet from the client with
> the \n in arrives after the socket is closed for reading, prompting a RST
> from the server.  Even though the full response is either in socket
> buffers at the InterNIC or on the wire or even in socket buffers on the
> client, once the RST arrives that response will be (correctly) thrown away
> if it hasn't been actually read() by the client.

The exact same whois.c client code running on my NetBSD-1.3.x boxes
fails to retrieve the complete response, yet when run on at least the
BSDI 1.1 box it works fine.

> The reason you see part of it is that the whois server is sending separate
> packets for the "\nRegistrant:\n" part and the rest of the response.
> 
> The fix is for the InterNIC to fix their whois server to conform to the
> "protocol" and/or do a lingering close so it doesn't send a RST.  Simply
> waiting for the end of the line should be enough and should be correct,
> although if they really want to do a lingering close then see the
> lingering_close() function in Apache for an example.

That might indeed help, but I'm not going to put the blame on them
immediately since I know that even when I make the connection from my
NetBSD boxes the packets are making it back as far as the machine on the
far end of my PPP link.

The only apparent difference between connections that work, and
connections that don't, for me at least, is the initial window size.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>      <robohack!woods>
Planix, Inc. <woods at planix.com>; Secrets of the Weird <woods at weird.com>