Flint 3 tethering fails on reboot

Router
1

On the flint 3 every time I reboot the tethering is lost. I need to unplug and replug in the cable manually.

Is it possible to get a fix for this?

Is there a way to force the USB port to reset completely within luci that will do the same as unplugging? I could then script a fix?

2

i found the following seems to work…

sleep 10
echo 0 > /sys/bus/usb/devices/usb1/authorized
sleep 2
echo 1 > /sys/bus/usb/devices/usb1/authorized

Is this safe to use?

Also spotted the startup script under luci, is this of use? Edit looks like it forces usb2

usb3_disable

Edit: None of these options work on reboot :frowning:

4

Hi,

We were unable to reproduce the issue.

During testing with Flint 3 v4.8.3 and an Android phone, restarting the router and then enabling USB Tethering on the Android device (required by Android to reconfigure the USB mode after each USB disconnect/reconnect or a unlock if you have configured USB tethering as default USB configuration) allowed the router to reconnect automatically.

But If you believe it may help, you can also try:

echo 0 > /sys/class/gpio/usb_power/value
sleep 10
echo 1 > /sys/class/gpio/usb_power/value
5

Thanks! ive put that in the luci startup section and it does the trick!

Might be worth adding an option to the gl-inet section to do this automatically.

7

Just wanted to add that I'm facing the same issue. Just bought a flint 3, and have a beryl ax as well.

With the beryl ax on 4.7.4 firmware:

  • Samsung s25 ultra set with usb tethering as default mode in developer options
  • S25 connected to beryl ax via usb 3.0
  • When beryl ax reboots or loses power, all I have to do to get usb tethering connectivity is to unlock the phone. I don't have to reconnect any cable.

With Flint 3, running latest 4.8.3 firmware:

  • Using the same s25 ultra, connected via usb 3.0
  • When flint 3 reboots, I unlock the phone but it doesn't recognize usb tethering as valid connection (usb tethering appears selected but greyed out on the android usb options). If I the unplug the usb cable and plug again, it works fine and automatically connects via usb tethering

I'll try those commands you shared later but would be great to get this fixed without having to rely on that.

Thanks for helping!

8

Thank you for your feedback.
We have successfully reproduced the issue using a Samsung S24 Ultra and will have our development team investigate further.

10

Wow thanks, wasn't expecting such a fast reply! Talk about being reactive, even during holiday season. Is that why you called them flints? Cause you're on fire! Hehehe

Happy holidays to the staff!

1 Like
11

So I’ve since tested this also with a Samsung S23 and I experienced the same bug, but I have some additional notes:

  • When I first restart both the router and the phone, no matter if the S23 or S25 ultra, the results are the same, the router connects fine via usb tethering and remains stable with internet.

BEFORE SCRIPT WAS ADDED:

  • After that, if the usb connection drops due to usb cable being disconnected, or power goes down, or if you go to the phone and disable usb tethering and re-enable it again, the usb tethering will NOT reconnect again and I noticed in the logs it always said something like usb failed enumeration.

AFTER SCRIPT WAS ADDED:

  • Since then I tried the script you provided above and it helped, meaning, in the scenarios described above, I could reconnect usb tethering if I re-plugged the cable or re-enabled usb tethering on the phone after disabling it, but the problem that I face when I do that is that the connectivity lasts only a few minutes and after a while it says that the internet is not reachable via usb tethering, if I disconnect the usb cable and connect it again, I notice that on the logs the USB device number increases always +1, and I can get internet for a few minutes, then it loses internet connectivity again. I also turned on repeater on the phone to make sure that it wasn’t an internet problem, and I can confirm that every time the usb tethering loses internet connectivity, the repeater, connected to the same phone via hotspot, still has internet, so it’s a usb tethering issue.

  • What I’m now doing to be able to have stable internet via usb tethering is I use your script on the “local startup” tab in Luci, and I always reboot both the router and the phone, the first usb tethering connection that is established between the phone and the router seems to always be stable and lasts for days, but if I disconnect it for some reason, internet connectivity via usb tethering after that seems unstable and lasts only some minutes, I have no idea why.

  • I’ll try to gather more evidence over time, but I need the connection to be stable during the week so I cannot mess around with this too much, I’ll try more during the weekend if possible.

  • In the meantime I would suggested if possible that when you guys test this out, that you do these things:

    • Unplug and plug usb cable with usb tethering on and wait at least 20 minutes to see if internet connectivity is stable or if it loses connectivty.
    • Disable and re-enable usb tethering on the phone with the usb cable connected, and again, same thing, look for internet instability via usb tethering after around 20 minutes
    • Unplug router from power and plug again, and again test internet via usb tethering
    • Compare all scenarios described above with a fresh reboot from both router and phone, this seems to be the only stable solution.
