[Solved] Strange behaviour with realtek USB NIC

Started by schnipp, February 25, 2022, 10:50:39 AM

Previous topic - Next topic
February 25, 2022, 10:50:39 AM Last Edit: March 17, 2022, 09:16:00 PM by schnipp
After upgrading Opnsense from 21.7.8 to 22.1.1_3 I have problems with my Realtek USB NIC which is only used for a separate printer LAN. So, performance doesn't matter. I know about the discussions regarding realtek device support by FreeBSD's original drivers. The USB card is a quite old one and worked flawlessly with Opnsnese 21.7.x and should be supported by FreeBSD.

Before upgrading I installed the plugin "os-realtek-re", but I cannot verify which driver is in use and how to switch to another one.

usbconfig shows the following results, so I guess "ure" is the driver in use

root@opnsense-host:~ # usbconfig ugen0.2 show_ifdrv
ugen0.2: <Realtek USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (350mA)
ugen0.2.0: ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 2.10/31.00, addr 1>


The strange thing is the NIC stops working after link changes from down to up state (the printer is directly connected via a patch cable). Packet capture shows that packets are probably sent but no ones are received. But, with only one hands-up step I get the NIC to work properly again. Stopping and restarting the interface at the command line is a workaround

$ ifconfig ue0 down && ifocnfig ue0 up

Does anybody have a clue on that? Or can anybody tell me how to test the other NIC driver via command line (kldload etc.)?
OPNsense 24.7.11_2-amd64

I have read that usb NICs aren't supported well by FreeBSD. The NIC itself works well after stoping and starting the interface using ifconfig. Does anybody encounter similar problems or can test this scenario?
OPNsense 24.7.11_2-amd64

I did some more investigation and found out that the Realtek 8153 chipset family provide two different interfaces. The vendor specific which is the default one when connecting the USB ethernet adapter. The second is based on USB CDC-ECM (USB Communications Device Class - Ethernet Control Model). The second interface mode can be selected by configuring the device to the second USB configuration set (see link, Ch. 6.1.1).

The ECM based interface works well and is used in conjunction with another driver ("if_cdce" instead of "if_ure"). According to its doucmentation the vendor specific interface can perform better than the ECM interface. But for my connected printer it doesn't matter.

In my case the following command sets the device (ugen0.2) into ECM mode:

$ usbconfig -d 0.2 set_config 1

For permanently setting the device into this mode usb_quirks helps out. The following line needs to be added to configuration file /boot/loader.conf.local:

hw.usb.quirk.0="0x0bda 0x8153 0 0xffff UQ_CFG_INDEX_1"

Details of the configuration string can be found in the manpage of "usb_quirk"
OPNsense 24.7.11_2-amd64

Quote from: schnipp on March 17, 2022, 09:15:40 PM
For permanently setting the device into this mode usb_quirks helps out. The following line needs to be added to configuration file /boot/loader.conf.local:

hw.usb.quirk.0="0x0bda 0x8153 0 0xffff UQ_CFG_INDEX_1"

Details of the configuration string can be found in the manpage of "usb_quirk"
Don't manipulate configuration files. If you use the tunables section in the UI, your settings will be saved to a configuration backup whenever you create one and will survive an update.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

March 17, 2022, 09:36:39 PM #4 Last Edit: March 17, 2022, 09:40:32 PM by schnipp
Quote from: pmhausen on March 17, 2022, 09:22:44 PM
Don't manipulate configuration files. If you use the tunables section in the UI, your settings will be saved to a configuration backup whenever you create one and will survive an update.

In most cases the hint is corrrect. But, according to the manpage it is a loader tunable which must be applied before loading the kernel. I am not sure whether adding this parameter to the tunable section will work. So far all parameters added to the file loader.conf.local (not loader.conf) survived all updates I ever applied since Opnsense 18.x

Is it in this case possible to use the tunable section instead of the configuration file?

Edit:
Or are the tunables automatically written to the loader.conf file
OPNsense 24.7.11_2-amd64

Tunables added in the UI are added to /boot/loader.conf - so that will work.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

In this specific case, what to add exactly in tunable ?

In the specific case that you happen to have the exact same hardware as @schnipp, you need to enter exactly what they wrote:
hw.usb.quirk.0="0x0bda 0x8153 0 0xffff UQ_CFG_INDEX_1"

Everything left of the "=" is the "Tunable". Everything right of the "=" is the "Value".
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)


Quote from: pmhausen on March 17, 2022, 10:33:56 PM
Tunables added in the UI are added to /boot/loader.conf - so that will work.

Thanks for the hint. I have moved the loader tunable to the GUI based configuration
OPNsense 24.7.11_2-amd64

It looks like the CDCE mode of  the Realtek NIC doesn't work either since Opnsense 22.1.10. Does anybody observed the same issue?

OPNsense 24.7.11_2-amd64