Hi
I’m using two TP-Link USB 3.0 LAN network adapters. When only using one of them I’m not having any problems. If I have both attached and do a reboot, one is not recognized anymore. If I shutdown and boot up regularly the problem doesn’t occur. If I re plug the adapter while not recognized it’s being recognized. After re plugging the product-ID shown by “lsusb” changes from:
Bus 004 Device 003: ID 2357:0601 TP-Link USB 10/100/1000 LAN
Bus 004 Device 002: ID 2357:8151 TP-Link USB 10/100/1000 LAN
to:
Bus 004 Device 003: ID 2357:0601 TP-Link USB 10/100/1000 LAN
Bus 004 Device 004: ID 2357:0601 TP-Link USB 10/100/1000 LAN
I’m using a notebook which only has two USB ports so I can’t try another port.
Any suggestions?
Thank you for your help!
thank you for reporting this - it reminds me of this bug which unfortunately only occurs on some mainboards, and we never managed to confirm it aside from one machine I am personally running.
Just to ensure: Which Core Update are you running?
Thanks, and best regards,
Peter Müller
P.S.: Actually, this recent commit in the Linux stable tree looks related, but I may be wrong. Are you capable of compiling the latest Linux 5.15.x version yourself and give it a try?
Hi,
thank you for the quick reply. I’m running on the latest Core Update, 168. Unfortunately I’m not capable of compiling the latest kernel.
Best regards
Well, with regards to the aforementioned kernel commit, @arne_f told me that this merely affects USB OTG, hence most probably would not have resolved your issue.
Nevertheless, may I ask you to give Core Update 169 (testing) a try? Since we updated the kernel in there, there is a slim change that this changes anything. Also, to investigate weather this is mainboard or USB hub related, could you please post your Fireinfo profile link here?
My guess is that this problem (presumed we share the same one ) is not related to the USB adapter itself, but to the USB hub component on the mainboard. I will investigate, but do not have an idea how to fix this at the moment. Probably a kernel bug or something alike…
the upcoming Core Update 170, which should be available for testing soon-ish, comes with an updated kernel. Since I recall 5.15.57 featuring some changes to XHCI and possibly other related components, it would be great if you could give Core Update 170 a try once a testing version of it is released.
Hi,
thank you for your effords, Peter. Unfortunately I don’t have physical access to the system at the moment. I will try the update with the next stable release.
Hi Peter,
we have a pcengine apu3 system, also with a TP-Link USB 3.0 LAN network adapter but only one and same issue after a reboot from the ipfire.
In Core update 170 the problem still exist.
You have to change the usb entry from /sys/bus/usb/devices accordingly (lsusb). After pluging you can see what chipset is loaded and alter modprobe for your chipset
It’s an apu2 and in this case I disable and reenable all usb devices. Be careful if you have different slots and other machines while running the OS from usb
@janw & @angrytux - could you please provide me with the Fireinfo profile links of these machines, so I can investigate? This looks like a general problem with some USB hubs, rather than related to certain NICs.
The issue seems to have an unhealthy Product attraction to 8151.
I plugged an unused RTL8153 Gigabit Ethernet Adapter (vendor CableCreation) and I see this:
[root@ipfireAPU ~]# lsusb
Bus 002 Device 002: ID 0438:7900 Advanced Micro Devices, Inc.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0438:7900 Advanced Micro Devices, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[root@ipfireAPU ~]#
If I reboot the IPFire device with RTL8153 Gigabit Ethernet Adapter (vendor CableCreation) changes to this:
[root@ipfireAPU ~]# lsusb
Bus 002 Device 002: ID 0438:7900 Advanced Micro Devices, Inc.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0438:7900 Advanced Micro Devices, Inc.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 002: ID 0bda:8151 Realtek Semiconductor Corp. RTL8151 Adapteon Business Mobile Networks BV
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[root@ipfireAPU ~]#
Tested on:
PCEngines APU4D4 IPFire 2.27 (x86_64) - Core-Update 170
This is exactly the same output I get. USB-to-Ethernet-Adapter from Delock, works without any problems. As soon as I reboot IPFire it’s not mentioned anymore in the zone cofiguration and lsusb shows “8151”. When I unplug it and plug it back in again, lsusb shows “8153” and it works again.
I have a IPFire Mini Appliance and the most recent core 173.
I tried out the suggestion made by @angrytux, which unfortunately didn’t work for me. I did some digging and found the solution in this post:
The first suggestion, where you “rebind” the port itself, did not work for me either, but the second one, where you “rebind” the whole interface, did. Since I have an IPFire Mini Appliance and the USB-ports are at “Bus 004” (your Bus might differ, just ceck with “lsusb”) the working commands for me are
firewall.local is supposed to be dedicated only to firewall rules and I think it is specific for IPFire. Instead rc.local is a very old Unix concept of all SystemV boot systems. I believe they both work in the same way.
Basically, all the scripts at boot or shutdown are run by the init process and are located in /etc/init.d. However init will run the scripts in the sequence indicated by the specific runlevel (a number from 0 to 6). This mechanism is realized by having symbolic links to those scripts placed in the directories named /etc/rc.d/rc#.d, where # is the runlevel number. Each one of those numbers represents a specific sequence of scripts for a given purpose. For example, if you want to boot as a single user, the scripts are defined in /etc/rc.d/rc0.d, multi-user /etc/rc.d/rc3.d, reboot /etc/rc.d/rc6.d and so on. IPFire has only 3 run levels, 0, 3 and 6.
If a system administrator wants to modify the boot process with a script, he/she is supposed to put the script in /etc/init.d and then symlink it in each appropriate runlevel in the correct sequence (defined by the symlink name). To make the sysadmin life easier, rc.local was created as a separate thing. Whatever you put in there is executed at the end of each runlevel sequence, just before the login.
For example, If you go to the terminal and type init 6, you are telling the init process to execute sequentially all the scripts linked in the rc6.d folder, which will reboot the machine. Even if there is no symlink for rc.local, it will be executed nonetheless.
Keep in mind that I do not know what I am saying and whatever I wrote above, might or might not be correct. Maybe someone more competent will write what I got wrong in this post.
) is not related to the USB adapter itself, but to the USB hub component on the mainboard. I will investigate, but do not have an idea how to fix this at the moment. Probably a kernel bug or something alike… 
