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.
Best regards
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.
Best regards
Jan
Hi,
same for me. The core update 170 didn’t change anything about the issue.
Best regards
Same problem with another stick/chip:
Bus 003 Device 006: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
I “solved” this with a cron entry: @reboot sleep 5m && /root/usb.sh
echo 0 > /sys/bus/usb/devices/usb3/authorized # unload usb3
echo 1 > /sys/bus/usb/devices/usb3/authorized # load usb3
modprobe -r r8153_ecm
modprobe r8153_ecm
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 
2 Likes
Hi all,
apologies for my belated response. 
@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.
Thanks, and best regards,
Peter Müller
No need to apologize 
Sure, here it is: fireinfo.ipfire.org - Profile 6119e3d143e58841b36955e7dac79fc306d25642
Hi Peter,
the Fireinfo Link: https://fireinfo.ipfire.org/profile/c79cc573df5f746ab0d761a8a32f4bf711aa5dd8
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
EDIT: added lsusb verbose info:
RTL8153 (after un-re-plug):
lsusb - Cable Creation USB3 to Ethernet Adapter - RTL8153 (after un-re-plug) copy.txt.zip (2.8 KB)
RTL8153 (after reboot):
lsusb - Cable Creation USB3 to Ethernet Adapter - RTL8153 (after reboot) copy.txt.zip (2.9 KB)
1 Like
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.
Any updates on this?
Hey there,
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
echo usb4 > /sys/bus/usb/drivers/usb/unbind
echo usb4 > /sys/bus/usb/drivers/usb/bind
Since IPFire only has problems with the dongle at startup, I added these lines to my “firewall.local”-file with some “sleep” between them.
Now, everything works fine! 
Have a nice weekend!
Greetings
Alex
3 Likes
You can use also rc.local .
2 Likes
Hey cfusco,
thanks for your addition.
I found “rc.local” nowhere documented in the IPFire-wiki (only on an old page from IPCop :D).
What is the difference between “rc.local” and “firewall.local” and are there any advantages / disadvantages to use one over the other?
Greetings
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.
3 Likes
I agree. It should be documented.
1 Like
@jon If you create a stub for an entry explaining rc.local in the wiki, I will take my post above and restructure it, with links and everything and fill up the wiki entry. If you agree, should this cover both files (rc.local and firewall.local)?
1 Like
How about here:
https://wiki.ipfire.org/pkgs/rc-local
firewall.local already has a wiki page:
https://wiki.ipfire.org/configuration/firewall/firewall-local
So maybe add links and/or notes to the firewall.local page
1 Like
@meathill
If the 8153 keeps getting detected as 8151, why not just blacklisting the device 8151 in udev? I think the path in IPFire should be /etc/udev/rules.d/23-usb.rules.
Here’s a small writing about how this could be done:
https://www.projectgus.com/2014/09/blacklisting-a-single-usb-device-from-linux/
@pmueller
What about adding some support (via an additional .local file for example) for blacklisting devices? So that it won’t get overwritten by the next update?
1 Like
Don’t create your rule in 23-usb.rules but create a new rule file such as 99-disable-8151-usb.rules and add the disable info in that. Then it won’t be overwritten by a core update. You can also add that file name to your include.user file so it is backed up and available for restore if you need to do a fresh install etc.
I think that should give you what you are looking for.
3 Likes
Thank you guys for all the workarounds. I tried both the udev blacklisting and the rc.local solution. The udev blacklisting seems like a cleaner solution, but unfortunately doesn’t work for me. Rc.local with usb rebind works fine.
@chrisk1 @bonnietwin
I created “/etc/udev/rules.d/99-disable-8151-usb.rules” with the following content:
# Disable wrong product ID for USB ethernet adapter
SUBSYSTEM=="usb", ATTRS{idVendor}=="2357", ATTRS{idProduct}=="8151", ATTR{authorized}="0"
After several reboots and trying to enable the rule via “udevadm control --reload” lsusb still shows:
Bus 004 Device 002: ID 2357:8151 TP-Link USB 10/100/1000 LAN
Bus 003 Device 002: ID 2357:0601 TP-Link UE300 10/100/1000 LAN (ethernet mode) [Realtek RTL8153]
@lexuspolaris
Therefore I added the following to “/etc/sysconfig/rc.local”:
echo usb4 > /sys/bus/usb/drivers/usb/unbind
sleep 1
echo usb4 > /sys/bus/usb/drivers/usb/bind
exit 0
Now I’m happy with both ethernet adapters beeing recognized at reboot!
Thank you again I really appreciate the great support here.
2 Likes
https://bbs.archlinux.org/viewtopic.php?id=284914
Last reply seems to solve the whole problem. Didn´t get any disconnect messages or similar errors for two days at least.
try to disable “SG”
ethtool -K INSERT_NAME_OF_DEVICE_HERE sg off
e.g. ethtool -K orange0 sg off
Problem occured again today. So it´s not a solution
EDIT: Moderator corrected the bbs.archlinux.org link in Line 1