Skip to content
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

Open
openwrt-bot opened this issue Apr 22, 2020 · 26 comments
Open

FS#3037 - DEVICE_CLAIM_FAILED error on GUEST interface #7795

openwrt-bot opened this issue Apr 22, 2020 · 26 comments
Labels

Comments

@openwrt-bot
Copy link

lucenera:

Supply the following if possible:

@openwrt-bot
Copy link
Author

@openwrt-bot
Copy link
Author

pauljb:

Confirming this happens to me too on a ZyXEL NBG6817

OpenWrt SNAPSHOT r13001-23916bca61 / LuCI Master git-20.108.52006-71e22c1

@openwrt-bot
Copy link
Author

pauljb:

This is still happening.

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

SadButTrue:

have had the same problem and solved it how gawd suggested by selecting the bridge option save&apply and deselecting save&apply...

@openwrt-bot
Copy link
Author

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.
It seems like startup order issue.

When I manually press "restart" on the interface it fixes the issue.
This is annoying as configuration is not active at startup.

Does anyone has a fix or I must downgrade?
I cannot have non-working system after every power down.

Thanks!

@openwrt-bot
Copy link
Author

alonbl:

I can simulate the manual restart using:

wifi down radio1 && wifi up radio1

I can probably add this to startup to workaround the issue.
Does anyone has a better idea of why this happens?

Thanks,

@openwrt-bot
Copy link
Author

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.

@openwrt-bot
Copy link
Author

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
wifi down radio0
sleep 1
wifi up radio0
sleep 1

@openwrt-bot
Copy link
Author

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
MAC: EA:08:6B:E8:15:30
RX: 16.21 KB (85 Pkts.)
TX: 18.88 KB (93 Pkts.)
Error: Unknown error (DEVICE_CLAIM_FAILED)

DHCP does not provide address to clients because there is no IP assigned to the interface

@db260179
Copy link
Contributor

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.

@PS4-BillGates
Copy link

PS4-BillGates commented Mar 1, 2022

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. ***

@db260179
Copy link
Contributor

db260179 commented Mar 14, 2022

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 scripts/netifd-wireless.sh- https://gitlab.com/db260179/openwrt-netifd/-/commit/c5ea57c9ec7a296a1cdafc5ca8cdc1a1a1e7990c

The scripts/netifd-wireless.sh needs to have a better checking routine on wireless driver initialisation routine, noticeable on auto channel scanning as it adds a delay that breaks the rest of uci commit routine.

The chosen sleep number (10) was set to allow a variation of time delays.
Ideally this needs to be a better wait check.

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. ***

@RyanBlakeIT
Copy link

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)

@stinerman
Copy link

Can confirm the same with a WRT1200AC on 22.03.0-rc1 r19302-df622768da.

@Bjoernnystrand
Copy link

My device: Xiaomi MiWiFi Mini
Architecture MediaTek MT7620A ver:2 eco:6
Firmware Version OpenWrt 22.03.0-rc5

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
100% sure that this was necessary but seemed to give the device the time it needed when I looked in syslog.

sleep 30
wifi down radio1
sleep 10
wifi up radio 1
sleep 3

@CharlieTheProgrammer
Copy link

Model: GL Technologies, Inc. AXT1800
Architecture: ARMv7 Processor rev 4 (v7l)
Target Platform: ipq807x/ipq60xx
Firmware Version: OpenWrt 21.02

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:

sleep 20
wifi down radio0
sleep 1
wifi up radio0
sleep 10
ubus call network.interface.[name of your interface]down
sleep 10
ubus call network.interface.[name of your interface] up

exit 0

Timings are not optimized, you can tweak them as what will work for your device.

Other useful commands
ubus list
ubus list network.interface.*
ubus -v list network.interface.lan
ubus call network.interface.wan status
https://openwrt.org/docs/techref/ubus

Best of luck!

@trietend
Copy link

trietend commented Nov 6, 2022

same issue for me

Model: TP-Link Archer C7 v5
Architecture: Qualcomm Atheros QCA956X ver 1 rev 0
Target Platform: ath79/generic
Firmware Version | OpenWrt 21.02

