Date: Thu, 9 May 2013 10:56:54 +0200 From: Spil Oss <spil.oss@gmail.com> To: freebsd-ipfw@freebsd.org, current <freebsd-current@freebsd.org> Cc: pyunyh@gmail.com, Ian Smith <smithi@nimnet.asn.au> Subject: Re: Problems with ipfw/natd and axe(4) Message-ID: <CAEJyAvO_KA8dYSLkFXCoBqcogTkurBX_X=KZn25R4MKoeUGaVQ@mail.gmail.com> In-Reply-To: <20130417133637.W56386@sola.nimnet.asn.au> References: <CAEJyAvOZ6fW0i3yT_D4fH1huje-qsJwA7GGeXqAO1PKzge-YNw@mail.gmail.com> <20130415015850.Y56386@sola.nimnet.asn.au> <CAHu1Y73Xu64NY1B=idaKmHKDGOB3AHbcXKi4A48-SNkhJrMy6Q@mail.gmail.com> <20130415160625.K56386@sola.nimnet.asn.au> <CAEJyAvP-4FZ7eZ0o4c3qMzC0nY_gT4GfS3KjBVQiuzNY3aXz4Q@mail.gmail.com> <CAEJyAvMGKr9gZEEhg2KCD2FkZ=F4Xbx20v8iWyu8hhA_Pq8phw@mail.gmail.com> <20130417133637.W56386@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <smithi@nimnet.asn.au> 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 <spil.oss@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEJyAvO_KA8dYSLkFXCoBqcogTkurBX_X=KZn25R4MKoeUGaVQ>