Re: Problems with ipfw/natd and axe(4)
Hi YongHyeon, Without natd this seems to work fine (both on RELEASE and CURRENT). Both my Hong-Kong no-name and Edimax EU-4208 seem to behave the same. This works with natd on RELEASE as well, but just for a limited time. I've yet to establish if it's time or #packets that cause the processing to stop. I'll try to generate some tcpdump output and compare working / non-working connected to NIC with txcsum/rxcsum disabled. Any pointers how to dig deeper? Kind regards, Spil. On Mon, May 13, 2013 at 6:36 AM, YongHyeon PYUN pyu...@gmail.com wrote: On Sat, May 11, 2013 at 12:04:09AM +0400, Gleb Smirnoff wrote: Spil, On Fri, May 10, 2013 at 09:06:35AM +0200, Spil Oss wrote: S There seems to be quite a bit of overhaul on the firewall code, pf and S ipfw have been moved to sys/netpfil? Can there be some regressions in S there that I hit? Yes, a regression is possible there. However, the issue seems to be axe(4) specific, since there are no reports on more common NICs. There was no change to axe(4) except added a new device id so it seems the issue is not in driver. In addition, AX88772B engineering sample I have works without problems on CURRENT. I didn't use ipfw(4) or natd though. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problems with ipfw/natd and axe(4)
On Sat, May 11, 2013 at 12:04:09AM +0400, Gleb Smirnoff wrote: Spil, On Fri, May 10, 2013 at 09:06:35AM +0200, Spil Oss wrote: S There seems to be quite a bit of overhaul on the firewall code, pf and S ipfw have been moved to sys/netpfil? Can there be some regressions in S there that I hit? Yes, a regression is possible there. However, the issue seems to be axe(4) specific, since there are no reports on more common NICs. There was no change to axe(4) except added a new device id so it seems the issue is not in driver. In addition, AX88772B engineering sample I have works without problems on CURRENT. I didn't use ipfw(4) or natd though. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problems with ipfw/natd and axe(4)
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@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 smi...@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@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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problems with ipfw/natd and axe(4)
Spil, On Fri, May 10, 2013 at 09:06:35AM +0200, Spil Oss wrote: S There seems to be quite a bit of overhaul on the firewall code, pf and S ipfw have been moved to sys/netpfil? Can there be some regressions in S there that I hit? Yes, a regression is possible there. However, the issue seems to be axe(4) specific, since there are no reports on more common NICs. S Just upgraded to r250404 but that does not help. Should I file a PR? Having a PR, with all information gathered in one report, is definitely better than not having one. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problems with ipfw/natd and axe(4)
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 smi...@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@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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
