Hello everyone,
I have made the bug reproducible by adding sleep(2) between the calls to
nl80211_create_iface and linux_br_add_if in src/drivers/driver_nl80211.c
of hostapd.
In that way, I was able to observe (without the confusing random
effects) that commit 4d0c2ad3fd268388b97af0582baa8a89
There is a race condition between hostapd and netifd.
Now that the bug is found, I could try to write a patch. But I do not
know what the correct behaviour should be.
Should netifd not add wlan0.sta1 to the bridge at all? If so, what is
the best way to implement it?
Or should hostapd be pa
Hi everyone, I think I finally located the problem!
There is a race condition between hostapd and netifd.
In hostapd, src/drivers/driver_nl80211.c, look at the function
i802_set_wds_sta. There are calls to
1) nl80211_create_iface and
2) linux_br_add_if.
Now call 1) seems to trigger netifd in
Another update:
If I issue the following commands:
1. /etc/init.d/network restart
2. ip addr
3. ip addr
4. ip addr
Then, in a "bad case", if the timing is right, 2. shows that the
interface wlan0.sta1 is DOWN, 3. shows that it is UP and 4. shows that
is DOWN again. Then it stays DOWN.
This
can you please add this function ontop of
/lib/netifd/wireless/mac80211.sh
Unfortunately, /tmp/foo is identical after good and bad boot, see below.
There are three ways to trigger the bug (randomly, yesterday I thought
the chance was about 50%, but today it felt much lower, about 5-10%):
1.
Another update:
I put some logging code into the function interface_add_link. On every
reboot the function interface_add_link is sometimes called for the
device wlan0.sta1 and sometimes not.
What I have seen is the following:
When it is not called, the connection works.
When it is called, t
Small update:
Preventing the call to mdev->hotplug_ops->add (and replacing it with
return 0) inside the function interface_add_link whenever it is called
from interface_handle_link and the string name contains the substring
".sta" seems to "fix" the bug.
What kind of hotplug_ops are called f
By the way, maybe I should add that both devices are GL.iNet GL-AR150.
Also, the configs are only minimally different from the defaults. The
only option that could be a bit unusual is having 802.11r enabled.
And indeed, after disabling 802.11r, the bug occurs much less often. In
fact, without
Can you please send me the config that you're using? I'd like to try to
reproduce it myself.
Find attached the config dumps of the AP and the client.
They have been created with 21.02, but after flashing the snapshot on
the AP I restored exactly this config (and the bug was still there).
---
Felix, I took the last openwrt snapshot and compiled netifd from master
with your patch applied and installed it.
Result:
After boot wlan0.sta1 was DOWN.
After "/etc/init.d/network restart" it was UP and the connection worked!
After another "/etc/init.d/network restart" it was DOWN again.
After
Please test if applying this change to netifd fixes the issue.
I am currently building the toolchain for the current snapshot, so I can
test on the current snapshot.
So far I have only been able to test the patch on 21.02. Since the patch
does not apply cleanly I tried to versions of the pat
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
I have investigated a bit more.
Even without the "fix", after each reboot WDS there seems to be about a
50% chance of WDS working.
To reliably reproduce the bug, it is necessary to do
/etc/init.d/network restart
with the WDS client connected.
Now what I noticed is that using the netifd versio
Hello,
I just installed 21.02 on my devices and WDS stopped working. This seems
to be the following bug:
https://bugs.openwrt.org/index.php?do=details&task_id=3961
I have ath79 and x86 devices, but all with ath9k wireless. WDS stopped
working on all of them.
Since the bug reporter already
14 matches
Mail list logo
