From owner-freebsd-net@FreeBSD.ORG Mon Apr 23 00:24:48 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 A832616A403 for ; Mon, 23 Apr 2007 00:24:48 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id 675C413C487 for ; Mon, 23 Apr 2007 00:24:48 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id CDF735E0C; Mon, 23 Apr 2007 10:24:46 +1000 (EST) From: Alan Garfield To: Yar Tikhiy In-Reply-To: <20070420233619.GC52136@comp.chem.msu.su> References: <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> <20070419175331.GA5999@comp.chem.msu.su> <1177077805.4063.7.camel@hiro.auspc.com.au> <20070420233619.GC52136@comp.chem.msu.su> Content-Type: text/plain Date: Mon, 23 Apr 2007 10:24:46 +1000 Message-Id: <1177287886.4075.15.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: 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 00:24:48 -0000 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 ---- 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. 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. Should I pad out the packet on the platform side to be the same as the SP? Thanks, Alan.