Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#3766 - AP+STA (master+client) doesn't work in most cases #8781

Closed
openwrt-bot opened this issue Apr 29, 2021 · 1 comment
Closed

FS#3766 - AP+STA (master+client) doesn't work in most cases #8781

openwrt-bot opened this issue Apr 29, 2021 · 1 comment
Labels
flyspray release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release

Comments

@openwrt-bot
Copy link

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:

  • 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.
@aparcar aparcar added the release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release label Feb 22, 2022
@981213
Copy link
Member

981213 commented Mar 7, 2022

Duplicated with #8783

@981213 981213 closed this as completed Mar 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray release/19.07 pull request/issue targeted (also) for OpenWrt 19.07 release
Projects
None yet
Development

No branches or pull requests

3 participants