[FS#3768] AP/master + STA/client doesn't work in almost all cases
OpenWrt Bugs
openwrt-bugs at lists.openwrt.org
Thu Apr 29 20:22:54 BST 2021
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Eugene Muzychenko (emusic)
Attached to Project - OpenWrt/LEDE Project
Summary - AP/master + STA/client doesn't work in almost all cases
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Low
Priority - Very Low
Reported Version - openwrt-19.07
Due in Version - Undecided
Due Date - Undecided
Details - 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.
More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=3768
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.
More information about the openwrt-bugs
mailing list