Date: Fri, 10 May 2013 09:06:35 +0200 From: Spil Oss <spil.oss@gmail.com> To: freebsd-ipfw@freebsd.org, current <freebsd-current@freebsd.org> Subject: Re: Problems with ipfw/natd and axe(4) Message-ID: <CAEJyAvNL4NWmm8BMGkT6usZgGt2VWJNqQXeXBgYY9%2BMiNoUBVw@mail.gmail.com> In-Reply-To: <CAEJyAvO_KA8dYSLkFXCoBqcogTkurBX_X=KZn25R4MKoeUGaVQ@mail.gmail.com> 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> <CAEJyAvO_KA8dYSLkFXCoBqcogTkurBX_X=KZn25R4MKoeUGaVQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <spil.oss@gmail.com> 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 <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?CAEJyAvNL4NWmm8BMGkT6usZgGt2VWJNqQXeXBgYY9%2BMiNoUBVw>