This just verifies what I said weeks ago. On the client side:
## several packets are lost here due to congestion, thanks to TCP_NODELAY: 15:28:09.879928 transwarp.tao.org.uk.telnet > genius.tao.org.uk.kpop: P 609:641(32) ack 64 win 33304 15:28:09.881926 transwarp.tao.org.uk.telnet > genius.tao.org.uk.kpop: P 993:1025(32) ack 64 win 33304 ## client only acks up to 641 after this: 15:28:09.881964 genius.tao.org.uk.kpop > transwarp.tao.org.uk.telnet: . ack 641 win 33304 On the server side: 15:28:18.291734 genius.kpop > transwarp.telnet: . ack 641 win 33304 ## server resends 641:1057 after a timer expired, 1 second seems long? 15:28:19.288745 transwarp.telnet > genius.kpop: P 641:1057(416) ack 64 win 33304 Conclusion: This is a OpenSSH problem, not a FreeBSD problem. -Tomas Friday, December 28, 2001, 4:33:30 PM, you wrote: JK> On Fri, Nov 30, 2001 at 03:45:21PM -0800, Matthew Dillon wrote: >> :... >> :> I am tracking it down now. >> : >> :Is this the same problem that I experience on ssh connections between >> :my 5.0-current laptop and my releng_4 server? When I run an 'ls' >> :from the shell on large directories I get the response back block >> :delay block delay block. I assumed that it was a problem with >> :-current. >> : >> :Joe >> >> It sounds like the same problem. In fact, I seem to recall observing >> something very similar from my laptop while ssh'd into one of my >> servers, but at the time I though it was a hicup in the wireless network. >> Now though I think it was this same issue. JK> Ok, at last, here's the tcpdumps from both ends. JK> On the client (genius.tao.org.uk -current) I 'ssh -p 23 transwarp' JK> and from there 'ls -l /usr/src'. The tcpdump is from when I hit JK> return on the ls command. The server (transwarp.tao.org.uk) is running JK> -stable. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
