You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have GL-Inet GL-AR150 (Atheros 933x, single radio) configured with three WiFi interfaces/networks: two APs (main+guest) and one client (WWAN). I would like to use them as a wireless repeater, but in most cases is able to use as pure AP or pure client only.
If client interface is disabled, both APs work perfectly. If the client is enabled, it successfully connects to the specified external AP and routing between LAN and WWAN works perfectly, but none of the APs are visible/accessible in most cases.
There was only a single case of dozens experiments when I saw all three interfaces working. In that case, both APs were visible and accessible, the client was connected to the external AP, and packet routing was established between LAN (RJ-45 and APs) and WWAN (the client). It means that this SoC is technically capable of running mixed mode interfaces on a single radio. Unfortunately, in that case I didn't think to save the logs.
In most cases, when AP networks are not exposed, system log contains repeated error messages from hostapd:
daemon.err hostapd: Failed to set beacon parameters
daemon.notice hostapd: handle_probe_req: send failed
I'm afraid that client initialization is performed first, and some beacon parameters are set for the radio driver. When hostapd tries to set its own parameters, the driver fails the request. But in the case where all three interfaces worked, initialization sequence most probably was slightly different, so there was no conflict. Unfortunately, I cannot reproduce that successful case, but at that time, I carefully checked all the functionality to ensure that it really worked as expected.
I tried to change AP channel from Auto to a particular number, as suggested in [[https://bugs.openwrt.org/index.php?do=details&task_id=3114|FS#3114]], but this didn't help.
The problem occurs in many stable OpenWRT releases. The latest are 19.07.3 and 19.07.7 (both are generic).
Steps to reproduce:
Create at least two wireless interfaces: one client/STA, one or more master/AP.
When client/STA is enabled, AP(s) is(are) not exposed.
The text was updated successfully, but these errors were encountered:
emusic:
I have GL-Inet GL-AR150 (Atheros 933x, single radio) configured with three WiFi interfaces/networks: two APs (main+guest) and one client (WWAN). I would like to use them as a wireless repeater, but in most cases is able to use as pure AP or pure client only.
If client interface is disabled, both APs work perfectly. If the client is enabled, it successfully connects to the specified external AP and routing between LAN and WWAN works perfectly, but none of the APs are visible/accessible in most cases.
There was only a single case of dozens experiments when I saw all three interfaces working. In that case, both APs were visible and accessible, the client was connected to the external AP, and packet routing was established between LAN (RJ-45 and APs) and WWAN (the client). It means that this SoC is technically capable of running mixed mode interfaces on a single radio. Unfortunately, in that case I didn't think to save the logs.
In most cases, when AP networks are not exposed, system log contains repeated error messages from hostapd:
daemon.err hostapd: Failed to set beacon parameters
daemon.notice hostapd: handle_probe_req: send failed
I'm afraid that client initialization is performed first, and some beacon parameters are set for the radio driver. When hostapd tries to set its own parameters, the driver fails the request. But in the case where all three interfaces worked, initialization sequence most probably was slightly different, so there was no conflict. Unfortunately, I cannot reproduce that successful case, but at that time, I carefully checked all the functionality to ensure that it really worked as expected.
I tried to change AP channel from Auto to a particular number, as suggested in [[https://bugs.openwrt.org/index.php?do=details&task_id=3114|FS#3114]], but this didn't help.
The problem occurs in many stable OpenWRT releases. The latest are 19.07.3 and 19.07.7 (both are generic).
Steps to reproduce:
The text was updated successfully, but these errors were encountered: