The axe driver and usb Ethernet controllers
broncoBrad last edited by
Here's what I'm trying to do.
I have an old Sony Vaio laptop. It only has one NIC. I wanted to use that as my WAN interface and then add a USB to Wireless NIC (run driver) to create a wireless access point for my computers to access.
I would also like to have a LAN interface to be able to access the web configurator in case for some reason there is an issue with the wireless. I am trying to make this LAN interface from a USB to Ethernet NIC, specifically the Linksys USB200M.
The Wireless USB NIC works perfectly. But I'm having serious issues with the USB200M. When I have a DHCP server enabled on that interface, my PC can receive a DHCP address, but I cannot ping the gateway (or shall I say very poorly ping; 85% drop and the ones that are returned are around 3000ms).
I have also tried a different NIC. The StarTech USB21000S2 which is also based on the axe driver. In both cases the interface is identified by "ue0". When I mentioned this issue to one of my co-workers he said it sounds like a driver issue.
I have multiple StarTech USB21000S2 NICs working on another pfSense install, those were originally set up in pfSense 2.0.1. And the only thing I had to do in 2.1 to get them working is to set hw.usb.ehci.no_hs = 1 in /boot/loader.conf.local. But I've tried that on this new install and it still isn't working.
Has anyone else got the axe/ue driver to successfully work?
I am using a DELOCK Adapter USB 2.0 > Gigabit LAN nic for exactly 30 mins now. Works like a charm: I receive a download rate of 28M/bits. Driver is AX88178.
So this works for me as far as internet is concerned.
BUT: I would like to use traffic shaping. Manpage altq (FreeBSD 8.3) tells me that axe drivers are supported.
I checked my nic:
# usbconfig -d ugen2.2 dump_device_desc ugen2.2: <product 0x1780="" vendor="" 0x0b95="">at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x00ff bDeviceSubClass = 0x00ff bDeviceProtocol = 0x0000 bMaxPacketSize0 = 0x0040 idVendor = 0x0b95 idProduct = 0x1780 bcdDevice = 0x0001 iManufacturer = 0x0001 <asix elec.="" corp.="">iProduct = 0x0002 <ax88178>iSerialNumber = 0x0003 <602A9C> bNumConfigurations = 0x0001</ax88178></asix></product>
But the device doesn't show up at the traffic shaper gui.
So: does axe drivers support altq or not?
Reset all interfaces today. No changes: axe0 isn't regognized by traffic shaper.
Took another look into the message log:
ugen2.2: <vendor 0x0b95="">at usbus2 axe0: <vendor 2="" 0x0b95="" product="" 0x1780,="" rev="" 2.00="" 0.01,="" addr="">on usbus2 ... ue0: <usb ethernet="">on axe0</usb></vendor></vendor>
So does pfsense see a device with "axe0" or a device with "ue0"? As for "ue0" I learnt that it is not supporting altq.
Any help or do I have to buy another usb nic - and if so: which one?
robvanhooren last edited by
having these issues on a fresh build of 2.1 with the Apple-USB adapters (axe)
perhaps looks like this upstream fBSD bug might be back in pfS 2.1
Well, finished the issue by installing a new ethernet nic re0.
Usb nics suck! Really!
Paul47 last edited by
I have a Belkin F4U047 as my LAN interface (on an Intel D510MO motherboard). It uses axe0 according to dmesg and shows up as ue0 in pfsense. I can ping from pfsense 2.1 to my laptop on the lan just fine, but if I ping the other way the ping just hangs. Maybe need to fix my firewall rules or something. I don't care, because it works perfectly. Don't give up on USB ethernet adapters yet! :)
It's not gigabit or USB 3.0 but I don't need that to feed a single laptop.
Woops, I just looked at that ping command again and found I used the wrong address. :-[ With the right address it pings both ways without a hitch. I also do not notice the connection dropping out as some have complained with using other devices.
@Paul47: I wasn't complaining about usb nics in general. I had one working for me flawlessly for months. It's just that traffic shaping requires the appropriate driver which axe0 and ue0 definitly are not.
That's why I changed to a standard PCI nic.