Daemon.err hostapd: 80/80+80 MHz: center segment 1 wrong or no second channel offset

Installing and Using OpenWrt Network and Wireless Configuration
1

Since a few days I've noticed a hostapd error in my log files, though I have not been able to track any specific change I might have made on the day it first occurred.

Sat Aug 13 19:07:59 2022 daemon.err hostapd: 80/80+80 MHz: center segment 1 wrong or no second channel offset

I am a bit stumped what this error is even about, as I have not been able to find any information on it anywhere (except the source code of wpa_supplicant).

2

Faced the same issue recently after I added another wifi-iface section to my device and changed the htmode of a radio. I had simply ran wifi reload to apply my config changes, after which the error started coming up in the logs.

I finally fixed it by running wifi down; wifi reconf; wifi up. I haven't looked into the exact difference between reload and reconf hence am unable to explain why that fixed it. But simply rebooting the device would also fix it, I suppose.

3

Weirdly enough, a reboot did not fix the issue for me. Setting the htmode to VHT160 via Luci and then changing it back to VHT80 did help, though. I looks a bit like some (semi-permanent) setting got corrupted on the network card?

4

Came across this issue again after I changed a few more WiFi settings.

Changing WiFi width to 80 or 20 or changing the channel did not fix it. The error was still there even when I reset all settings back to the original working configuration and rebooted.

However, completely turning off the power (unplugging the router) and then a cold boot did fix it and the error was gone.

Looks like something indeed does get corrupted in the radio on changing settings in a certain order :ghost:

1 Like
5

Looks like my previous observations were wrong, or I failed to observe something important.
On further testing, I have finally nailed down the cause of the issue.

My configuration

My router (let's call it A) on its 5GHz radio (mode: VHT80, fixed channel 36) has 2 wireless interfaces configured - AP and 802.11s mesh. This mesh interface is used to connect to another peer router (let's call it B) which only has a mesh interface on its radio (mode: VHT20, fixed channel 36).

Observations

  1. Initially both routers are turned off. Router A is turned on first, and B is turned on a few minutes later. No error is produced on router A, and both interfaces - mesh and AP work perfectly fine.
  2. Initially both routers are turned off. Now, router B is turned on first, and A is turned on a few minutes later. The above hostapd errors start appearing for the AP interface of router A.

What I observed in the logs is that on powering on the router A, the mesh interface comes up first and almost immediately connects to the router B, which is shortly followed by the AP interface coming up. I don't understand why the AP interface breaks when the mesh interface connects early.

  • If I turn off the AP interface, the hostapd errors stop appearing - so it is definitely the AP which is broken. Turning on the AP again, causes errors to show up again.
  • The errors do not appear when router A's mode is VHT20/40.
  • The errors are not purely cosmetic in nature -
    • If I attempt to use the AP interface while the errors are appearing, I notice that I am unable to connect any Android device to this AP - they all get stuck on Obtaining IP address. If I use a static IP to connect, they do associate (with full 866Mbps 80MHz bitrate) but no L3 network is accessible at all - I am not even able to ping the router.
    • Irrespective of the errors, I was able to connect 2 laptops with different Intel WiFi cards to the AP and they worked perfectly fine - obtained an IP and worked normally for several hours despite the errors in the router logs
    • When errors are not appearing (i.e. when the mesh interface connects after the AP is ready), both - Android and laptop devices work perfectly fine.
6

Interesting, as it is very similar to my own network topology.