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_at_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_at_) > > 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_at_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_at_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, IanReceived on Fri May 10 2013 - 05:06:36 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:37 UTC