Odd tcp dump? was: ssh working with dialup, not through router

M. Fioretti mfioretti at mclink.it
Tue May 18 20:01:37 UTC 2004


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

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.

	Marco Fioretti

On Sat, May 15, 2004 23:59:39 PM +0100, Luciano Miguel Ferreira Rocha
(strange at nsk.no-ip.org) 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
> . 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  *      UH    0      0   0 ppp0     *        U     0      0   0 br0       *            U     0      0   0 br0
default         net128-098.mcli         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

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
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. 

	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

More information about the fedora-list mailing list