12

Thank you for sharing such specific information.
We will forward it to the R&D and testing teams.

13

Hi,

Here’s more concrete evidences that might help you debug this issue. After around 5 days with the Flint 3 connected via usb tethering with a Samsung S23 without any issues, suddenly the tethering connection was lost and it fell back to the connection via repeater mode using multiwan.

  • I tried two things to re-enable usb tethering:
  1. Unlocking the phone to re-enable usb-tethering option directly on android.
  2. Did not work, usb tethering option appears greyed out on the phone.
  3. Unplugged and plugged usb cable again.
    1. This triggers usb tethering to become “not greyed out” but it never becomes enabled. A few seconds after the usb cable is plugged in again, it becomes greyed out again.

Here are the system logs exactly at the moment the usb cable is plugged in again:

Wed Jan 21 21:40:05 2026 kern.info kernel: [775185.494906] usb 1-1: new high-speed USB device number 21 using xhci-hcd
Wed Jan 21 21:40:05 2026 kern.err kernel: [775185.644934] usb 1-1: device descriptor read/64, error -71
Wed Jan 21 21:40:06 2026 kern.err kernel: [775185.914939] usb 1-1: device descriptor read/64, error -71
Wed Jan 21 21:40:06 2026 kern.info kernel: [775186.184909] usb 1-1: new high-speed USB device number 22 using xhci-hcd
Wed Jan 21 21:40:06 2026 kern.err kernel: [775186.334935] usb 1-1: device descriptor read/64, error -71
Wed Jan 21 21:40:06 2026 kern.err kernel: [775186.604926] usb 1-1: device descriptor read/64, error -71
Wed Jan 21 21:40:06 2026 kern.info kernel: [775186.725071] usb usb1-port1: attempt power cycle
Wed Jan 21 21:40:07 2026 kern.info kernel: [775187.194908] usb 1-1: new high-speed USB device number 23 using xhci-hcd
Wed Jan 21 21:40:07 2026 kern.warn kernel: [775187.194979] usb 1-1: Device not responding to setup address.
Wed Jan 21 21:40:07 2026 kern.warn kernel: [775187.414951] usb 1-1: Device not responding to setup address.
Wed Jan 21 21:40:07 2026 kern.err kernel: [775187.634894] usb 1-1: device not accepting address 23, error -71
Wed Jan 21 21:40:07 2026 kern.info kernel: [775187.784901] usb 1-1: new high-speed USB device number 24 using xhci-hcd
Wed Jan 21 21:40:07 2026 kern.warn kernel: [775187.784969] usb 1-1: Device not responding to setup address.
Wed Jan 21 21:40:08 2026 kern.warn kernel: [775188.004940] usb 1-1: Device not responding to setup address.
Wed Jan 21 21:40:08 2026 kern.err kernel: [775188.234894] usb 1-1: device not accepting address 24, error -71
Wed Jan 21 21:40:08 2026 kern.err kernel: [775188.235087] usb usb1-port1: unable to enumerate USB device
Wed Jan 21 21:40:41 2026 daemon.info hostapd: wlan0: STA 40:e2:30:f4:5b:c5 IEEE 802.11: authenticated
Wed Jan 21 21:40:41 2026 kern.err kernel: [775221.789594] wlan: [0:E:ANY] ieee80211_recv_asreq: ieee80211_recv_asreq: assoc req from dms not-supported sta :40:e2:30:f4:5b:c5
Wed Jan 21 21:40:41 2026 kern.err kernel: [775221.789594]
Wed Jan 21 21:40:41 2026 daemon.info hostapd: wlan0: STA 40:e2:30:f4:5b:c5 IEEE 802.11: associated (aid 3)
Wed Jan 21 21:40:41 2026 daemon.info hostapd: wlan0: STA 40:e2:30:f4:5b:c5 WPA: sending 1/4 msg of 4-Way Handshake
Wed Jan 21 21:40:41 2026 kern.err kernel: [775221.794884] wlan: [7632:I:ANY] wlan_cfg80211_change_station: Ignore set station for ap vlan wlan0
Wed Jan 21 21:40:41 2026 daemon.info hostapd: wlan0: STA 40:e2:30:f4:5b:c5 WPA: received EAPOL-Key frame (2/4 Pairwise)
Wed Jan 21 21:40:41 2026 daemon.info hostapd: wlan0: STA 40:e2:30:f4:5b:c5 WPA: sending 3/4 msg of 4-Way Handshake
Wed Jan 21 21:40:41 2026 daemon.info hostapd: wlan0: STA 40:e2:30:f4:5b:c5 WPA: received EAPOL-Key frame (4/4 Pairwise)
Wed Jan 21 21:40:41 2026 daemon.info hostapd: wlan0: STA 40:e2:30:f4:5b:c5 RADIUS: starting accounting session 39BD18EC5062E9A2
Wed Jan 21 21:40:41 2026 daemon.info hostapd: wlan0: STA 40:e2:30:f4:5b:c5 WPA: pairwise key handshake completed (RSN)
Wed Jan 21 21:40:46 2026 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) 192.168.8.222 40:e2:30:f4:5b:c5
Wed Jan 21 21:40:46 2026 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.8.222 40:e2:30:f4:5b:c5
Wed Jan 21 21:40:47 2026 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.8.222 40:e2:30:f4:5b:c5
Wed Jan 21 21:40:47 2026 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.8.222 40:e2:30:f4:5b:c5 MrBlueSocks
Wed Jan 21 21:40:50 2026 daemon.info dnsmasq[1]: read /etc/hosts - 12 names
Wed Jan 21 21:40:50 2026 daemon.info dnsmasq[1]: read /tmp/hosts/dhcp.ovpnclient1 - 4 names
Wed Jan 21 21:40:50 2026 daemon.info dnsmasq[1]: read /tmp/hosts.vpn/lan_hosts - 16 names
Wed Jan 21 21:40:50 2026 daemon.info dnsmasq-dhcp[1]: read /etc/ethers - 0 addresses
Wed Jan 21 21:40:51 2026 daemon.err uhttpd[10389]: [info] luci: accepted login on / for root from 192.168.8.178
Wed Jan 21 21:41:12 2026 kern.info kernel: [775252.564575] usb 1-1: new high-speed USB device number 25 using xhci-hcd
Wed Jan 21 21:41:12 2026 kern.err kernel: [775252.714631] usb 1-1: device descriptor read/64, error -71
Wed Jan 21 21:41:13 2026 kern.err kernel: [775252.984601] usb 1-1: device descriptor read/64, error -71
Wed Jan 21 21:41:13 2026 kern.info kernel: [775253.264584] usb 1-1: new high-speed USB device number 26 using xhci-hcd
Wed Jan 21 21:41:13 2026 kern.err kernel: [775253.414595] usb 1-1: device descriptor read/64, error -71
Wed Jan 21 21:41:13 2026 kern.err kernel: [775253.684617] usb 1-1: device descriptor read/64, error -71
Wed Jan 21 21:41:13 2026 kern.info kernel: [775253.804736] usb usb1-port1: attempt power cycle
Wed Jan 21 21:41:14 2026 kern.info kernel: [775254.274570] usb 1-1: new high-speed USB device number 27 using xhci-hcd
Wed Jan 21 21:41:14 2026 kern.warn kernel: [775254.274642] usb 1-1: Device not responding to setup address.
Wed Jan 21 21:41:14 2026 kern.warn kernel: [775254.494621] usb 1-1: Device not responding to setup address.
Wed Jan 21 21:41:14 2026 kern.err kernel: [775254.714558] usb 1-1: device not accepting address 27, error -71
Wed Jan 21 21:41:18 2026 kern.info kernel: [775257.944552] usb 1-1: new high-speed USB device number 29 using xhci-hcd
Wed Jan 21 21:41:18 2026 kern.err kernel: [775258.094580] usb 1-1: device descriptor read/64, error -71
Wed Jan 21 21:41:18 2026 kern.err kernel: [775258.364577] usb 1-1: device descriptor read/64, error -71
Wed Jan 21 21:41:18 2026 kern.info kernel: [775258.634550] usb 1-1: new high-speed USB device number 30 using xhci-hcd
Wed Jan 21 21:41:18 2026 kern.err kernel: [775258.784575] usb 1-1: device descriptor read/64, error -71
Wed Jan 21 21:41:19 2026 kern.err kernel: [775259.064562] usb 1-1: device descriptor read/64, error -71
Wed Jan 21 21:41:19 2026 kern.info kernel: [775259.184707] usb usb1-port1: attempt power cycle
Wed Jan 21 21:41:19 2026 kern.info kernel: [775259.654535] usb 1-1: new high-speed USB device number 31 using xhci-hcd
Wed Jan 21 21:41:19 2026 kern.warn kernel: [775259.654605] usb 1-1: Device not responding to setup address.
Wed Jan 21 21:41:19 2026 kern.warn kernel: [775259.874575] usb 1-1: Device not responding to setup address.
Wed Jan 21 21:41:20 2026 kern.err kernel: [775260.097450] usb 1-1: device not accepting address 31, error -71
Wed Jan 21 21:41:20 2026 kern.info kernel: [775260.244530] usb 1-1: new high-speed USB device number 32 using xhci-hcd
Wed Jan 21 21:41:20 2026 kern.warn kernel: [775260.244611] usb 1-1: Device not responding to setup address.
Wed Jan 21 21:41:20 2026 kern.warn kernel: [775260.464569] usb 1-1: Device not responding to setup address.
Wed Jan 21 21:41:20 2026 kern.err kernel: [775260.684541] usb 1-1: device not accepting address 32, error -71
Wed Jan 21 21:41:20 2026 kern.err kernel: [775260.684735] usb usb1-port1: unable to enumerate USB device

