New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FS#3037 - DEVICE_CLAIM_FAILED error on GUEST interface #7795
Comments
pauljb: Confirming this happens to me too on a ZyXEL NBG6817 OpenWrt SNAPSHOT r13001-23916bca61 / LuCI Master git-20.108.52006-71e22c1 |
pauljb: This is still happening. |
gawd0wns: Confirmed still happening in r13342 on my WRT3200ACM. I got the affected guest wifi interface working by selecting the bridge interface option in LUCI, saving and applying, and then unchecking it since I did not want this enabled for the guest wifi network. |
SadButTrue: have had the same problem and solved it how gawd suggested by selecting the bridge option save&apply and deselecting save&apply... |
alonbl: Hello, Just upgraded to OpenWrt 21.02.0 r16279-5cc0535800 / LuCI openwrt-21.02 branch git-21.231.26241-422c175 Happens to me as well without "Force DHCP" option so I do not think it is related. I tried the workaround suggested by gawd and it does not work. When I manually press "restart" on the interface it fixes the issue. Does anyone has a fix or I must downgrade? Thanks! |
alonbl: I can simulate the manual restart using:
I can probably add this to startup to workaround the issue. Thanks, |
jchristensen: I am seeing the same behavior as @alon Bar-Lev with 21.02.1 on a Linksys WRT1900ac v1. Edit: I added the wifi up and wifi down commands to /etc/rc.local and rebooted several times. It works mostly but is not 100% reliable for me. Sometimes after a boot, the radio was not active. |
telia: I also get this on TP-Link Archer C20 v5 and OpenWrt 21.02.0 r16279-5cc0535800 Had to add this into startup script: sleep 15 |
telia: And also same happens on TP-Link Archer C7 v2 OpenWrt 21.02.0 r16279-5cc0535800 Interface shows in Luci as: Protocol: Static address DHCP does not provide address to clients because there is no IP assigned to the interface |
In the netifd scripts is trying to bring up the interface too quickly, so a race condition happens. This is noticeable for wireless drivers or any device that takes a few seconds longer to initialise. My repo fix - https://gitlab.com/db260179/openwrt-netifd/-/commit/c5ea57c9ec7a296a1cdafc5ca8cdc1a1a1e7990c You can add that sleep 10 in the /lib/netifd/netifd-wireless.sh on the live router. Please feedback if this fixes this issue, i can then create an upstream patch. |
THANKS (excuse my English) This fix my issue in "GL.iNet Model GL-MT300N-V2 Architecture MediaTek MT7628AN)" I added 2 additional VAP, one for WireGuard and another for OpenVPN (PBR), then assigned two Networks for this VAPs, and everytime the Rooter booted up this Networks shows the "DEVICE_CLAIM_FAILED" error. With this workaround the problem is gone for ever, i rebooted the Router for about two continous hours and never got the mentioned error. Also tweaked the Sleep value and found that a value of 7 is sufficient for my GL-MT300N-V2, but a lower value (6 or less) makes the error appears again. (A value of 10 is OK, have no problem with that.) Can you explain if the Sleep value depend on what packages i've installed or some configs etc etc ? *** My anterior workaround is to restart 'wifi' from 'local.rc' (invoke 'wifi' command alone with no parameters), but this solution is more elegant and the Wireless is up in much less time. *** |
No problem. So i've forked on my gitrepo - https://git.openwrt.org/?p=project/netifd.git;a=log;h=refs/heads/openwrt-21.02 And made changes to The The chosen sleep number (10) was set to allow a variation of time delays.
|
Would it be possible for someone to include @db260179 's fix into the master build? I also agree if there was a better wait check, it would be the best long-term solution. I had to implement this fix in order to get my wireless working. Running WRT1900ACv1 with OpenWrt 21.02.2 and have Guest WiFi set up on my 2.4 Ghz radio. Get same error as was mentioned: Error: Unknown error (DEVICE_CLAIM_FAILED) |
Can confirm the same with a WRT1200AC on 22.03.0-rc1 r19302-df622768da. |
My device: Xiaomi MiWiFi Mini The DEVICE_CLAIM_FAILED error on GUEST interface appeared for me as well after reboot, the "sleep 10" fix above didn't work in my case, instead both main and guest networks got disabled when I tried that... The /etc/rc.local fix however worked fine, since my device only has a 580 Mhz cpu I prolonged the sleep commands, I'm not sleep 30 |
Model: GL Technologies, Inc. AXT1800 I'm also experiencing this issue, but restarting the radios does not fix it by itself, I had to restart the interface too. Here's my startup script:
Timings are not optimized, you can tweak them as what will work for your device. Other useful commands Best of luck! |
same issue for me Model: TP-Link Archer C7 v5 a simple |
Same issue |
Here is my hardware and firmware configuration: I tried the sleep 10 fix, and it did not help with the problem. I then increased the time to 15 second, and the wireless interfaces guest, and lan (SSID) became disable. I tried the rc.local change (sleep 5 ; ifdown guest ; ifup guest) - no joy :-( while the sleep 10 fix may solve the issue for some hardware versions, it does not address all the routers. |
To sum my case up: The
Some interfaces fail because of the device claim failed error and that is probably the error. I got 3 radios and 4 SSIDs (for testing just 2), all are in different vlans, configured dsa. I configured that fully working, but only the first ssid gets an ip address (external dhcp). I'll try more solutions on friday, but I don't feel like flashing a sleep workaround on a bulk of devices. |
This worked best for me, hopefully it helps everybody else: |
Interestingly, I see this message in the log:
It is only visible sometimes. |
Actually that works, so I guess the problem is misconfiguration? And the log error, is fixed by #11227 |
Huge thanks for this! |
confirmed, |
lucenera:
Supply the following if possible:
{{http://forum.openwrt.org/uploads/default/original/3X/7/3/73925ccd738d985397293bca5b85f2c3f209c2a5.png}}
If you try to set the DHCP of the GUEST interface to "Force" and save and apply the change, the interface is recognized and is functioning perfectly until you restart. After reboot it doesn't work again. But the DHCP setup workaround always works.
On stable versions of OpenWrt the problem does not arise.
The text was updated successfully, but these errors were encountered: