Describe the bug
The usb ethernet dongles are all prone to issues, in my case all r8152b dongles (yes, all of them, I have 3) just stop working during a lot of traffic and just don't receive or transmit any data without any reported dmesg issues. Unfortunately CONFIG_USB_RTL8152=y is set, so it is not possible to just use the dkms module which uses the vendor code that appears to work much better without rebuilding my own kernel (or messing with depmod priorities and initcall blacklists).
Steps to reproduce the behaviour
use a r8152b usb eth dongle & watch it fail after some time with a bit of traffic (apt dist-upgrade, docker downloads, ..) , versions without b might be worse, versions ending in bg might work better.
Device (s)
Raspberry Pi CM5
System
current rpi os and next kernels
Logs
No response
Additional context
All of the usb ethernet devices should be modules as far as I am concerned because they all have weird issues. I do have another AX88179A dongle, which has its own kernel module, which gets loaded, but is unused, because it is nowadays supported by cdc_ncm, and the actual module is apparently really bad (?).
Unfortunaly setting the mac with cdc_ncm silently fails which is a known issue so setting the mac means not getting any traffic unless you set the interface to promiscuous mode. Fun to debug, tcpdump makes it work!
Fortunately the kernel config is CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_AX88179_178A=m so I can just blacklist that and use a dkms module using the vendor drivers and.. that's it. It just works, no depmod mystery or rebuilding required.
Describe the bug
The usb ethernet dongles are all prone to issues, in my case all r8152b dongles (yes, all of them, I have 3) just stop working during a lot of traffic and just don't receive or transmit any data without any reported dmesg issues. Unfortunately CONFIG_USB_RTL8152=y is set, so it is not possible to just use the dkms module which uses the vendor code that appears to work much better without rebuilding my own kernel (or messing with depmod priorities and initcall blacklists).
Steps to reproduce the behaviour
use a r8152b usb eth dongle & watch it fail after some time with a bit of traffic (apt dist-upgrade, docker downloads, ..) , versions without b might be worse, versions ending in bg might work better.
Device (s)
Raspberry Pi CM5
System
current rpi os and next kernels
Logs
No response
Additional context
All of the usb ethernet devices should be modules as far as I am concerned because they all have weird issues. I do have another AX88179A dongle, which has its own kernel module, which gets loaded, but is unused, because it is nowadays supported by cdc_ncm, and the actual module is apparently really bad (?).
Unfortunaly setting the mac with cdc_ncm silently fails which is a known issue so setting the mac means not getting any traffic unless you set the interface to promiscuous mode. Fun to debug, tcpdump makes it work!
Fortunately the kernel config is CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_AX88179_178A=m so I can just blacklist that and use a dkms module using the vendor drivers and.. that's it. It just works, no depmod mystery or rebuilding required.