From owner-freebsd-net@FreeBSD.ORG Sat Apr 21 16:30:13 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 8D2B216A400 for ; Sat, 21 Apr 2007 16:30:13 +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 4EBD113C43E for ; Sat, 21 Apr 2007 16:30:13 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.197] (c220-239-255-86.rivrw3.nsw.optusnet.com.au [220.239.255.86]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id 404905C18; Sun, 22 Apr 2007 02:30:12 +1000 (EST) Message-ID: <462A3BF1.5070202@fromorbit.com> Date: Sun, 22 Apr 2007 02:29:37 +1000 From: Alan Garfield User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Yar Tikhiy 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> In-Reply-To: <20070420233619.GC52136@comp.chem.msu.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sat, 21 Apr 2007 16:30:13 -0000 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. Indeed that would appear to be the case. >> I'm sure it's something to do with how I'm doing the output. Does this >> look sane? > > Well, there's certain space for improvement, Aww it's not _that_ bad is it. :) hehe > but now I fail to find a > bug that would result in corrupted data. Phew /me wipes brow... so I'm not _totally_ useless then. :) > Would you mind testing the link with ping using packets of size > equal to, just below, and slightly above the mtu, and with different > data patterns? See -s and -p options to ping. You can observe the > patterns in echo replies with tcpdump -X. The data patterns in > echo requests and echo replies should be exactly the same. If they > aren't, the character of corruption can hint you at the bug. I've done a pretty preliminary tcpdump'ing and the packets seem ok above and below the MTU via the bpf taps. I wonder if it's a bug in the SP side... then again I could be completely off base and it's all my dodgy codes fault. :) I'll poke around with tcpdump and ping a bit more. Many thanks again Yar, Alan.