USB gigabit network adapter - or alternatives
-
Yeah, it's strange with the
ifconfig
command. Connecting a network cable doesn't change anything. Has it something to do with the driver not being loaded?I think I'll give it a try with one of the ASIX adapters. But I'm a little bit confused: The manual says "Set 1000Mbps (Gigabit Ethernet) operation (AX88178 only)". But as I see it, the chipset should be AX88179?
Regards,
Jon -
@jontheil said in USB gigabit network adapter - or alternatives:
Yeah, it's strange with the
ifconfig
command. Connecting a network cable doesn't change anything. Has it something to do with the driver not being loaded?I think I'll give it a try with one of the ASIX adapters. But I'm a little bit confused: The manual says "Set 1000Mbps (Gigabit Ethernet) operation (AX88178 only)". But as I see it, the chipset should be AX88179?
Regards,
JonHi @jontheil - I think this might be an accidental mistake / oversight in the manual entry for axge. If you look at the entry for axe, only the ASIX AX88178 has 1000Mbit support among those chipsets listed:
https://www.freebsd.org/cgi/man.cgi?query=axe&apropos=0&sektion=4&manpath=FreeBSD+11.2-RELEASE+and+Ports&arch=default&format=html
It also appears that the 1000Mbit section was a direct copy from the axe manual entry to the axge entry (without removing the reference to the axe supported AX88178 in the process).
I think it's fair to assume that both the AX88178A and AX88179 ASIX chipsets will have native support for 1000Mbit using the axge driver.
Hope this helps.
-
Hi again,
Now I have switched to another USB NIC, namely a Startech USB31000S, which should have a AX88179 ASIX chipset.
It works–sort of...
usbconfig -d 0.3 ugen0.3: <ASIX Elec. Corp. AX88179> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (124mA)
ifconfig -vv ue0 ue0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE> ether 00:24:9b:4f:86:e8 hwaddr 00:24:9b:4f:86:e8 inet6 fe80::224:9bff:fe4f:86e8%ue0 prefixlen 64 scopeid 0x6 inet 213.150.58.234 netmask 0xfffffff8 broadcast 213.150.58.239 inet 213.150.58.236 netmask 0xfffffff8 broadcast 213.150.58.239 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex,master>) status: activeifconfig -vv ue0 ue0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8000b<RXCSUM,TXCSUM,VLAN_MTU,LINKSTATE> ether 00:24:9b:4f:86:e8 hwaddr 00:24:9b:4f:86:e8 inet6 fe80::224:9bff:fe4f:86e8%ue0 prefixlen 64 scopeid 0x6 inet xxx.xxx.xxx.xxx netmask 0xfffffff8 broadcast yyy.yyy.yyy.yyy inet zzz.zzz.zzz.zzz netmask 0xfffffff8 broadcast aaa.aaa.aaa.aaa nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex,master>) status: active
(IP addresses obfuscated, but correct)
I have to problems:
When I reboot the firewall from a shell or the web GUI, the USB interface is no longer online. If I shut the system completely down with the power switch, it starts up again correctly. I can't find any descriptions in the forum or elsewhere of anything to put in
/boot/loader.conf.local
or/conf/config.xml
.I know that I should expect challenges regarding the real bandwidth of this type of NIC. And to be honest, I don't really know what to expect from a system connected to a 1,000 Mb/s line upstream. With the actual configuration – WAN assigned to ue0 and LAN to em0.100 – I get a speed of about 100 Mb/s (download) and 300 Mb/s upload. Both measurements are slow which could be related to the hardware challenge. But I don't understand the prominent difference. Could it be related to the setup with VLANs?
As usual, all comments and suggestions are very welcome.
Regards,
Jon -
When you warm boot what does the NIC come up as? It is detected correctly and ue0 is present? Just not linked?
-
Hmm. Haven't seen this until now, but for some reason the system log is completely empty after the warm reboots. So I can only say that the box seems active (HD activity), but no activity for the NIC (LEDs are off but there and at the connection to the gateway). I can easily post the output after the cold restart, but I guess that wouldn't give any clues.
Regards,
Jon -
Indeed, I would check the boot log and the output from usbconfig after the warm boot for clues/errors.
-
It seems that
dmesg.log
is cleared after each reboot. I don't know if I can configure something to keep dmesg messages between reboots.
What I can do is to swap the new firewall with the old one. Then I can connect it to a keyboard and a monitor and examinedmesg.log
andusbconfig
.
If that's the only way, I'll try it outside "office hours" and report back here.Regards,
Jon -
Hi @jontheil - what does CPU usage look like on the NUC when you run the speed test on your gigabit connection? Is it fully maxed out or still some room left?
Hope this helps.
-
I can't figure out what happens after the hot restart. I can't see anything in the boot log (
dmesg.log
) about Asix or ue0. I can't find any information about theugen0.3: <vendor 0x8087 product 0x0aaa> at usbus0
entrance in the log though. I have attached the file. dmesg.boot.txt.
usbconfig
doesn't show anything about the NIC (I think):ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen0.2: <Logitech USB Keyboard> at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (90mA) ugen0.3: <vendor 0x8087 product 0x0aaa> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ugen0.4: <Kingston DataTraveler 3.0> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (224mA)
Regards,
Jon -
@tman222, I'll have a look, when it's swapped back again. As I recall it, there are enough of resources. I'll report back.
Thanks,
Jon -
@jontheil said in USB gigabit network adapter - or alternatives:
It seems that
dmesg.log
is cleared after each reboot. I don't know if I can configure something to keep dmesg messages between reboots.dmesg.boot is simply a capture of the output of the command
dmesg
after the current boot finished. this is done so you can see your current dmesg output before it potentially gets flooded with kernel messages about funky packets or other such things. each time the system reboots, this file is recreated from scratch, probably via.../sbin/dmesg > /var/log/dmesg.boot
at the very end of the boot sequence.
-
Check the bios for any sort of USB power saving features that might be shutting down the NIC at reboot.