WDS stopped working in 21.02, looking for bug in netifd

Felix Fietkau nbd at nbd.name
Mon Sep 20 09:17:18 PDT 2021


On 2021-09-20 16:46, Daniel Haid wrote:
> I have continued investigating.
> 
> After all, it seems that the interface being down is just a symptom.
> 
> I summarize my current findings:
> 
> With the 21.02 netifd version, there seems to be a bug concerting WDS. 
> The bug has the following effect:
> 
> I have openwrt 21.02 running on one system running as WDS AP and another 
> one running as WDS Client. The WDS Client is running and its 
> configuration never changed.
> 
> After booting the WDS AP, there are two possibilities for in what state 
> the system can be, I call them NON-WORKING and WORKING. The probability 
> seems to be about 50% to be in one or the other state after booting.
> 
> To find out in which state I am after booting, I look for the interface 
> wlan0.sta1. If it is UP, then we are in state WORKING. If it is DOWN, 
> then we are in state NON-WORKING.
> 
> Using ping, in state WORKING, the AP can reach the Client. In state 
> NON-WORKING, the AP cannot reach the Client.
> 
> In state WORKING, the interface wlan0.sta1 can be set to DOWN and UP 
> again, and the AP can then again ping the Client, but only after waiting 
> about 4 minutes for the Client to reconnect to the AP (in my last mail, 
> I wrote that it did not work, but I just did not wait long enough).
> 
> In state NON-WORKING, I can set the interface wlan0.sta1 to UP, but this 
> will not help. The ip command will show that the interface is UP, but 
> the AP can not ping the Client, no matter how long I wait after setting 
> the state to UP.
> 
> If I turn off the Client, wait for the interface wlan0.sta1 to be 
> removed on the AP, and then restart the Client, then the interface 
> wlan0.sta1 will be created again, in state DOWN. Everything is again as 
> in the state NON-WORKING.
> 
> To reliably reach the state NON-WORKING, run "/etc/init.d/network restart".
> 
> Changing the function wireless_interface_handle_link such that it does 
> not call interface_handle_link when it is called from 
> wireless_device_hotplug_event fixes the bug.
> 
> But I do not understand what is happening.
> 
> I am not subscribed to the list; please send Cc to me.
Please test if applying this change to netifd fixes the issue.

Thanks,

- Felix

---
--- a/wireless.c
+++ b/wireless.c
@@ -328,14 +328,14 @@ static void wireless_interface_handle_link(struct wireless_interface *vif, const
 	if (!ifname)
 		ifname = vif->ifname;
 
-	if (up) {
+	if (up && ifname != vif->ifname) {
 		struct device *dev = device_get(ifname, 2);
 		if (dev) {
 			dev->wireless_isolate = vif->isolate;
 			dev->wireless_proxyarp = vif->proxyarp;
 			dev->wireless = true;
 			dev->wireless_ap = vif->ap_mode;
-			dev->bpdu_filter = dev->wireless_ap && ifname == vif->ifname;
+			dev->bpdu_filter = dev->wireless_ap;
 		}
 	}
 
@@ -793,6 +793,13 @@ wireless_interface_init_config(struct wireless_interface *vif)
 	if ((cur = tb[VIF_ATTR_NETWORK]))
 		vif->network = cur;
 
+	cur = tb[VIF_ATTR_MODE];
+	if (cur)
+		vif->ap_mode = !strcmp(blobmsg_get_string(cur), "ap");
+
+	if (!vif->ap_mode)
+		return;
+
 	cur = tb[VIF_ATTR_ISOLATE];
 	if (cur)
 		vif->isolate = blobmsg_get_bool(cur);
@@ -801,9 +808,6 @@ wireless_interface_init_config(struct wireless_interface *vif)
 	if (cur)
 		vif->proxyarp = blobmsg_get_bool(cur);
 
-	cur = tb[VIF_ATTR_MODE];
-	if (cur)
-		vif->ap_mode = !strcmp(blobmsg_get_string(cur), "ap");
 }
 
 /* vlist update call for wireless interface list */



More information about the openwrt-devel mailing list