I thought I should create new thread here, sorry if it's already discussed but after buying 3 separate USB 3.0 to Gigabit Adapter (all as WAN) I encounter multiple problem wtih Openwrt Snapshot (kernel 5.4.x) below :
Generic USB 3.0 to Gigabit Ethernet with Realtek RTL8153 chipset
Basically it's no great from the start, random disconnect and hardware not detected after getting wan
activity, similar problem also occured when in Windows 10 but after updating the driver from realtek
website the problem's gone. As for OpenWRT putting the adapter in USB 2.0 port solve the problem
although for those with fast gigabit internet, the speeds will be halved to max USB 2.0 speed.
Generic USB 3.0 to Gigabit Ethernet with AX88179 chipset
At first all seems well but after a day or more (random but usually between 1 day) the WAN side
failed to get DHCP Lease and can only resolved with usbreset command, unplugging and
replugging the USB Adapter, or rebooting the pi.
Tp-Link UE-300 USB 3.0 to Gigabit Ethernet with RTL8153
I had better experience with this dongle, but after a week or more (at least better than the previous
AX88179) similar problem occured when getting DHCP lease :
Sun Jul 26 13:26:18 2020 daemon.notice netifd: wan (1702): udhcpc: sending renew to 10.x.x.x
Sun Jul 26 13:26:19 2020 daemon.notice netifd: wan (1702): udhcpc: lease of 10.x.x.x obtained,
lease time 3600
the solution also the same like previous adapter, usbreset, unplugging, or rebooting the pi.
I don't have device with stable kernel (4.9) to test (usually rpi 3b), but using Intel NUC and OPNsense with RTL8153 generic adapter seems stable enough, I do plan to use OpenWRT on x86 to test if in the future when I have spare time.
I have an i-tec with RTL8153 working fine since April.
I am using pppoe and dhcpv6, however I don't see any issue from the logs you attached. You sent a RENEW and next second you received the lease.
This is weird, as you know I am using a UE300 too. My RPi4 has been up and running for 25 days now on a 5.4 kernel. No need to reboot, reset USB or unplug the USB NIC. What's the problem with the DCHP lease? Would you be more specific? Is it forgetting the IP and you it is not renewing automatically?
For generic USB , I assume (or what I believe at least) the problem lies more than just chipset but other component that makes them. The generic RTL8153 and AX88179 both use similar housing which probably the other components outsourced from similar factory.
As for the UE300, maybe other combination like ISP, kernel version, and add-ins? I use layer_cake in SQM_QOS, other than that basic like luci_statistics and drivers for rtc.
When using AX88179, after a day I got similar message like above, but it failed to renew lease... on UE300 (From observation about 2 weeks more it only occured 2 times, usually on weekend but the only things strikes me is that it happened just when I got home usually (seeing from the log). bandwidth statistics usually low to none but when I got home bandwidth surged (although not huge) and that's when things get awry.
If you saw the message lease of 10.x.x.x obtained, lease time 3600 in your logs, it means the packet was received and examined by OpenWrt. So it has passed already the part where a bad driver or faulty card would cause problems.
no other usb devices than the usb card, the raspberry pi 4 itself positioned near ISP modem. but there are other cable (including PoE to AP) nearby.
I do plan to wait for few more weeks and observe if the problem persists or not, and maybe try switching the USB ethernet as LAN port and leaving the WAN side to native LAN, is it a good idea?
I see, that's also explained when using generic AX88179 in the interfaces I don't get WAN side IP (the 10.x.x.x part) and the error a bit different. I try to look for other possibilities then.
Is not a bad idea. Main reason to keep your USB NIC as WAN is to have access to your LAN interface for admin purposes, you can use your RPi4's WiFi for this purpose, tho'.
In any case, when I used my AX88179 I had no problems at all. My Pi is close to my cable modem right under my APs —like 30 cm apart of each other— and right besides a microwave oven, which is less than ideal and, I have none of your problems.
hi guys,
I'm running for months a PI4 + Buster image + r8153 USB adapter, sniffing all my data (usb 3.0 port), with no disconnections or issues (ntop-ng on it).
And decide to try an openwrt image on it rpi-4_snapshot_1.7.66-7_r14267. BUILD_ID="r14267-18fbb9aa21"
So the HW is the same, but after a day playing, I came up with the infamous disappearances/instability listed above.
I performed
opkg update
opkg install kmod-usb-net-rtl8152
But it doesn't seem to be better.
[ 602.048544] usb 1-1: USB disconnect, device number 2
[ 602.350168] usb 1-1.2: device not accepting address 5, error -62
[ 602.367037] usb 1-1-port2: couldn't allocate usb_device
i'd advise you to either remove all 'usbmode switch / qmi / lte / otg" style packages or test with an official build to be absolutely certain that your issues are not the result of package combinations within the build...
if I had to guess though... i'd say it's not build related... and more likely as stated above... related to particular device/chip / use case or environmental/hw combinations/subtlties/factors...
what is the exact adapter you are using? and exact rpi model?
in this case 99.999% sure it's not build related... and doubt using the official image assist... ( although particular package conflicts are still in the picture )...
official images ( i.e. to test with a bare minimum package set ) but again... fairly confident it will yeild identical outcomes...
was also reading other posts, about link power mgt or other
eg. disable link power mgt? usbcore.quirks=0bda:8153:k ? how would I do this on the PI4 openwrt to see if any diff?
or things about Link Negotiation:auto or not... how to change all those params?
note, I have 2 of those adapaters, let me play & see if any difference as well ...
tx
yeah... you could try the quirks but to be honest... when troubleshooting things like this you are best to start broad and work your way down...
is buster 32bit? there is 32bit openwrt for the pi... well worth a comparison imho... especially any differences in sysfs/ethtool regarding usb/that nic...