And here are the Kernel logs:

[775186.725071] usb usb1-port1: attempt power cycle
[775187.194908] usb 1-1: new high-speed USB device number 23 using xhci-hcd
[775187.194979] usb 1-1: Device not responding to setup address.
[775187.414951] usb 1-1: Device not responding to setup address.
[775187.634894] usb 1-1: device not accepting address 23, error -71
[775187.784901] usb 1-1: new high-speed USB device number 24 using xhci-hcd
[775187.784969] usb 1-1: Device not responding to setup address.
[775188.004940] usb 1-1: Device not responding to setup address.
[775188.234894] usb 1-1: device not accepting address 24, error -71
[775188.235087] usb usb1-port1: unable to enumerate USB device
[775221.789594] wlan: [0:E:ANY] ieee80211_recv_asreq: ieee80211_recv_asreq: assoc req from dms not-supported sta :40:e2:30:f4:5b:c5 
[775221.789594] 
[775221.794884] wlan: [7632:I:ANY] wlan_cfg80211_change_station: Ignore set station for ap vlan wlan0
[775252.564575] usb 1-1: new high-speed USB device number 25 using xhci-hcd
[775252.714631] usb 1-1: device descriptor read/64, error -71
[775252.984601] usb 1-1: device descriptor read/64, error -71
[775253.264584] usb 1-1: new high-speed USB device number 26 using xhci-hcd
[775253.414595] usb 1-1: device descriptor read/64, error -71
[775253.684617] usb 1-1: device descriptor read/64, error -71
[775253.804736] usb usb1-port1: attempt power cycle
[775254.274570] usb 1-1: new high-speed USB device number 27 using xhci-hcd
[775254.274642] usb 1-1: Device not responding to setup address.
[775254.494621] usb 1-1: Device not responding to setup address.
[775254.714558] usb 1-1: device not accepting address 27, error -71
[775257.944552] usb 1-1: new high-speed USB device number 29 using xhci-hcd
[775258.094580] usb 1-1: device descriptor read/64, error -71
[775258.364577] usb 1-1: device descriptor read/64, error -71
[775258.634550] usb 1-1: new high-speed USB device number 30 using xhci-hcd
[775258.784575] usb 1-1: device descriptor read/64, error -71
[775259.064562] usb 1-1: device descriptor read/64, error -71
[775259.184707] usb usb1-port1: attempt power cycle
[775259.654535] usb 1-1: new high-speed USB device number 31 using xhci-hcd
[775259.654605] usb 1-1: Device not responding to setup address.
[775259.874575] usb 1-1: Device not responding to setup address.
[775260.097450] usb 1-1: device not accepting address 31, error -71
[775260.244530] usb 1-1: new high-speed USB device number 32 using xhci-hcd
[775260.244611] usb 1-1: Device not responding to setup address.
[775260.464569] usb 1-1: Device not responding to setup address.
[775260.684541] usb 1-1: device not accepting address 32, error -71
[775260.684735] usb usb1-port1: unable to enumerate USB device
[775293.504397] usb 1-1: new high-speed USB device number 33 using xhci-hcd
[775293.654399] usb 1-1: device descriptor read/64, error -71
[775293.924505] usb 1-1: device descriptor read/64, error -71
[775294.194364] usb 1-1: new high-speed USB device number 34 using xhci-hcd
[775294.344393] usb 1-1: device descriptor read/64, error -71
[775294.614377] usb 1-1: device descriptor read/64, error -71
[775294.734593] usb usb1-port1: attempt power cycle
[775295.204363] usb 1-1: new high-speed USB device number 35 using xhci-hcd
[775295.204436] usb 1-1: Device not responding to setup address.
[775295.424436] usb 1-1: Device not responding to setup address.
[775295.644349] usb 1-1: device not accepting address 35, error -71
[775295.794348] usb 1-1: new high-speed USB device number 36 using xhci-hcd
[775295.794418] usb 1-1: Device not responding to setup address.
[775296.014426] usb 1-1: Device not responding to setup address.
[775296.234353] usb 1-1: device not accepting address 36, error -71
[775296.234558] usb usb1-port1: unable to enumerate USB device

