I compiled the openwrt firmware myself.Today, I found out that wifi didn't work when the system first started.
Logread has the following exception information:
Fri Mar 1 06:29:48 2019 daemon.err hostapd: Failed to set beacon parameters
Fri Mar 1 06:29:48 2019 daemon.notice hostapd: wlan0: INTERFACE-DISABLED
Fri Mar 1 06:29:48 2019 daemon.notice hostapd: wlan0: INTERFACE-ENABLED
Fri Mar 1 06:29:48 2019 daemon.err hostapd: Failed to set beacon parameters
Fri Mar 1 06:29:48 2019 daemon.notice hostapd: wlan0: INTERFACE-DISABLED
Fri Mar 1 06:29:51 2019 daemon.err hostapd: Failed to set beacon parameters
Fri Mar 1 06:29:51 2019 daemon.err hostapd: Configuration file: /var/run/hostapd-phy0.conf
Fri Mar 1 06:29:51 2019 daemon.err hostapd: nl80211: Could not configure driver mode
Fri Mar 1 06:29:51 2019 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Fri Mar 1 06:29:51 2019 daemon.err hostapd: nl80211 driver initialization failed.
Fri Mar 1 06:29:51 2019 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->DISABLED
Fri Mar 1 06:29:51 2019 daemon.notice hostapd: wlan0: AP-DISABLED
Fri Mar 1 06:29:51 2019 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Fri Mar 1 06:29:51 2019 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started
Fri Mar 1 06:29:53 2019 daemon.notice hostapd: wlan0: interface state ENABLED->DISABLED
Fri Mar 1 06:29:53 2019 daemon.notice hostapd: wlan0: AP-DISABLED
Fri Mar 1 06:29:53 2019 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Fri Mar 1 06:29:53 2019 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Fri Mar 1 06:29:53 2019 daemon.notice hostapd: nl80211: Failed to remove interface wlan0 from bridge br-lan: Invalid argumen
At first, I thought there was something wrong with my parameter configuration, but after I run wifi reload, wifi worked normally, which proved that my parameters could be set normally.
My system information is follows:
At first, I thought there was something wrong with my parameter configuration, but after I run wifi reload, wifi worked normally, which proved that my parameters could be set normally.
Me too. I think this might be a bug in OpenWrt 18.06.x.
I'm running 18.06.2 and I experienced the same thing. I changed the config, reloaded the wifi and it worked.
Thanks for your replay.
I think this phenomenon is probabilistic, and it is only probabilistic in the first boot, after the work has been very stable,so I do not think it is a problem of parameter configuration.
I had originally posted this as a possible cause, but then removed it when I read that you were able to start wireless without rebooting. It still doesn't seem to fit the information, but perhaps worth a quick check or at least awareness.
ART-resident cal data is copied to the OpenWrt filesystem by /etc/hotplug.d/firmware/11-ath10k-caldata or similar. In my experience, it is tens or hundreds of milliseconds late for the ath driver to use for loading into the chips. This is not obvious once the system has booted, as the files are present and have a timestamp shown in ls -l that appears to be as early as anything else.
The timing problem can be roughly measured by adding logging statements to 11-ath10k-caldata with /proc/uptime available for since-boot time to correspond with the kernel messages. It is generally evident in the driver-initialize messages for the wireless drivers, with a first-boot set of messages failing on the multiple options for files that the driver tries, but later boots having a shorter list of "Error: -2" lines (file not found).
There have been some recent patches on master that speed this copy of ART data, which it does dramatically. However, at least on the IPQ4019 device I'm working with right now, it is still "too late" for the first boot. See the developer mailing list and, for example
commit a69e101ed1169f562fc030a783cd997d3f066b16
Author: Christian Lamparter <redacted>
Date: Thu Feb 14 19:06:47 2019 +0100
ipq40xx: speed up ath10k-caldata extraction
Reading and writing to and from flash storage is slow and currently,
the ath10kcal_extract() scripts are even more at an disadvantage
because they use a block size of 1 to be able skip.
This patch reworks the extraction scripts to be much faster and
efficient by reading and writing the calibration data in possibly
one big block.
However, as I believe initialization of the wireless chips is only done once per boot, if that is true, it would seem that wifi reload wouldn't change things.