On Tue, 05 Mar 2002 17:40:37 -0500
"Steven M. Bellovin" <smb@research.att.com> wrote:

> Can you run tcpdump on the network in question, to see what packets are 
> emitted?  I see a long delay when running ssh to a 486/50 I have lying 
> around, but this sounds worse.  I suspect a network cause, such as a 
> DNS timeout or a fruitless attempt at a v6 connection.  You've 
> obviously thought about some of that, too, but it might be worth 
> looking at the wire to see what's actually happening.

OK here goes

First the client makes an IPv6 simple forward lookup of the destination
hostname, which fails, so it does an IPv4 lookup which succeeds. With the
-4 option the client does not do the IPv6 lookup.

Then there's 8 packets of ssh data sent from the client to the (NetBSD)
daemon, interleaved with this there's 6 packets sent back from the daemon
to the client. The server sends the last packet before a 3 minute wait. I
presume this is SSH2_MSG_KEX_DH_GEX_GROUP from the daemon debug output,
while the client is waiting for SSH2_MSG_KEX_DH_GEX_REPLY.

The daemon waits (for a valid response?) for 3 minutes, then it kicks off
again - it transmits the first packet of the continuation of the ssh
negotiation, in which it transmits 4 packets and recieves 6 replies, the
daemon then does a reverse DNS lookup of the client IP, then it does a
normal forward lookup of the result to I presume get the canonical name of
the client. There's a further 2 packets of ssh data exchanged in each
direction but that maybe just the login banner and $ prompt.

There are no failed DNS lookups, no IPv6 traffic and the timeout occurs
during the negotiation between client and daemon, not during client to DNS
or daemon to DNS etc.

-Andrew

-- 
sparc sun4c stuff : http://www.lostgeneration.freeserve.co.uk/sparc
personal email    : bob at lostgeneration dot freeserve dot co dot uk