Thanks in advance for your help!

14

Thank you for your update. We have not been able to reproduce this issue locally yet.

After the issue occurs, could you further test the following scenarios:

  1. Try using a different USB cable to see if the issue is resolved. If possible, please use a shielded cable with ferrite beads.
  2. Try disabling all 2.4 GHz bands on the Flint 3, or go to Admin Panel → Overview and switch the USB to 2.0 mode to see if this resolves the issue.
  3. Are you using the original Flint 3 power adapter, or another one that meets the 12 V / 4 A specification?
  4. If you only reboot the phone (a system-level reboot, not restarting USB tethering) without rebooting the router, does that fix the issue?
15

Hi Will, thanks for your reply.

Regarding your questions:

1- I’ve tried with different cables, it’s always the same result unfortunately. Also, these cables I use will get a good connection eventually that lasts for several days so it shouldn’t be a cable issue right? I’ve also used these cables with the beryl ax without issues as well, they’re supposed to be good quality.

2- I’ll try disabling the 2.4ghz when I can but I can say that I’ve tried to switch between usb 2.0 and 3.0 before several times, switched it back and forth to see if it would make any difference and unfortunately didn’t seem to change anything, maybe I need to reboot after each switch?

3- I’m using the original power adapter.

4- I’ve tested that many times, but when usb tethering becomes greyed out on the phone, the only thing that seems to fix it is a router reboot, not a phone reboot.

  • Some additional info: (I’m using the script you provided btw)

    • When I reboot the router, the usb tethering on the phone changes from greyed-out to active, but the first few times it connects via tethering, what happens is that it usually loses internet connectivity after a few minutes, sometimes immediately.
    • What I do to fix it, is I reconnect the usb cable over and over again until it connects reliably for more than a few minutes, and when that happens, the tethering lasts for several days (5+).
    • After a few days, if the tethering connection is lost for some reason, then the usb tethering goes back to being greyed out and the only thing that seems to fix this is a router reboot, and I have to re-start this whole process over again.
    • Keep in mind that before I added the script, I almost never could make tethering connect if I re-plugged the cable, it would only connect the first time after a router reboot. Now with the script, that doesn’t seem to happen as much. When I reboot the router, the tethering becomes active on the phone but there’s some instability in the first few connection attempts, I just keep replugging the cable until it becomes stable.
      • I’ll try to capture the full logs next time I attempt this, but just to be clear, this instability is not the same as when the usb tethering becomes completely disabled/greyed out. This instability that occurs right after a router reboot, in these circumstances, usb tethering connects just fine, I get an ip address, a gateway ip, and a dns ip via usb tethering, but after a few minutes/seconds there’s a message above the usb tethering UI saying that the internet is not acessible or something like that, and when I check the logs I typically find lots of messages like this:
      • [   94.485847] Virtual device usb0 asks to queue packet!
