Support for RTL8153 Adapter?
-
You can open a feature request: https://redmine.pfsense.org/
I don't see one for that specifically.
Steve
-
Ah, well, yes in Linux the support is likely far better.
I've never seen that sort or rate from USB Ethernet in FreeBSD myself.
Steve
-
@stephenw10 and done. Thank you!
https://redmine.pfsense.org/issues/11125
-
How many interfaces does your pfsense have on it now? If the problem is bandwidth for your vlans - while sure multigig interface would be 1 option, be it 2.5, 5 or even better 10
But you can split your vlans across multiple physical gig interfaces.. Part of the reason its a good idea to have router with lots of interfaces ;) That is why I love my 4860, its got 6 interfaces.. So I have my vlans spread across 5 of those.. The only interface that has multiple vlans on it is the one that does the wireless vlans - since they are always low bandwidth anyway - and they don't talk to each other - so no intervlan traffic on the same physical.
-
for this reason it does not show the link speed
the ure(4) driver is not currently included in pfSense so your adapter is instead using the cdce(4) driver.
You should add comments to the feature request of you want that driver to be included in a future version.
-
I've upgraded to 2.5.2 and the new kernel driver is unstable with my RTL8153 adaptor, it works for 1 or 2 days and the stops working. It was working perfectly as a module to load with set_config/usbconfig, without needing any reboot for months (uptime > 90 days...). Bad idea guys...
-
usbconfig does not load kernel modules. What module were you using? In 2.5.1? What happens if you load that module in 2.5.2? More details needed to even define the issue you're seeing.
But at a basic level don't use USB Ethernet if you're looking for speed or stability.
Steve
-
Your're absolutly right Steve, sorry about it: this is the "cdce" driver that was running! Personnaly, I don't mind the speed as I have a DSL link, however it was very stable (I have tried kernel modules urtwn, urndis and ipheth from FreeBSD deposit before, but stopped due to the complexity to upgrade).
My /conf/config.xml in 2.5.1 and previous releases was:
<earlyshellcmd>usbconfig -d `usbconfig list | grep "Thinkpad" | cut -c5-7` set_config 1</earlyshellcmd>
Jean-Francois.
-
@stephenw10
I forgot to answer the other questions:- in 2.5.2, the same config as the one reported doesn't work: the interface is active but no DHCP received (and no communication if I set a fixed IP address)
- in 2.5.2, if I change the config to "set_config 0", then it also works for 1 or 2 days (same as removing the whole line in config.xml)
I know USB Ethernet is not the best solution, but my mini PC only hosts 1 NIC in my homelab.
Jean-Francois.
-
So it was using the generic cdce(4) driver in 2.5.1 but is now using ure(4) in 2.5.2?
How does it fail? Anything logged?
Steve
-
I can't see anything in system logs, but maybe I'm not looking at the right place. ifconfig indicates that the interface is down, but the activity links are still blinking. If my memory is good, with "set_config 0" there was a "disconnected" message on the console, but I'm not 100% sure (since I removed the config.xml line I can't see any message related to this NIC on the console).
The weirdest thing it that the link being active while the interface is down (GUI & ifconfig, and the console doesn't display any IP address assigned to the NIC). My wife and I were working from home with 2 VPNs and we only figured the Internet was not working when we tried to use our personnal PC. The existing TCP tunnels were working perfectly fine.
Please let me know if you want me to run special command lines for you the next time it happens (in 2 days probably sigh).
-
Grab a status_output file when it fails. Navigate to <firewall IP>/status.php , it's not linked from the GUI anyway. Then you can review that later.
However if open connections continued to p[ass traffic that doesn't sound like a NIC issue. More like state exhaustion or conflciting states maybe.
You could try adding to /boot/loader.conf.local:
hint.ure.0.disabled=1
That might just disable it completely rather than allow cdce to attach though.
Steve
-
I tried "hint.ure.0.disabled=1" but then ue0 interface was not available anymore... Do you mean I should use this loader.conf.local to disable the new driver, in which case I should revert config.xml with the previous <earlyshellcmd> to get the previous cdce driver?
If so, I'll give it a 2nd try next time it fails (I'm waiting to grab status_output before).
-
Yes, you may need to change the config index again to have cdce recognise it.
Try running
usbconfig dump_all_desc
to see what config indexes exist for it and what interfaces they present.Steve
-
Unfortunately, it was not possible to execute the "status" link: the GUI was not accessible this time with an nginx error message (gateway error). As always, the existing connections were still alive. I reverted to the cdce driver with the previous usbconfig line and hint.ure.0.disabled=1. Let's wait a few days to see if it's stable like 2.5.1 was before.
Just another detail: I have an alternate 4G/WiFi connection (dual WAN for backup). Usually, I just have to power on the 4G device, but this time the firewall could not establish the WiFi connection. After reboot everything was working fine. It seems that this NIC failure causes a more global failure (nginx and WiFi failure at least).
-
Ah, so you were able to move back to the cdce driver by disabling ure0? Good to know.
Your description of the problem seem like something more wide ranging than the driver. Like maybe php stalling on something? I would expect the logs to show something.
Steve
-
It has been 7 days without any issue, as far as I'm concerned the workaround to force cdce driver instead of the new ure driver works perfectly with my Thinkpad RTL8153 USB adaptor. To summarize in one post to help other users:
/boot/loader.conf.local:
hint.ure.0.disabled=1
/conf/config.xml:
<earlyshellcmd>usbconfig -d `usbconfig list | grep "Thinkpad" | cut -c5-7` set_config 1</earlyshellcmd>
Thank you, Jean-Francois.
-
@jean-francois This is still relevant in 2.6.0. Had a NIC die and didn't have a replacement on hand. Plugged in a TP-Link UE200 with the RTL8153 chipset. It was capping out at 40MBit.
Using the 2 config lines you posted boosted the throughput up to 250mbit, which should suffice until a replacement nic arrives.