Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    ASIX AX88179 USB to GigE

    Scheduled Pinned Locked Moved Hardware
    52 Posts 9 Posters 29.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H
      Huxy
      last edited by

      I did some testing with pfSense and m0n0wall using the USB adapter as my WAN connection.
      Throughput on incoming traffic was really poor 0.5mbit/s but upload was fine at 10.5mbit/s.
      The net connection also stopped responding on two separate occasions and I was forced to reboot the pfSense VM.

      I installed a Debian based router instead as a test and I had full speed 125mbit/s and 10.5mbit/s speeds on my LAN clients. I'm not sure what the issue is to be honest, but it renders pfSense unsuitable for me at this point in time.

      http://blog.codeape.co.uk

      1 Reply Last reply Reply Quote 0
      • B
        bryan.paradis
        last edited by

        @Huxy:

        I did some testing with pfSense and m0n0wall using the USB adapter as my WAN connection.
        Throughput on incoming traffic was really poor 0.5mbit/s but upload was fine at 10.5mbit/s.
        The net connection also stopped responding on two separate occasions and I was forced to reboot the pfSense VM.

        I installed a Debian based router instead as a test and I had full speed 125mbit/s and 10.5mbit/s speeds on my LAN clients. I'm not sure what the issue is to be honest, but it renders pfSense unsuitable for me at this point in time.

        FreeBSD integration ranges from very poor to not as poor depending on your hypervisor choice.

        1. What are you using as a hypervisor?
        2. Does the hypervisor host OS support the usb nic?
        3. Are you passing through the usb device?

        1 Reply Last reply Reply Quote 0
        • H
          Huxy
          last edited by

          1. What are you using as a hypervisor?

          I've been using a Xen 4.3 Wheezy based Hypervisor. I backported Xen and added PVUSB support to a recent kernel version. The VM is a QEMU traditional based HVM.

          2. Does the hypervisor host OS support the usb nic?

          Yes the host OS has drivers for it. In a debian VM it also works fine with PCI Passthrough.

          3. Are you passing through the usb device?

          I'm passing through the USB controller directly to the VM. The pfSense VM is then in control of both the USB driver and the NIC driver. I think I downloaded a PVHVM build of pfSense somewhere. That might have better luck..

          http://blog.codeape.co.uk

          1 Reply Last reply Reply Quote 0
          • B
            bryan.paradis
            last edited by

            @Huxy:

            I've been using a Xen 4.3 Wheezy based Hypervisor. I backported Xen and added PVUSB support to a recent kernel version. The VM is a QEMU traditional based HVM.

            You are using Xen on wheezy with Qemu-dm is what I gather?

            Yes the host OS has drivers for it. In a debian VM it also works fine with PCI Passthrough.

            This is probably because the debian has proper passthrough support.

            I'm passing through the USB controller directly to the VM. The pfSense VM is then in control of both the USB driver and the NIC driver. I think I downloaded a PVHVM build of pfSense somewhere. That might have better luck..

            Why not just create a virtual wan network using that as the physical adapter on the host and then using a virtual nic in the guest pfsense?

            1 Reply Last reply Reply Quote 0
            • H
              Huxy
              last edited by

              You are using Xen on wheezy with Qemu-dm is what I gather?

              Yes, not the upstream version

              Why not just create a virtual wan network using that as the physical adapter on the host and then using a virtual nic in the guest pfsense?

              I'm guessing this would work, but I was keen to keep the WAN external to the main hypervisor. I'm not an expert but I would think by passing through the device it would be more secure and reduce the amount of overhead required to communicate between the hypervisor and the guest. Given that Xen support and FreeBSD seems immature compared to it's linux brethren so it might be easier to go that route.

              With regards to the loss of connectivity, I think this might solve the issue with USB network interfaces.
              https://forum.pfsense.org/index.php/topic,72019.msg393187.html#msg393187

              http://blog.codeape.co.uk

              1 Reply Last reply Reply Quote 0
              • B
                bryan.paradis
                last edited by

                @Huxy:

                You are using Xen on wheezy with Qemu-dm is what I gather?

                Yes, not the upstream version

                Why not just create a virtual wan network using that as the physical adapter on the host and then using a virtual nic in the guest pfsense?

                I'm guessing this would work, but I was keen to keep the WAN external to the main hypervisor. I'm not an expert but I would think by passing through the device it would be more secure and reduce the amount of overhead required to communicate between the hypervisor and the guest. Given that Xen support and FreeBSD seems immature compared to it's linux brethren so it might be easier to go that route.

                With regards to the loss of connectivity, I think this might solve the issue with USB network interfaces.
                https://forum.pfsense.org/index.php/topic,72019.msg393187.html#msg393187

                I would keep it simple in regards to your WAN. Linux is far ahead in hardware support and integration with hypervisors that is for sure.

                1 Reply Last reply Reply Quote 0
                • U
                  upgrayedd
                  last edited by

                  Hello, I know this thread is a year old but I'm having similar issues. First I'm a Windows guy with 1 yr as a junior Linux admin and very little BSD exp, so take it easy on me  ;D

                  So the system I am working with a Dell D620 laptop with a USB Gigabit AX99179 adapter  http://www.amazon.com/gp/product/B00E44F3BO/ref=oh_aui_detailpage_o00_s02?ie=UTF8&psc=1

                  I'm running into the same problems. I downloaded the 64 bit driver posted earlier and tried to install.

                  
