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 */
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
