[FS#3421] netifd: tries to claim VAP device before it's created (Attachment added)

[OpenWrt Bugs]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened.  Details are below. 

User who did this - Marcin Jurkowski (marcin1j) 

Attached to Project - OpenWrt/LEDE Project
Summary - netifd: tries to claim VAP device before it's created
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Medium
Priority - Very Low
Reported Version - Trunk
Due in Version - Undecided
Due Date - Undecided
Details - This is obviously a general issue but the problem was reported on Netgear RT6220. There are two 5 GHz (radio1, non-DFS channel) VAPs and five VAPs in total. Netifd debug log is attached.

When netifd tries to claim second 5 GHz VAP (wl1-gst) it fails with error message:

device_claim(447): claim Network device wl1-gst failed: -1


It seems that the second VAP had not been (yet) created by hostapd when netifd tried to claim it as if it lacked a proper synchronization with hostapd.

As a result:

  * wl1-gst device is never added as bridge member,
  * it permanently stays in "down" state:

# ubus call network.device status '{ "name": "wl1-gst" }'
{
	"external": true,
	"present": true,
	"type": "Network device",
	"up": false,
	"carrier": true,
	"statistics": {
                ...
	}
}

  * the second 5 GHz VAP is pretty much useless.

There's no easy way to workaround this since each wifi reload command triggers the same routine.

Is it possible to fix netifd without a major rewrite? It seems that to consider each VAP ready as soon as hostapd is started, which is obviously not the case.

The problem was originally reported in FS#2698 but the workaround in https://github.com/openwrt/openwrt/pull/2848 treats only some symptoms. The root cause is still unaddressed.




 

One or more files have been attached.

More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=3421

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.