From owner-freebsd-current@FreeBSD.ORG Wed Apr 10 17:48:01 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 950AEBBA for ; Wed, 10 Apr 2013 17:48:01 +0000 (UTC) (envelope-from spil.oss@gmail.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0BCDBD for ; Wed, 10 Apr 2013 17:48:01 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id a11so900499iee.39 for ; Wed, 10 Apr 2013 10:48:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qS3v1TtPsr1p58oIZ1xbAcTYH9BBxcQeg8D/vQJ5yj0=; b=zUUASHef5ozjKGSkIPeysnrqCYVPETTTEhaCblqPEu/9I/zb6EophT1f34xnqLiNyY WgL8Ni7KRl9QqK/DFEv9M1Te6RWE8HfqfzDM1kQ5OItBP/RudtOD+oLRVCxGDihw6ksw 6xSocOiAAFGdJmDDMS1v2lBWtkqF6KcirL2PjjTlOvkAHmrKbaY3lJkWu27VxQ7bCRyP TZk5Ghh5qsm5ev7r8TtN2kbA50xNWxsyVQi4GLpRFoS/pnaikEycpaVfgylYJzZf9vg7 ucaVPVGpQ+4Ui0z4oWfJpqW76kuOFhkJw1fCKeUEsq/ww9kSvhtCanEBw++9L/67fn+e OVxw== MIME-Version: 1.0 X-Received: by 10.42.70.74 with SMTP id e10mr1811361icj.38.1365616080750; Wed, 10 Apr 2013 10:48:00 -0700 (PDT) Received: by 10.42.189.4 with HTTP; Wed, 10 Apr 2013 10:48:00 -0700 (PDT) In-Reply-To: <20130410021455.GB3086@michelle.cdnetworks.com> References: <20130408063548.GB1526@michelle.cdnetworks.com> <20130410021455.GB3086@michelle.cdnetworks.com> Date: Wed, 10 Apr 2013 19:48:00 +0200 Message-ID: Subject: Re: Problems with axe(4) and checksum offloading From: Spil Oss To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 17:48:01 -0000 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=8802 metric 0 mtu 1500 options=8000b ether 00:60:6e:42:5b:53 nd6 options=21 media: Ethernet autoselect (100baseTX ) 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=8843 metric 0 mtu 1500 options=8000b ether 00:60:6e:42:5b:53 inet6 fe80::260:6eff:fe42:5b53%ue0 prefixlen 64 scopeid 0x7 inet 172.17.2.111 netmask 0xffffff00 broadcast 172.17.2.255 nd6 options=21 media: Ethernet autoselect (100baseTX ) status: active On Wed, Apr 10, 2013 at 4:14 AM, YongHyeon PYUN wrote: > On Mon, Apr 08, 2013 at 08:45:58PM +0200, Spil Oss wrote: > > Hi YongHyeon, > > > > output from verbose boot > > > > ugen3.2: at usbus3 > > axe0: on usbus3 > > axe0: PHYADDR 0xe0:0x10 > > miibus1: on axe0 > > ukphy0: PHY 16 on miibus1 > > ukphy0: OUI 0x007063, model 0x0008, rev. 1 > > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, > > auto-flow > > ue0: 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, > > 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: 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 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? > > > >