[   96.250846] Virtual device usb0 asks to queue packet!
[   96.250871] [send_icmp_echo 192]dev_queue_xmit failed.
[   97.290780] Virtual device usb0 asks to queue packet!
[   97.290805] [send_icmp_echo 192]dev_queue_xmit failed.
[   98.330792] Virtual device usb0 asks to queue packet!
[   98.330816] [send_icmp_echo 192]dev_queue_xmit failed.
[  100.410781] Virtual device usb0 asks to queue packet!
[  100.410808] [send_icmp_echo 192]dev_queue_xmit failed.
[  100.414804] Virtual device usb0 asks to queue packet!
[  100.420287] [send_icmp_echo 192]dev_queue_xmit failed.
[  103.638494] Virtual device usb0 asks to queue packet!
[  103.638586] Virtual device usb0 asks to queue packet!
[  103.641010] Virtual device usb0 asks to queue packet!
[  103.642674] Virtual device usb0 asks to queue packet!
[  105.610770] Virtual device usb0 asks to queue packet!
[  105.610796] [send_icmp_echo 192]dev_queue_xmit failed.
[  105.614927] Virtual device usb0 asks to queue packet!
[  105.619825] [send_icmp_echo 192]dev_queue_xmit failed.
[  106.650788] Virtual device usb0 asks to queue packet!
[  106.650814] [send_icmp_echo 192]dev_queue_xmit failed.
[  107.700785] Virtual device usb0 asks to queue packet!

  • In all of my tests, I always have repeater mode on btw, so I can see that the internet is fine, and this repeater is connected to the same phone. I’ve also tried with two separate phones just to make sure that the problem doesn’t come from having the phone with both usb tethering as well as hotspot enabled, I’ve put repeater connected to an s25 ultra, and usb tethering to s23, and the same problems occur.

