Date: Thu, 19 Apr 2007 21:53:31 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Alan Garfield <alan@fromorbit.com> Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest Message-ID: <20070419175331.GA5999@comp.chem.msu.su> In-Reply-To: <1176990600.4177.26.camel@hiro.auspc.com.au> References: <1176861009.4426.21.camel@hiro.auspc.com.au> <20070418120622.GF40826@comp.chem.msu.su> <1176947814.4175.39.camel@hiro.auspc.com.au> <20070419073525.GA60301@comp.chem.msu.su> <1176972863.4177.7.camel@hiro.auspc.com.au> <20070419093847.GC60301@comp.chem.msu.su> <1176976273.4177.17.camel@hiro.auspc.com.au> <20070419113842.GE60301@comp.chem.msu.su> <1176990600.4177.26.camel@hiro.auspc.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070419175331.GA5999>