Call for testing for 3.5 OpenSSH

[Kevin Steves]

On Mon, Sep 23, 2002 at 07:17:12PM -0700, Dan Kaminsky wrote:
> Here, lemme see if I can whip up something a bit more useful.  I don't 
> know exactly what's causing it, but there's a second-level timeout 
> somewhere in here.  I fired up tethereal, and monitored the inter-packet 
> timings on a standard SSH2 login.  Here's the absolute timing -- notice 
> time-to-password is about 3 seconds, but in CVS we're up to 12.

i see:

02:38:59.242589 10.0.1.37.1697 > 10.0.1.11.22: P 1135:1663(528) ack 1848 win 64112 (DF)
02:38:59.244545 10.0.1.11.22 > 10.0.1.37.1697: P 1848:1928(80) ack 1663 win 17520 (DF)
02:38:59.414651 10.0.1.37.1697 > 10.0.1.11.22: . ack 1928 win 64032 (DF)
02:39:00.128602 10.0.1.37.1697 > 10.0.1.11.22: P 1663:1759(96) ack 1928 win 64032 (DF)
02:39:00.128806 10.0.1.11.22 > 10.0.1.37.1697: P 1928:2008(80) ack 1759 win 17520 (DF)
02:39:00.317401 10.0.1.37.1697 > 10.0.1.11.22: . ack 2008 win 63952 (DF)

02:39:06.771482 10.0.1.37.1697 > 10.0.1.11.22: F 1759:1759(0) ack 2008 win 63952 (DF)
02:39:06.771509 10.0.1.11.22 > 10.0.1.37.1697: . ack 1760 win 17520 (DF)
02:39:06.771825 10.0.1.11.22 > 10.0.1.37.1697: F 2008:2008(0) ack 1760 win 17520 (DF)
02:39:06.772053 10.0.1.37.1697 > 10.0.1.11.22: . ack 2009 win 63952 (DF)

and:

02:39:12.504504 10.0.1.37.1748 > 10.0.1.11.22: P 1127:1655(528) ack 1848 win 64112 (DF)
02:39:12.506264 10.0.1.11.22 > 10.0.1.37.1748: P 1848:1928(80) ack 1655 win 17520 (DF)
02:39:12.511981 10.0.1.37.1748 > 10.0.1.11.22: P 1655:1751(96) ack 1928 win 64032 (DF)
02:39:12.512112 10.0.1.11.22 > 10.0.1.37.1748: P 1928:2008(80) ack 1751 win 17520 (DF)
02:39:12.654619 10.0.1.37.1748 > 10.0.1.11.22: . ack 2008 win 63952 (DF)

02:39:14.723140 10.0.1.37.1748 > 10.0.1.11.22: F 1751:1751(0) ack 2008 win 63952 (DF)
02:39:14.723165 10.0.1.11.22 > 10.0.1.37.1748: . ack 1752 win 17520 (DF)
02:39:14.723476 10.0.1.11.22 > 10.0.1.37.1748: F 2008:2008(0) ack 1752 win 17520 (DF)
02:39:14.723709 10.0.1.37.1748 > 10.0.1.11.22: . ack 2009 win 63952 (DF)

which appears to be a different delay at the password prompt before
entering ^c causing the client to start a close with FIN.