a simple wifi fixed the issue for me

@Bixilon
Copy link

Bixilon commented Mar 3, 2023

Same issue

@jaggergit
Copy link

Here is my hardware and firmware configuration:
Linksys WRT1900AC v1 ; ARMv7 Processor rev 2 (v7l) ; mvebu/cortexa9
Firmware: OpenWrt 22.03.2 r19803-9a599fee93 / LuCI openwrt-22.03 branch git-23.039.29681-007c243

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.

@Bixilon
Copy link

Bixilon commented Mar 6, 2023

To sum my case up:
Everything was working with a firmware built on 22-09-15 from master. I am using a Netgear Orbi SRS60.

The sleep 10 did nothing, I will try adjusting it next time, but I don't feel that this is a fix for me. I tried the following fix, it did not work for me, sometimes wifis are completely disabled, ...:

#!/bin/sh /etc/rc.common

START=99
 
start() {
    echo "Stopping wifi"
    sleep 10
    wifi down radio0
    wifi down radio1
    wifi down radio2
    echo "Wifi stopped"
    sleep 50
    wifi up radio0
    sleep 1
    wifi down radio1
    sleep 1
    wifi down radio2
    echo "All up again"
}

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.

@gpsa
Copy link

gpsa commented Mar 7, 2023

This worked best for me, hopefully it helps everybody else:

#10771 (comment)

@Bixilon
Copy link

Bixilon commented Mar 10, 2023

Interestingly, I see this message in the log:

Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145): Command failed: ubus call hostapd config_add {"iface":"wifi_secure_0", "config":"/var/run/hostapd-phy0.conf"} (Invalid argument)
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145): Usage: ubus [<options>] <command> [arguments...]
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145): Options:
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):  -s <socket>:             Set the unix domain socket to connect to
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):  -t <timeout>:            Set the timeout (in seconds) for a command to complete
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):  -S:                      Use simplified output (for scripts)
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):  -v:                      More verbose output
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):  -m <type>:               (for monitor): include a specific message type
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):                   (can be used more than once)
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):  -M <r|t>         (for monitor): only capture received or transmitted traffic
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145): Commands:
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):  - list [<path>]                  List objects
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):  - call <path> <method> [<message>]       Call an object method
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):  - subscribe <path> [<path>...]   Subscribe to object(s) notifications
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):  - listen [<path>...]                     Listen for events
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):  - send <type> [<message>]                Send an event
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):  - wait_for <object> [<object>...]        Wait for multiple objects to appear on ubus
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):  - monitor                                Monitor ubus traffic
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145):
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4145): Device setup failed: HOSTAPD_START_FAILED
Fri Mar 10 17:11:07 2023 daemon.notice netifd: Wireless device 'radio0' set retry=0
Fri Mar 10 17:11:07 2023 daemon.crit netifd: Wireless device 'radio0' setup failed, retry=0
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4314): WARNING: Variable 'data' does not exist or is not an array/object
Fri Mar 10 17:11:07 2023 daemon.notice netifd: radio0 (4314): Bug: PHY is undefined for device 'radio0'
Fri Mar 10 17:11:07 2023 daemon.notice netifd: Wireless device 'radio0' is now down

It is only visible sometimes.

@Bixilon
Copy link

Bixilon commented Mar 15, 2023

This worked best for me, hopefully it helps everybody else:

#10771 (comment)

Actually that works, so I guess the problem is misconfiguration?

And the log error, is fixed by #11227

@P1N2O
Copy link

P1N2O commented Apr 4, 2023

This worked best for me, hopefully it helps everybody else:

#10771 (comment)

Huge thanks for this!

@mupsza
Copy link

mupsza commented Nov 16, 2023

confirmed,
workaround with empty bridge
works on openWRT 23.05 on a R7800 that was configuered as dumb AP with guest network following this guide
https://openwrt.org/docs/guide-user/network/wifi/guestwifi/guestwifi_dumbap
and having the described error on reboot.
thanx for https://github.com/openwrt/openwrt/issues/10771#issuecomment-1458274460

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests