From owner-freebsd-current@FreeBSD.ORG Thu May 9 08:56:55 2013 Return-Path: Delivered-To: freebsd-current@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 28C1AF9E; Thu, 9 May 2013 08:56:55 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id E7FB79BA; Thu, 9 May 2013 08:56:54 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id b11so5008788iee.37 for ; Thu, 09 May 2013 01:56:54 -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:cc:content-type; bh=YInPpZH2hSttC0xXAF4+fwiDjuZCVGRy37zK2ss9Rnc=; b=shQmiR3tgmB8kmtmL3betv0SG58xmLNTbUiRT6dXCe9QDZ61aNhxnLOAGyHyU1qHnD pUJOe4r/IEsysgSo4BsuCPfCVk/5ySY1sPcDGCeK/Iiw1kUq9/XSa0NKnVAgU3nZjTdt gdc3VHiTWNMNZ/43VLGrIjXzN6A+exILtFNXydNEgVJkHtz58FlsIl48OKHWm15Aybms Q667AI0HILTbrtMIIhYOehI1sgj9nnupC1j1VepQlxy/fppuQJp2VTahQhXxYjKbh9Ut e5tNr8/qMM1DRypgIHTANkN3zkyIaV/HRjNAl5ewGOlxLxMFffOw1+Px7S8LDZ+0druR S/2A== MIME-Version: 1.0 X-Received: by 10.50.140.73 with SMTP id re9mr7813550igb.59.1368089814647; Thu, 09 May 2013 01:56:54 -0700 (PDT) Received: by 10.42.189.4 with HTTP; Thu, 9 May 2013 01:56:54 -0700 (PDT) In-Reply-To: <20130417133637.W56386@sola.nimnet.asn.au> References: <20130415015850.Y56386@sola.nimnet.asn.au> <20130415160625.K56386@sola.nimnet.asn.au> <20130417133637.W56386@sola.nimnet.asn.au> Date: Thu, 9 May 2013 10:56:54 +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 Cc: pyunyh@gmail.com, Ian Smith 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: Thu, 09 May 2013 08:56:55 -0000 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