From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 17:53:36 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B162516A404 for ; Thu, 19 Apr 2007 17:53:36 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id DE1D413C448 for ; Thu, 19 Apr 2007 17:53:35 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l3JHrX9c007289; Thu, 19 Apr 2007 21:53:33 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l3JHrWg1007286; Thu, 19 Apr 2007 21:53:32 +0400 (MSD) (envelope-from yar) Date: Thu, 19 Apr 2007 21:53:31 +0400 From: Yar Tikhiy To: Alan Garfield Message-ID: <20070419175331.GA5999@comp.chem.msu.su> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1176990600.4177.26.camel@hiro.auspc.com.au> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2007 17:53:36 -0000 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