Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!shelby!agate!ucbvax!RIMFAXE.DIKU.DK!thorinn
From: thorinn@RIMFAXE.DIKU.DK (Lars Henrik Mathiesen)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: problems with nsfnet-relay.ac.uk
Message-ID: <9102281006.AA28115@rimfaxe.diku.dk>
Date: 28 Feb 91 10:06:42 GMT
References: <1991Feb27.142600.8252@mp.cs.niu.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 43


   Date: 27 Feb 91 14:26:00 GMT
   From: rickert@mp.cs.niu.edu  (Neil Rickert)

    It is really enjoyable reading all of these sinister theories.

    Did it occur to anyone that perhaps, in the aftermath of the link having
   been down, the machine is struggling to handle the backlog and can't always
   keep up with the volume of incoming SMTP connections.

When I saw this, I didn't think that that could be the explanation, so
I looked in our kernel. I was rather surprised to find that if there
are more than the allowed number of new connections waiting to be
accept()ed, the Berkeley TCP will summarily drop incoming SYNs (no
ICMP whatever, no RST). I suppose the idea is that the congestion is
temporary and the SYN will be retransmitted. Maybe a source quench
would be appropriate?

Anyway, there's a sun.nsfnet-relay.ac.uk that advertises SMTP in its
WKS record:

    sun.nsfnet-relay.ac.uk. 360000  A       128.86.8.7
    sun.nsfnet-relay.ac.uk. 360000  MX      13 nsfnet-relay.ac.uk.
    sun.nsfnet-relay.ac.uk. 360000  HINFO   SUN-4 SUNOS
    sun.nsfnet-relay.ac.uk. 360000  WKS      128.86.8.7 tcp (
			     ftp smtp )

I can connect to SMTP on that host, so it doesn't seem to be filtered.
Interestingly, from Europe this is routed through 192.16.192.185:

    ;; ANSWERS:
    185.192.16.192.in-addr.arpa.    15594   PTR     sun.nsfnet-relay.ac.uk.

    ;; AUTHORITY RECORDS:
    192.16.192.in-addr.arpa.        447592  NS      MCSUN.EU.NET.
    192.16.192.in-addr.arpa.        447592  NS      SERING.CWI.NL.

but it doesn't seem to the same machine (doesn't do telnet, for
instance).

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn@diku.dk