From owner-freebsd-ipfw@FreeBSD.ORG Wed Apr 17 05:03:27 2013 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9E795FFE for ; Wed, 17 Apr 2013 05:03:27 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id EAE25A82 for ; Wed, 17 Apr 2013 05:03:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id r3H53HMc094293; Wed, 17 Apr 2013 15:03:17 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 17 Apr 2013 15:03:17 +1000 (EST) From: Ian Smith To: Spil Oss Subject: Re: Problems with ipfw/natd and axe(4) In-Reply-To: Message-ID: <20130417133637.W56386@sola.nimnet.asn.au> References: <20130415015850.Y56386@sola.nimnet.asn.au> <20130415160625.K56386@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org, Michael Sierchio X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 05:03:27 -0000 On Tue, 16 Apr 2013 20:52:05 +0200, Spil Oss wrote: > Hi all, > > If I disable checksum offloading on the NIC I do the tcpdump on, then I > assume that the checksum-check will provide accurate results? It certainly should. > With checksum disabled, I see that the checksum is incorrect when the > client does not respond to the SYN,ACK, and correct when it does. I'm having trouble fully parsing that. Using 'tcpdump -vr ue0-ssh-fail.pcap | less -S' shows these incorrect checksums alright; before adding -v I'd only noticed 172.17.2.1 sending SYNs and clearly not responding to 172.17.2.111's SYN/ACKs. Since it works ok with the divert rule bypassed - presumably still with tx/rxcsum enabled - then it seems that (surprise!) Luigi picked the issue being in natd / divert socket handling. > Out of curiousity I tried with pf as well and it behaves the same. Can't comment on that. What's not clear is why the NIC "doesn't work" (symptoms?) with -txcsum -rxcsum. With the 'fail' pcap it seems the received checksum from the client SYN is ok on capture, and the server is responding with SYN/ACK (with mangled cksum), but the rxcsum must be ok after natd, so maybe it's only -txcsum needed? Might that work? Sorry, I'm just bouncing around on what I can see from here and could be missing something someone else might find obvious, I'm just an amateur.. > On Mon, Apr 15, 2013 at 9:04 PM, Spil Oss wrote: > > Network dumps as promised > > On 172.17.2.1: > > tcpdump -p -i bridge0 -s 0 -w ssh-fail.pcap host not 172.17.2.167 You didn't post that one; I assume it showed the bad cksums back from 172.17.2.111? ie that the SYN/ACK packet make it to the client's interface, but was dropped for its bad cksum on the client side? > > From 172.17.2.1 I ran > > telnet 172.17.2.111/157 22 > > In Wireshark I trimmed the capture a bit further with expression > > 'not stp and not http' > > > > Initial setup (ue0 ext, re0 int, rule 10 to allow ssh) > > -> ue0-ssh-success.pcap > > Removed rule 10 > > -> ue0-ssh-fail.pcap > > Switched re0 and ue0, default ruleset (without 10) > > -> re0-ssh-success.pcap > > > > According to YungHyeong the sample ASIX NIC he has works normally when > > checksumming is disabled. I guess trying another of the same NIC is the only way to rule out a faulty unit? I'm having similarly frustrating issues with a cardbus USB2 card, unrelated but proving just as indeterminate .. [..] > >> Does anyone know whether this is an issue with libalias(3) generally - > >> in which case using nat instead of divert shouldn't help - or just with > >> natd in particular? Question still stands .. I could redo that rc.firewall patch for nat in 'simple' but if the problem is with libalias(3) it won't help with this. cheers, Ian