Luciano, I'm sending you the tcpdump log privately because attachments are not allowed on the mailing list. If anybody else wants it, just ask me offlist. For the record, I've noticed that also the Perl CPAN shell didn't work, but that may be other reasons too. Further comments inline. Thanks a thousand for any help, I'm really at my wits end with this. Ciao, Marco Fioretti On Sat, May 15, 2004 23:59:39 PM +0100, Luciano Miguel Ferreira Rocha (strange@xxxxxxxxxxxxx) wrote: > > How may times? Several, see attached log. > You could have a bad cable that's corrupting packets. It's the new one which came in the router box... Also, why should it mess only ssh packets, not email not web? I'll try with another when I get it, still... > Could you send the full tcp log for a connection? Sent offlist. I have masked the IP of the server (on sysadmin request) and grepped out email and web surfing. > > And could you answer a few questions: > > . Does the ADSL connection use ppp PPPoA > > . What system does the router run Some custom version of Linux/*BSD I guess. uname is not supported. When I login as root, and try to run the iptables command you suggested, I get: BusyBox v0.61.pre (2004.02.17-09:20+0000) Built-in shell (ash) Enter 'help' for a list of built-in commands. # iptables iptables v1.2.6a: no command specified Try `iptables -h' or 'iptables --help' for more information. # iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS iptables v1.2.6a: TCPMSS target: At least one parameter is required Try `iptables -h' or 'iptables --help' for more information. > > . How is it configured (routing and nating) # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 195.110.128.98 * 255.255.255.255 UH 0 0 0 ppp0 192.168.1.0 * 255.255.255.0 U 0 0 0 br0 239.0.0.0 * 255.0.0.0 U 0 0 0 br0 default net128-098.mcli 0.0.0.0 UG 0 0 0 ppp0 NAT, how do I check that? > Otherwise, try to reduce the MTU in your client PC. Both the router and the PC had MTU/MRU 1500. Setting it to 576 on both machines didn't changed anything. Whatever other command/check I can run to provide more info, just ask! The ssh -vvv session timed out like this after entering the password (entering a wrong password on purpose does return immediately "access denied"): debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug1: channel request 0: shell debug1: fd 3 setting TCP_NODELAY debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug1: channel_free: channel 0: client-session, nchannels 1 debug3: channel_free: status: The following connections are open: #0 client-session (t4 r0 i0/0 o0/0 fd 4/5) debug3: channel_close_fds: channel 0: r 4 w 5 e 6 Read from remote host the.ssh.server: Connection timed out Connection to the.ssh.server closed. debug1: Transferred: stdin 0, stdout 0, stderr 116 bytes in 1180.2 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1 debug1: Exit status -1 Oh, and the server sysadmin (MTU set to 576 there) said: >It finally occurred to me to see what logwatch had to say. It thinks >that you have been loggin in successfully, although each time the >login attempt fails the first time. After that, it seems to work. TIA, Marco Fioretti -- Marco Fioretti m.fioretti, at the server inwind.it Red Hat for low memory http://www.rule-project.org/en/ Great minds discuss ideas. Average minds discuss events. Small minds discuss people. -- Admiral Hyman Rickover
