From owner-freebsd-current@FreeBSD.ORG Fri May 10 07:06:36 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 198FBC73; Fri, 10 May 2013 07:06:36 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id D78AE2DA; Fri, 10 May 2013 07:06:35 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id a14so7322308iee.41 for ; Fri, 10 May 2013 00:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=T71cCx0AaUPydO5tEwTcsqZh7xYRgI5feOaUsdV3FDg=; b=Y+jARyJbsXrd4rVHEtgDBkZiNNEx1An6p0xHrJ4k0+ZYXnGNyovL0jE3GxVkH3nzc1 4YQ4zsZGCHPyepeGyhzn10WeZDcAtc/rtDvDABSiyxhWpueKn81Yy0FoSmVO5/utzXga mKY3mBPFGPRDMY60C4omkU2PVlD8jEIGRhZyIvOcJ1tZ3+znEaZAOiSOoAMVxlqX3r7l APSQUCVMz895vxdlfy5468BVoFksPi56q22cpXZfFDhX3VNFqsaE++bMcv9vMC03sbP+ K82K2N58GJajUd308g41jWjUamCOtrJPaqYeAC5zmgAQwjw+ymPlwJCMse+YsXHUYWvq Jskw== MIME-Version: 1.0 X-Received: by 10.50.29.9 with SMTP id f9mr1037120igh.38.1368169595642; Fri, 10 May 2013 00:06:35 -0700 (PDT) Received: by 10.42.189.4 with HTTP; Fri, 10 May 2013 00:06:35 -0700 (PDT) In-Reply-To: References: <20130415015850.Y56386@sola.nimnet.asn.au> <20130415160625.K56386@sola.nimnet.asn.au> <20130417133637.W56386@sola.nimnet.asn.au> Date: Fri, 10 May 2013 09:06:35 +0200 Message-ID: Subject: Re: Problems with ipfw/natd and axe(4) From: Spil Oss To: freebsd-ipfw@freebsd.org, current Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 07:06:36 -0000 Hi, There seems to be quite a bit of overhaul on the firewall code, pf and ipfw have been moved to sys/netpfil? Can there be some regressions in there that I hit? Just upgraded to r250404 but that does not help. Should I file a PR? Kind regards, Spil. On Thu, May 9, 2013 at 10:56 AM, Spil Oss wrote: > Hi all, > > So I bought another AX88772B part, this time an Edimax UE-4208 and it > behaved exactly like the no-name part I bought on eBay. > > Looking at YongHyeong's feedback on his engineering sample I decided > to revert back to 9.1-RELEASE and try again, this works like expected. > (see my post > "Problems with axe(4) and checksum offloading" thread started Apr 7 in > freebsd-current@) > > So somewhere between 9.1-RELEASE and 10-CURRENT r248351 there's a > regression that breaks this. Any pointers on getting this to work? > > Kind regards, > > Spil. > > On Wed, Apr 17, 2013 at 7:03 AM, Ian Smith wrote: >> 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