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)
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)
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 axe(4) and checksum offloading
Hi YongHyeon, Will post on freebsd-ipfw@ as well... Does your engineering sample function normally with rxcsum/txcsum disabled? Kind regards, Spil. On Thu, Apr 11, 2013 at 3:11 AM, YongHyeon PYUN pyu...@gmail.com wrote: On Wed, Apr 10, 2013 at 07:48:00PM +0200, Spil Oss wrote: Hi YongHyeon, With the original unmodified .ko... ifconfig output as requested at bottom Static IP-configuration does not make a difference with the ipfw behaviour. ipfw ruleset (based on /etc/rc.firewall simple ruleset) 00010 allow ip from any to me dst-port 22 recv ue0 00010 allow tcp from me 22 to any xmit ue0 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 deny ip from any to ::1 00500 deny ip from ::1 to any 00600 allow ipv6-icmp from :: to ff02::/16 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 allow ipv6-icmp from any to any ip6 icmp6types 1 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 01100 deny ip from 10.16.2.1 to any in via ue0 01200 deny ip from 172.17.2.111 to any in via re0 01300 deny ip from any to 10.0.0.0/8 via ue0 01500 deny ip from any to 192.168.0.0/16 via ue0 01600 deny ip from any to 0.0.0.0/8 via ue0 01700 deny ip from any to 169.254.0.0/16 via ue0 01800 deny ip from any to 192.0.2.0/24 via ue0 01900 deny ip from any to 224.0.0.0/4 via ue0 02000 deny ip from any to 240.0.0.0/4 via ue0 02100 divert 8668 ip4 from any to any via ue0 02200 deny ip from 10.0.0.0/8 to any via ue0 02400 deny ip from 192.168.0.0/16 to any via ue0 02500 deny ip from 0.0.0.0/8 to any via ue0 02600 deny ip from 169.254.0.0/16 to any via ue0 02700 deny ip from 192.0.2.0/24 to any via ue0 02800 deny ip from 224.0.0.0/4 to any via ue0 02900 deny ip from 240.0.0.0/4 to any via ue0 03000 allow tcp from any to any established 03100 allow ip from any to any frag 03200 allow tcp from any to me dst-port 22 setup 03300 allow tcp from any to me dst-port 25 setup 03400 allow tcp from any to me dst-port 465 setup 03500 allow tcp from any to me dst-port 587 setup 03600 allow tcp from any to me dst-port 80 setup 03700 allow tcp from any to me dst-port 443 setup 03800 deny log logamount 5 ip4 from any to any in via ue0 setup proto tcp 03900 allow tcp from any to any setup 04000 allow udp from me to any dst-port 53 keep-state 04100 allow udp from me to any dst-port 123 keep-state 04200 allow ip from any to any dst-port 22 recv ue0 65535 deny ip from any to any If I remove rule 10 it will NOT work with ue0, the ruleset without rule 10 DOES work with re0. Found an older PR about em or fxp having trouble with natd when rxcsum/txcsum was enabled, that is why I started fiddling with rxcsum/txcsum and found that the NIC would be unusable without rxcsum/txcsum enabled. If only I could find that PR now (kern/170081???)... Was fixed in base... If you don't use ipfw/natd, checksum offloading of axe(4) work? If yes, you'd get better answer from ipfw mailing list. Some other post reported fake AX88772A chips (32-pin packaging vs 64 in the original) on cheap USB NICs so I checked the hardware as well and could not AX88772A does not support TX/RX checksum offloading. see an issue (64-pin packaging). # ifconfig ue0 ue0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8000bRXCSUM,TXCSUM,VLAN_MTU,LINKSTATE ether 00:60:6e:42:5b:53 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active # dhclient ue0 DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 4 DHCPOFFER from 172.17.2.1 DHCPREQUEST on ue0 to 255.255.255.255 port 67 DHCPACK from 172.17.2.1 bound to 172.17.2.111 -- renewal in 43200 seconds. # ifconfig ue0 ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8000bRXCSUM,TXCSUM,VLAN_MTU,LINKSTATE ether 00:60:6e:42:5b:53 inet6 fe80::260:6eff:fe42:5b53%ue0 prefixlen 64 scopeid 0x7 inet 172.17.2.111 netmask 0xff00 broadcast 172.17.2.255 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active I can see TX/RX checksum offloading is active and it successfully got a IP address via DHCP. On Wed, Apr 10, 2013 at 4:14 AM, YongHyeon PYUN pyu...@gmail.com wrote: On Mon, Apr 08, 2013 at 08:45:58PM +0200, Spil Oss wrote: Hi YongHyeon, output from verbose boot ugen3.2: vendor 0x0b95 at usbus3 axe0: vendor 0x0b95 product 0x772b, rev 2.00/0.01, addr 2 on usbus3 axe0: PHYADDR 0xe0:0x10 miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 16 on miibus1 ukphy0: OUI 0x007063, model 0x0008, rev. 1 ukphy0: none, 10baseT
Re: Problems with axe(4) and checksum offloading
Hi YongHyeon, With the original unmodified .ko... ifconfig output as requested at bottom Static IP-configuration does not make a difference with the ipfw behaviour. ipfw ruleset (based on /etc/rc.firewall simple ruleset) 00010 allow ip from any to me dst-port 22 recv ue0 00010 allow tcp from me 22 to any xmit ue0 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 deny ip from any to ::1 00500 deny ip from ::1 to any 00600 allow ipv6-icmp from :: to ff02::/16 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 allow ipv6-icmp from any to any ip6 icmp6types 1 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 01100 deny ip from 10.16.2.1 to any in via ue0 01200 deny ip from 172.17.2.111 to any in via re0 01300 deny ip from any to 10.0.0.0/8 via ue0 01500 deny ip from any to 192.168.0.0/16 via ue0 01600 deny ip from any to 0.0.0.0/8 via ue0 01700 deny ip from any to 169.254.0.0/16 via ue0 01800 deny ip from any to 192.0.2.0/24 via ue0 01900 deny ip from any to 224.0.0.0/4 via ue0 02000 deny ip from any to 240.0.0.0/4 via ue0 02100 divert 8668 ip4 from any to any via ue0 02200 deny ip from 10.0.0.0/8 to any via ue0 02400 deny ip from 192.168.0.0/16 to any via ue0 02500 deny ip from 0.0.0.0/8 to any via ue0 02600 deny ip from 169.254.0.0/16 to any via ue0 02700 deny ip from 192.0.2.0/24 to any via ue0 02800 deny ip from 224.0.0.0/4 to any via ue0 02900 deny ip from 240.0.0.0/4 to any via ue0 03000 allow tcp from any to any established 03100 allow ip from any to any frag 03200 allow tcp from any to me dst-port 22 setup 03300 allow tcp from any to me dst-port 25 setup 03400 allow tcp from any to me dst-port 465 setup 03500 allow tcp from any to me dst-port 587 setup 03600 allow tcp from any to me dst-port 80 setup 03700 allow tcp from any to me dst-port 443 setup 03800 deny log logamount 5 ip4 from any to any in via ue0 setup proto tcp 03900 allow tcp from any to any setup 04000 allow udp from me to any dst-port 53 keep-state 04100 allow udp from me to any dst-port 123 keep-state 04200 allow ip from any to any dst-port 22 recv ue0 65535 deny ip from any to any If I remove rule 10 it will NOT work with ue0, the ruleset without rule 10 DOES work with re0. Found an older PR about em or fxp having trouble with natd when rxcsum/txcsum was enabled, that is why I started fiddling with rxcsum/txcsum and found that the NIC would be unusable without rxcsum/txcsum enabled. If only I could find that PR now (kern/170081???)... Was fixed in base... Some other post reported fake AX88772A chips (32-pin packaging vs 64 in the original) on cheap USB NICs so I checked the hardware as well and could not see an issue (64-pin packaging). # ifconfig ue0 ue0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8000bRXCSUM,TXCSUM,VLAN_MTU,LINKSTATE ether 00:60:6e:42:5b:53 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active # dhclient ue0 DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 4 DHCPOFFER from 172.17.2.1 DHCPREQUEST on ue0 to 255.255.255.255 port 67 DHCPACK from 172.17.2.1 bound to 172.17.2.111 -- renewal in 43200 seconds. # ifconfig ue0 ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8000bRXCSUM,TXCSUM,VLAN_MTU,LINKSTATE ether 00:60:6e:42:5b:53 inet6 fe80::260:6eff:fe42:5b53%ue0 prefixlen 64 scopeid 0x7 inet 172.17.2.111 netmask 0xff00 broadcast 172.17.2.255 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active On Wed, Apr 10, 2013 at 4:14 AM, YongHyeon PYUN pyu...@gmail.com wrote: On Mon, Apr 08, 2013 at 08:45:58PM +0200, Spil Oss wrote: Hi YongHyeon, output from verbose boot ugen3.2: vendor 0x0b95 at usbus3 axe0: vendor 0x0b95 product 0x772b, rev 2.00/0.01, addr 2 on usbus3 axe0: PHYADDR 0xe0:0x10 miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 16 on miibus1 ukphy0: OUI 0x007063, model 0x0008, rev. 1 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow ue0: USB Ethernet on axe0 ue0: bpf attached ue0: Ethernet address: 00:60:6e:42:5b:53 ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP AX88772B engineering sample I have still worked on latest current. Could you use a static IP rather than using DHCP and see whether that makes any difference?(Note, you have to revert your changes made to axe(4) before trying that). Also show me the output of 'ifconfig ue0' before/after running dhclient(8). Apart from what I originally described... Networking does work, but not when packets pass through ipfw and nat. If I add my ipfw rules before the divert natd rule networking works as expected
Re: Problems with axe(4) and checksum offloading
Hi YongHyeon, output from verbose boot ugen3.2: vendor 0x0b95 at usbus3 axe0: vendor 0x0b95 product 0x772b, rev 2.00/0.01, addr 2 on usbus3 axe0: PHYADDR 0xe0:0x10 miibus1: MII bus on axe0 ukphy0: Generic IEEE 802.3u media interface PHY 16 on miibus1 ukphy0: OUI 0x007063, model 0x0008, rev. 1 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow ue0: USB Ethernet on axe0 ue0: bpf attached ue0: Ethernet address: 00:60:6e:42:5b:53 ue0: link state changed to UP ue0: link state changed to DOWN ue0: link state changed to UP Apart from what I originally described... Networking does work, but not when packets pass through ipfw and nat. If I add my ipfw rules before the divert natd rule networking works as expected, without the SYN,ACK response packets are not accepted if I e.g. connect to something on the axe interface. I have validated the ipfw ruleset with the onboard realtek NIC and it then works as expected. # usbconfig -u 3 -a 2 dump_info ugen3.2: product 0x772b vendor 0x0b95 at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (200mA) Kind regards, Spil. On Mon, Apr 8, 2013 at 8:35 AM, YongHyeon PYUN pyu...@gmail.com wrote: On Sun, Apr 07, 2013 at 09:14:16PM +0200, Spil Oss wrote: Hi all, With checksum offloading enabled I cannot use my axe NIC (ASIX AX88772B). ifconfig ue0 -txcsum -rxcsum will make dhclient ue0 return if I re-enable txcsum and rxcsum I get an immediate response from the dhcp server. Tried to remove the csum features by commenting out ifp-if_capabilities |= IFCAP_TXCSUM | IFCAP_RXCSUM; ifp-if_hwassist = AXE_CSUM_FEATURES; (lines 855 and 856 in /usr/src/sys/dev/usb/net/if_axe.c) and rebuild the module. This does remove RXCSUM and TXCSUM from options and behaves the same as disabling the features with ifconfig (i.e. does not work) 10.0-CURRENT r248351 Hope someone can help me... Spil. Last time I tried, checksum offloading worked as expected. Would you show me the verbose dmesg output after attaching the axe(4) NIC? ___ 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
Problems with axe(4) and checksum offloading
Hi all, With checksum offloading enabled I cannot use my axe NIC (ASIX AX88772B). ifconfig ue0 -txcsum -rxcsum will make dhclient ue0 return if I re-enable txcsum and rxcsum I get an immediate response from the dhcp server. Tried to remove the csum features by commenting out ifp-if_capabilities |= IFCAP_TXCSUM | IFCAP_RXCSUM; ifp-if_hwassist = AXE_CSUM_FEATURES; (lines 855 and 856 in /usr/src/sys/dev/usb/net/if_axe.c) and rebuild the module. This does remove RXCSUM and TXCSUM from options and behaves the same as disabling the features with ifconfig (i.e. does not work) 10.0-CURRENT r248351 Hope someone can help me... Spil. ___ 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
