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 · 16 comments
Open

FS#3037 - DEVICE_CLAIM_FAILED error on GUEST interface #7795

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

Comments

@openwrt-bot
Copy link

openwrt-bot commented Apr 22, 2020

lucenera:

Supply the following if possible:

@openwrt-bot
Copy link
Author

openwrt-bot commented Apr 22, 2020

@openwrt-bot
Copy link
Author

openwrt-bot commented May 13, 2020

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

openwrt-bot commented Sep 2, 2020

pauljb:

This is still happening.

@openwrt-bot
Copy link
Author

openwrt-bot commented Nov 2, 2020

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

openwrt-bot commented Nov 6, 2020

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

openwrt-bot commented Sep 11, 2021

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

openwrt-bot commented Sep 12, 2021

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

openwrt-bot commented Nov 11, 2021

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

openwrt-bot commented Dec 20, 2021

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

openwrt-bot commented Dec 21, 2021

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

db260179 commented Feb 22, 2022

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

RyanBlakeIT commented Mar 27, 2022

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

stinerman commented Jun 11, 2022

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

@Bjoernnystrand
Copy link

Bjoernnystrand commented Jul 24, 2022

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

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

6 participants