[openssh] Re: Frequent "Connection reset by peer"

[Tuc at T-B-O-H.NET]

> 
> Tuc at T-B-O-H.NET wrote:
> >> Tuc at T-B-O-H wrote:
> >>> 	Is there a way to tell why I'm getting frequent 
> >>> "Connection reset by peer" all of a sudden? 
> >>>
> >>> 	I'm using a FreeBSD machine, plugged via eithernet to a Linksys 
> >>> router running DD-WRT, to another Linksys 50 feet away running DD-WRT, 
> >>> both of them WDS'd together, plugged via ethernet to another FreeBSD machine.
> >>> With debug cranked, I see :
> >> 1) check the SSH server's logs to see if there's any logged message 
> >> corresponding to the disconnects.  If the problem is easy to reproduce, 
> >> you could run sshd in debug mode in the foreground (eg "/path/to/sshd 
> >> -ddde -p 2022" then connect to port 22).
> >>
> >> 2) if that doesn't have anything, or has the same "connection reset by 
> >> peer message" then you probably will need to run tcpdump or similar to 
> >> see which end is generating the TCP RST (in theory it should be only 
> >> generated by one of the TCP endpoints but it could also be generated by, 
> >> eg an intermediate NAT box).
> >>
> > Hi,
> > 
> > 	Thanks for the reply...
> > 
> > 	1) Nothing out of the ordinary in the logs. 
> > 
> > 	Last bit of logging from the server before/after it happens :
> > 
> > debug3: tty_parse_modes: 93 0
> > debug1: server_input_channel_req: channel 0 request shell reply 0
> > debug1: session_by_channel: session 0 channel 0
> > debug1: session_input_channel_req: session 0 req shell
> > debug1: PAM: setting PAM_TTY to "/dev/ttyp4"
> > debug2: fd 5 setting TCP_NODELAY
> > debug2: channel 0: rfd 10 isatty
> > debug2: fd 10 setting O_NONBLOCK
> > debug2: fd 9 is O_NONBLOCK
> > debug1: Setting controlling tty using TIOCSCTTY.
> > debug3: mm_answer_pty: tty /dev/ttyp4 ptyfd 3
> > debug3: mm_request_receive entering
> > Read error from remote host 10.0.0.1: Connection reset by peer
> > debug1: do_cleanup
> > debug1: PAM: cleanup
> > debug3: PAM: sshpam_thread_cleanup entering
> > debug1: do_cleanup
> > debug1: PAM: cleanup
> > debug3: PAM: sshpam_thread_cleanup entering
> > debug1: session_pty_cleanup: session 0 release /dev/ttyp4
> > 
> > 	2) TCPDUMP available to anyone that wants it via email (21K)
> > 
> > The last "good" packet between the SSH server and client looked
> > pretty normal, has Flags of PSH and ACK.
> > 
> > The next packet comes from the router closest to the SSH server.
> > There is no sequence or acknowledgement number, but its claiming
> > to originate from the same port that the client originally was
> > using.  The window size is 1/2 of what the client/server window 
> > was. Its sending to the SSH server an ACK. 
> > 
> > The next packet is from the SSH server to the router, there
> > is no sequence number, window size is 0, Flags are RST.
> > 
> > Next packet is from the SSH server to the client, marked
> > as a TCP retransmission, same sequence as the last "good"
> > packet, PSH,ACK
> 
> Check the IP TOS bits on the packets as I think that's around the point 
> that it sets IPTOS_LOWDELAY.  I have heard that some NAT/firewall 
> devices can't handle a connection where the TOS changes mid-connection.
> 
> If you have netcat installed, you can try this:
> 
> ssh -o "ProxyCommand nc %h %p" yourserver
> 
> as a quick test.
> 
	There is no NAT enabled devices between system. There are no
SPI firewalls between systems. The 2 systems go out eithernet to a 
Linksys Router running DD-WRT thats basically been put into "DUMB" mode
and WDS'd together. 

	I think wireshark calls TOS "Differentiated Services Field".
About 31 packets in I see my client sending to the server 0x10,
which isn't that IPTOS_LOWDELAY? (From FreeBSD netinet/ip.h :

#define IPTOS_LOWDELAY          0x10

	Trouble doesn't seem to star until about 104 packets in. 
TOS is set to 0x10 about 76 times in the entire conversation.

	I ran what you said, and the first one ran for about
2 minutes and then :

Connection to 10.0.0.6 closed by remote host.
Connection to 10.0.0.6 closed.

	And the 2nd time about 20 seconds before the same.

		Thanks, Tuc