From owner-freebsd-net@FreeBSD.ORG Mon Apr 23 14:54:35 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 BA84616A400 for ; Mon, 23 Apr 2007 14:54:35 +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 E0E2E13C4B7 for ; Mon, 23 Apr 2007 14:54:34 +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 l3NEsWFk023775; Mon, 23 Apr 2007 18:54:32 +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 l3NEsUVK023773; Mon, 23 Apr 2007 18:54:31 +0400 (MSD) (envelope-from yar) Date: Mon, 23 Apr 2007 18:54:30 +0400 From: Yar Tikhiy To: Alan Garfield Message-ID: <20070423145429.GF66604@comp.chem.msu.su> References: <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> <20070419175331.GA5999@comp.chem.msu.su> <1177077805.4063.7.camel@hiro.auspc.com.au> <20070420233619.GC52136@comp.chem.msu.su> <1177287886.4075.15.camel@hiro.auspc.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1177287886.4075.15.camel@hiro.auspc.com.au> User-Agent: Mutt/1.5.9i Cc: freebsd-net@freebsd.org Subject: Re: Corrupt packets in Jnet (Was: 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: Mon, 23 Apr 2007 14:54:35 -0000 On Mon, Apr 23, 2007 at 10:24:46AM +1000, Alan Garfield wrote: > On Sat, 2007-04-21 at 03:36 +0400, Yar Tikhiy wrote: > > > > ---- > > > Disconnecting: Corrupted MAC on input. > > > ---- > > > > That looks like data corruption happening when TCP segments and/or > > IP packets become relatively large, i.e., approach or reach the mtu > > limit. > > The reply looks disturbing from the SP (note the packet size).... > > ---- > IP (tos 0x0, ttl 64, id 2493, offset 0, flags [none], proto: ICMP (1), > length: 108) 169.254.101.3 > 169.254.101.2: ICMP echo request, id 31748, > seq 3, length 88 > 0x0000: 4500 006c 09bd 0000 4001 52d2 a9fe 6503 > 0x0010: a9fe 6502 0800 843d 7c04 0003 462b fbe5 > 0x0020: 0001 c4b7 abcd efab cdef abcd efab cdef > 0x0030: abcd efab cdef abcd efab cdef abcd efab > 0x0040: cdef abcd efab cdef abcd efab cdef abcd > 0x0050: efab cdef abcd efab cdef abcd efab cdef > 0x0060: abcd efab cdef abcd efab cdef > IP (tos 0x0, ttl 255, id 57441, offset 0, flags [none], proto: ICMP (1), > length: 108) 169.254.101.2 > 169.254.101.3: ICMP echo reply, id 31748, > seq 3, length 88 > 0x0000: 4500 006c e061 0000 ff01 bd2c a9fe 6502 > 0x0010: a9fe 6503 0000 8c3d 7c04 0003 462b fbe5 > 0x0020: 0001 c4b7 abcd efab cdef abcd efab cdef > 0x0030: abcd efab cdef abcd efab cdef abcd efab > 0x0040: cdef abcd efab cdef abcd efab cdef abcd > 0x0050: efab cdef abcd efab cdef abcd efab cdef > 0x0060: abcd efab cdef abcd efab cdef 0000 0000 > 0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0090: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x00a0: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x00b0: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x00c0: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x00d0: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x00e0: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x00f0: 00 > ---- Nothing wrong with the length, it's 241 bytes, the size of the buffer less that of the Ethernet header. As we concluded, Jnet has no means for indicating the exact size of the Ethernet frame, so the whole buffer has to be considered as such. BPF works at the link layer, so tcpdump shows you the frame's complete payload, not only the IP packet. The extra 0's at the end will be trimmed off by ip_input() based on the packet length field in the IP header -- note that it's correctly set to 108 bytes. > So obviously it cannot deal with fragmented packets. A ping over 213 > will over flow the packet and make the ping request fragment, the other > side simply drops it to the floor. This conclusion doesn't seem to follow from the above observation. Dropping fragmented IP packets can be a quirk of the Linux if it does so. > But that still doesn't make sense with SSH complaining about a corrupt > MAC on input. I see no corruption here only dumped packets if they are > over-sized. Perhaps the bug is triggered when the outgoing packet consists of multiple mbufs. ping sends its packet to the kernel as a single message while sshd can do smaller writes to the socket which get coalesced into a TCP segment. Now I can only think of the following test: run "sshd -d" under ktrace and compare the data it writes to the network socket with the data actually sent to Jnet via jnet_start(). A debug printf in jnet_start() will be needed to see the data at the lowest level possible. Other possible options for collecting genuine data sent by sshd are: - a netgraph using ng_ether and ng_eiface - a data tap between "sshd -i" and inetd - higher debug levels of sshd (I've never investigated them) I'd also test if the ssh from SP can work OK with a FreeBSD host (the same FreeBSD version as on the platform side would be the best) via the external Ethernet. If nothing helps at all, device access timing can be the cause. Can the device ports written to/read from in a loop without a delay? > Should I pad out the packet on the platform side to be the same as the > SP? Your jnet_start() routine fills the tail of the buffer w/zeros already, doesn't it? -- Yar