[2.2-RELEASE][root@pfSense.localdomain]/boot/modules: kldload if_axge.ko
kldload: an error occurred while loading the module. Please check dmesg(8) for more details.

                  listing system.log I get

                  
Feb  1 20:08:55 pfSense kernel: interface axge.1 already present in the KLD 'kernel'!
Feb  1 20:08:55 pfSense kernel: linker_load_file: Unsupported file type

                  So based on this I'm assuming the driver is already present. So I went to the FreeBSD site and look at this https://www.freebsd.org/cgi/man.cgi?query=axge&sektion=4 and added

                  if_axge_load="YES"

                  to the loader.conf.wrapper. Still nothing. At this point I really could use some help. Here is my ifconfig and dmesg:

                  
[2.2-RELEASE][root@pfSense.localdomain]/boot/modules: ifconfig
bwi0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 2290
        ether DELETED
        nd6 options=21 <performnud,auto_linklocal>media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
        status: associated
bge0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
        options=8009b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,linkstate>ether DELETED
        inet6 DELETED
        inet DELETED netmask 0xfffffe00 broadcast DELETED
        nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
pflog0: flags=100 <promisc>metric 0 mtu 33144
pfsync0: flags=0<> metric 0 mtu 1500
        syncpeer: 224.0.0.240 maxupd: 128 defer: on
        syncok: 1
lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
        options=600003 <rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6>inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
        nd6 options=21 <performnud,auto_linklocal>enc0: flags=0<> metric 0 mtu 1536
        nd6 options=21 <performnud,auto_linklocal>bwi0_wlan0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
        ether DELETED
        inet6 DELETED bwi0_wlan0 prefixlen 64 scopeid 0x7
        inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
        nd6 options=23 <performnud,accept_rtadv,auto_linklocal>media: IEEE 802.11 Wireless Ethernet DS/1Mbps mode 11g
        status: associated
        ssid default channel 6 (2437 MHz 11g) bssid 08:10:74:18:1c:c2
        country US authmode OPEN privacy OFF txpower 0 bmiss 7 scanvalid 60
        bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5
        protmode CTS</performnud,accept_rtadv,auto_linklocal></up,broadcast,running,simplex,multicast></performnud,auto_linklocal></performnud,auto_linklocal></rxcsum,txcsum,rxcsum_ipv6,txcsum_ipv6></up,loopback,running,multicast></promisc></full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,linkstate></up,broadcast,running,simplex,multicast></performnud,auto_linklocal></up,broadcast,running,simplex,multicast> 

                  
