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#3768 - AP/master + STA/client doesn't work in almost all cases #8783

Open
openwrt-bot opened this issue Apr 29, 2021 · 2 comments
Open

FS#3768 - AP/master + STA/client doesn't work in almost all cases #8783

openwrt-bot opened this issue Apr 29, 2021 · 2 comments
Labels
flyspray release/19.07

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented Apr 29, 2021

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.
@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented May 28, 2021

emusic:

I [[https://forum.openwrt.org/t/an-ugly-way-to-enable-client-ap-mode/97781|found]] that adding another (even not associated) physical network interface can greatly improve Client+AP mode stability. There is no doubt that race conditions exist in the initialization sequence. Please check the sequence to avoid such conflicts.

@ptpt52
Copy link
Contributor

@ptpt52 ptpt52 commented Feb 21, 2022

same issue here, with latest code in master

@aparcar aparcar added the release/19.07 label Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray release/19.07
Projects
None yet
Development

No branches or pull requests

3 participants