On Thu, Apr 19, 2007 at 11:50:00PM +1000, Alan Garfield wrote: [...] > > BUT! Now I have a weird bug. > > SSH on the SP whinges about :- > > ---- > localhost $ ssh -v 169.254.101.3 > OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090703f > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Applying options for * > debug1: Rhosts Authentication disabled, originating port will not be > trusted. > debug1: ssh_connect: needpriv 0 > debug1: Connecting to 169.254.101.3 [169.254.101.3] port 22. > debug1: Connection established. > debug1: identity file /home/manager/.ssh/identity type -1 > debug1: identity file /home/manager/.ssh/id_rsa type -1 > debug1: identity file /home/manager/.ssh/id_dsa type -1 > debug1: Remote protocol version 2.0, remote software version > OpenSSH_4.5p1 FreeBSD-20061110 > debug1: match: OpenSSH_4.5p1 FreeBSD-20061110 pat OpenSSH* > Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_3.4p1 > debug1: SSH2_MSG_KEXINIT sent > d475 078f 7eae aef6 > Disconnecting: Bad packet length -730527857. > debug1: Calling cleanup 0x1001fc68(0x0) > localhost $ > ---- > > ... bad packet length! UGH! :) > > Since there is no telnet, vi or any other _testable_ services on the SP > I'm stuffed to figure out what's wrong with the packets on the SP side. > I can tcpdump on the platform side and everything looks peachy.
1. Ping the Linux side with packets close to the MTU in size (ping -s), use different data patterns (ping -p), see with tcpdump -X if the data gets damaged. 2. Capture a broken SSH session (tcpdump -s0 -w ssh.cap) and analyze it off-line with Ethereal/Wireshark (I hope it has a dissector for SSH). The sessions doesn't reash encryption, so the damage should be clear. > How can I look at the tcp packet length in the data? tcpdump -v, but it seems to be SSH packet length, not TCP one. AFAIK, the SSH protocol utilizes packets of its own over the TCP stream. > > > Yeah it's what the Linux driver is called. Can be something else, got a > > > better name? :) > > > > Perhaps just "jn"? Some utilities still have trouble with long > > interface names[1], and they are a drag to type in. :-) So I'd > > rather keep the name as short as possible. > > Yeah 'jn' sounds ok to me. Although it's really not going to be that > common unless you have these SunFire or NewISys servers. :) Nevertheless, it can be a reference driver working with real hardware for other folks to study. -- Yar _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