Root mount waiting for: usbus4
ugen4.4: <o2>at usbus4
Root mount waiting for: usbus4
ugen4.5: <realtek>at usbus4
umass0: <ethernet data="">on usbus4
umass0: Get Max Lun not supported (USB_ERR_STALLED)</ethernet></realtek></o2> 

                  
ugen2.1: <uhci root="" hub="" intel="">at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen1.1: <uhci root="" hub="" intel="">at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen0.1: <uhci root="" hub="" intel="">at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen4.1: <ehci root="" hub="" intel="">at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen3.1: <uhci root="" hub="" intel="">at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (0mA)
ugen4.2: <product 0xa005="" vendor="" 0x413c="">at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA)
ugen4.3: <product 0x7761="" vendor="" 0x0b97="">at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (200mA)
ugen4.4: <o2micro ccid="" sc="" reader="" o2="">at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA)
ugen4.5: <usb 101001000="" lan="" realtek="">at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA)</usb></o2micro></product></product></uhci></ehci></uhci></uhci></uhci> 

                  
[2.2-RELEASE][root@pfSense.localdomain]/boot/modules: usbconfig -d ugen4.5 dump_device_desc
ugen4.5: <usb 101001000="" lan="" realtek="">at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0210
  bDeviceClass = 0x0000
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0040
  idVendor = 0x0bda
  idProduct = 0x8153
  bcdDevice = 0x3000
  iManufacturer = 0x0001  <realtek>iProduct = 0x0002  <usb 10="" 100="" 1000="" lan="">iSerialNumber = 0x0003  <0023566C5827>
  bNumConfigurations = 0x0002</usb></realtek></usb>
                  1 Reply Last reply Reply Quote 0
                  • B
                    bryan.paradis
                    last edited by

                    All clues point to it being a realtek chip inside that usb ethernet adapter and not an asix88179. I personally have this one from amazon. There are many otheres. Amazon must have shipped you the wrong part or the specs are bad. I would stick with products with many reviews as there are know counterfit asix chips.

                    http://www.amazon.com/Cable-Matters-SuperSpeed-Gigabit-Ethernet/dp/B00BBD7NFU/ref=sr_1_60?ie=UTF8&qid=1422838559&sr=8-60&keywords=88179

                    1 Reply Last reply Reply Quote 0
                    • U
                      upgrayedd
                      last edited by

                      @bryan.paradis:

                      All clues point to it being a realtek chip inside that usb ethernet adapter and not an asix88179. I personally have this one from amazon. There are many otheres. Amazon must have shipped you the wrong part or the specs are bad. I would stick with products with many reviews as there are know counterfit asix chips.

                      http://www.amazon.com/Cable-Matters-SuperSpeed-Gigabit-Ethernet/dp/B00BBD7NFU/ref=sr_1_60?ie=UTF8&qid=1422838559&sr=8-60&keywords=88179

                      Thanks for the quick reply Bryan!  I'll check out the link and make sure to leave a comment on the list I bought from.

                      1 Reply Last reply Reply Quote 0
                      • D
                        DB9
                        last edited by

                        Hi,

                        I'm running into a rather strange problem using these interfaces on pfSense 2.2.6.

                        I have two Digitus DN-3023 USB 3.0 NICs in my system which use the AX88179 chip:

                        ugen0.7: <ax88179 asix="" elec.="" corp.="">at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (124mA)
                        ugen0.8: <ax88179 asix="" elec.="" corp.="">at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (124mA)

                        I've successfully configured pfSense as follows:

                        Internet
                            |
                        Provider's router
                            |
                        10.1.1.0/24
                            |
                          WAN
                        pfSense
                        LAN1, LAN2 (vlans 3, 4)
                            |
                        10.1.3.0/24
                        10.1.4.0/24
                            |
                          Switch
                          |    |    |
                        Clients (distributed over the two vlans)

                        Everything was working as expected until I tried to update a Ubuntu PC (hash sum errors on downloaded packages). I noticed that also the md5sum of a downloaded Ubuntu ISO image was incorrect. (http://releases.ubuntu.com/wily/ubuntu-15.10-desktop-amd64.iso).

                        When I connect directly to my provider's router I can update and can download a non-corrupted ISO image without any problem. So it has to be something in pfSense.

                        Comparing the corrupted ISO on a binary level against a non-corrupted one along with some packet dumps, it seems like the corruption occurs at the beginning / end of packets in the download stream.

                        At first I wanted to blame the 802.1Q setup, maybe these NICs aren't supported that well. I tried playing with the MTU on the LAN interfaces, reducing it to 1496 to compensate for the inserted vlan tags. This seemed to fix the issue. I was able to update and download the iso, but some websites would not load at all. I think this is due to the destination unreachable due to fragmentation ICMP traffic the WAN interface was sending out. So back to the standard MTU of 1500.

                        Now I've disabled all vlan setup and the LAN interface (only one remaining) is running directly on the interface. But I'm still experiencing the corrupted downloads.

                        • I still have a feeling this issue is related to these NICs, hence I'm posting in this topic
                        • I think it's strange that such a low level issue, has so little impact. Only some HTTP streams are affected, everything else seems to work like a charm.
                        • There's a third realtek interface in the system (on the mainbord), but this is not yet supported by the FreeBSD driver, so no other Interfaces to troubleshoot

                        Does anyone have the slightest idea what might be going on here?</ax88179></ax88179>

                        1 Reply Last reply Reply Quote 0
                        • M
                          MasterX-BKC- Banned
                          last edited by

                          @DB9:

                          Hi,

                          I'm running into a rather strange problem using these interfaces on pfSense 2.2.6.

                          I have two Digitus DN-3023 USB 3.0 NICs in my system which use the AX88179 chip:

                          ugen0.7: <ax88179 asix="" elec.="" corp.="">at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (124mA)
                          ugen0.8: <ax88179 asix="" elec.="" corp.="">at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (124mA)

                          I've successfully configured pfSense as follows:

                          Internet
                              |
                          Provider's router
                              |
                          10.1.1.0/24
                              |
                            WAN
                          pfSense
                          LAN1, LAN2 (vlans 3, 4)
                              |
                          10.1.3.0/24
                          10.1.4.0/24
                              |
                            Switch
                            |    |    |
                          Clients (distributed over the two vlans)

                          Everything was working as expected until I tried to update a Ubuntu PC (hash sum errors on downloaded packages). I noticed that also the md5sum of a downloaded Ubuntu ISO image was incorrect. (http://releases.ubuntu.com/wily/ubuntu-15.10-desktop-amd64.iso).

                          When I connect directly to my provider's router I can update and can download a non-corrupted ISO image without any problem. So it has to be something in pfSense.

                          Comparing the corrupted ISO on a binary level against a non-corrupted one along with some packet dumps, it seems like the corruption occurs at the beginning / end of packets in the download stream.

                          At first I wanted to blame the 802.1Q setup, maybe these NICs aren't supported that well. I tried playing with the MTU on the LAN interfaces, reducing it to 1496 to compensate for the inserted vlan tags. This seemed to fix the issue. I was able to update and download the iso, but some websites would not load at all. I think this is due to the destination unreachable due to fragmentation ICMP traffic the WAN interface was sending out. So back to the standard MTU of 1500.

                          Now I've disabled all vlan setup and the LAN interface (only one remaining) is running directly on the interface. But I'm still experiencing the corrupted downloads.

                          • I still have a feeling this issue is related to these NICs, hence I'm posting in this topic
                          • I think it's strange that such a low level issue, has so little impact. Only some HTTP streams are affected, everything else seems to work like a charm.
                          • There's a third realtek interface in the system (on the mainbord), but this is not yet supported by the FreeBSD driver, so no other Interfaces to troubleshoot

                          Does anyone have the slightest idea what might be going on here?</ax88179></ax88179>

                          I know this is old but i wanted to supply a likely very plausible answer to this in case anyone else runs into this issue.

                          If the provider is a DSL provider, and the providers modem is in bridge mode to connect to the pfsense, you MUST in almost all cases change the WAN port on the pfsense to an MTU of 1492, not 1496.  DSL uses a tagging on the packets simular to your vlan tags, and any packets exceeding 1492 cannot get through properly.

                          This is confirmed on XO Communications DSL, CenturyLink DSL, Qwest DSL(bought by CenturyLink), and Integra DSL as well.  This could, and most likely was the cause of the issues quoted above, and most likely had nothing to do with the ASIX nics, or the fact they were USB.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.