OPNsense Forum

Archive => 22.1 Legacy Series => Topic started by: schnipp on February 25, 2022, 10:50:39 am

Title: [Solved] Strange behaviour with realtek USB NIC
Post by: schnipp on February 25, 2022, 10:50:39 am
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

Code: [Select]
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

Code: [Select]
$ 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.)?
Title: Re: Strange behaviour with realtek USB NIC
Post by: schnipp on March 06, 2022, 06:24:39 pm
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?
Title: Re: Strange behaviour with realtek USB NIC
Post by: schnipp on March 17, 2022, 09:15:40 pm
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 (https://www.olimex.com/Products/USB-Modules/USB-GIGABIT/resources/rtl8153.pdf), 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:

Code: [Select]
$ 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:

Code: [Select]
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"
Title: Re: Strange behaviour with realtek USB NIC
Post by: Patrick M. Hausen on March 17, 2022, 09:22:44 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:

Code: [Select]
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.
Title: Re: Strange behaviour with realtek USB NIC
Post by: schnipp on March 17, 2022, 09:36:39 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
Title: Re: [Solved] Strange behaviour with realtek USB NIC
Post by: Patrick M. Hausen on March 17, 2022, 10:33:56 pm
Tunables added in the UI are added to /boot/loader.conf - so that will work.
Title: Re: [Solved] Strange behaviour with realtek USB NIC
Post by: lello1231 on March 18, 2022, 01:40:29 pm
In this specific case, what to add exactly in tunable ?
Title: Re: [Solved] Strange behaviour with realtek USB NIC
Post by: Patrick M. Hausen on March 18, 2022, 02:20:09 pm
In the specific case that you happen to have the exact same hardware as @schnipp, you need to enter exactly what they wrote:
Code: [Select]
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".
Title: Re: [Solved] Strange behaviour with realtek USB NIC
Post by: franco on March 18, 2022, 02:24:21 pm
*Save value without double-quotes
Title: Re: [Solved] Strange behaviour with realtek USB NIC
Post by: schnipp on March 18, 2022, 03:54:36 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
Title: Re: [Solved] Strange behaviour with realtek USB NIC
Post by: schnipp on July 18, 2022, 10:06:31 pm
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?