Thanks for your help, as soon as I find any more clues I’ll add them here.

16

Thank you for your update.

After the issue occurs, please keep the issue present, SSH into the router, and run the following commands to check the situation and share the results with us:

opkg update && opkg install usbutils
lsusb 
ip link show usb0

Also, please export the logs and send them via private message so we can analyze them further.

How to export logs:

image
image1430×911 87 KB

How to send private messages:

image
image632×233 19.1 KB

17

Hi, I just spent around 3 hours testing this again.

I haven’t yet done the ssh thing but I’ll try to do it when I have some more time. For now I just wanted to get a repeatable pattern that you guys could use to replicate one of the bugs I’m seeing.

Some findings:

  1. To replicate the bug related to usb tethering not connecting correctly (not getting an ip address via usb tethering) all you have to do is use a Samsung S23 or S25 ultra phone, I imagine that any other recent S series Samsung phones using the latest OS version (ONEUI 8) will behave similarly:
    1. Enable developer options on the mobile phone
      1. Set Default USB configuration to “USB Tethering”.
    2. Connect phone to router via usb.
    3. Disconnect the cable on the phone end’s
    4. Wait 5 seconds
    5. Connect it again
    6. Repeat enough times until tethering stops giving you an ip address. (this usually takes between 2 to 10 tries)

So, what I found is that this seems tied to having the Default USB configuration set to “USB tethering”.

The workaround that I found is to go to the phone, change the USB connection to “CHARGE ONLY” for a second, and then switch it back to “USB tethering”. If I do that, the router works fine and gets an ip address.

Now, I don’t know if this is a bug on Samsung’s side or if there’s something you guys can do on the router side in order not to have to switch back and forth between charge mode and usb tethering to be able to establish a usb tethering connection after a disconnection.

Could you have a look please? This didn’t use to happen with Beryl AX on 4.7.4, so I imagine there’s something you can do on the router side. I’ll try it again soon on the beryl just to make sure nothing has changed on Samsung’s side that might cause this with the beryl now as well. If I find that behaviour with the beryl I’ll let you know.

There’s a couple of other bugs I’ve experienced, and when I have more information about those I’ll let you know. This information is just about the bug where the usb tethering simply never gets an ip address at all, it remains stuck in:

“Thu Feb 19 22:16:53 2026 daemon.notice netifd: tethering (8779): udhcpc: broadcasting discover
Thu Feb 19 22:16:56 2026 daemon.notice netifd: tethering (8779): udhcpc: broadcasting discover”

…and never moves from there.

Thanks for your help!

18

Sorry for the late reply—we’ve just returned from the Chinese New Year holiday.

Thank you for the update.

We’ve asked our R&D and testing teams to follow the steps you provided to see if we can reproduce the issue locally and work on a solution.