>
> 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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/li...enssh-unix-dev