IoT interface (QCA9887) won't work as a mesh point - after configuring I get this in logs:
Thu Oct 5 21:36:44 2023 kern.warn kernel: [248017.124210] ath10k_pci 0001:01:00.0: pdev param 0 not supported by firmware
Thu Oct 5 21:36:44 2023 kern.warn kernel: [248017.128868] ath10k_pci 0001:01:00.0: must load driver with rawmode=1 to add mesh interfaces
Thu Oct 5 21:36:44 2023 daemon.err wpa_supplicant[19100]: Could not set interface m-11s-1 flags (UP): Invalid argument
Thu Oct 5 21:36:44 2023 daemon.err wpa_supplicant[19100]: nl80211: Could not set interface 'm-11s-1' UP
Thu Oct 5 21:36:44 2023 daemon.notice wpa_supplicant[19100]: nl80211: deinit ifname=m-11s-1 disabled_11b_rates=0
Upper band ax device won't start in 160MHz mode with logs reporting something like:
Thu Oct 5 21:39:40 2023 daemon.err hostapd: ACS: Failed to compute ideal channel
Thu Oct 5 21:39:40 2023 daemon.err hostapd: Interface initialization failed
Thu Oct 5 21:39:40 2023 daemon.notice hostapd: phy1-ap0: interface state ACS->DISABLED
Thu Oct 5 21:39:40 2023 daemon.notice hostapd: phy1-ap0: AP-DISABLED
Thu Oct 5 21:39:40 2023 daemon.err hostapd: ACS: Possibly channel configuration is invalid, please report this along with your config file.
Thu Oct 5 21:39:40 2023 daemon.err hostapd: ACS: Failed to start
Are these a known issue? Any workarounds? Should I report these bugs?
You can get telnet & SSH access on the international FW, the problem with the international versions is you need the UART to successfully flash OpenWRT. If you can get hold of a 1.8V UART adapter then further up this thread there's a post describing how to connect to the router UART via sewing needles or similar fed through the grill under the router, so no need to open the router.
Have you tried adding mentioned parameter to /etc/modules.d/ath10-ct ?
If you are getting error on the driver level than wpa supplicant won't work
Yes I am unable to get 160Mhz either - apparently it is the hostapd bug? and some people hacked it by providing their own patches enabling 160Mhz for hardcoded frequency - it supposedly worked for them?... If you are interested check messages in that very thread
Of course!) It needs a proper support from the firmware side: ath10k_pci 0001:01:00.0: rawmode = 1 requires support from firmware
Yep, I've seen it. I think there was a series of posts from @scr4tchy. But it looks like the issue has been solved and worked fine in rc3 (at least according to the post). The question is - will this patchset ever be merged upstream? Maintaining manually hostapd fork feels like pain)
Have you tried using different firmware? Technically there are 3 firmware you could try:
ath10k-firmware-qca9887
ath10k-firmware-qca9887-ct (I believe this firmware was in the default image)
ath10k-firmware-qca9887-ct-full-htt
The initial patch in its original form, with hardcoded frequency - 0% chance to be merged
I agree, maintaining hostapd buillds on my own is probably not worth it, especially with the 160MHz working on lower 5G band
I think I found the problem. radio1 reports that it's 160MHz capable, while in reality - it's not. It has not enough channels available to span the 160MHz network.
So, the new question is - these channels: 169, 173 and 177 are forbidden in China and at least in my chinese AX9000, so is the same true for international version? And if not, is it possible to unlock these 3 channels? It really makes a huge difference here where I live.
You might be right ... It seems not enough channels for anything more than 80Mhz (80+80 or 160)
I'm not sure but it seems to be controlled from the BDF, and used WiFi country activates channels and related settings like max transmission power.
Unfortunately that's something that Qualcomm can only change ... despite us raising it with them that embedded regdb in the BDF is far from perfect.
Robi Marko suggested to QCM that external regdb could be used for ath11k (QCM did something like that for ath12k drivers to allow loading external file with all these information), but it is not a priority for them unfortunately to do it for ath11k https://bugzilla.kernel.org/show_bug.cgi?id=216832
Hi all,
I keep bothering around with two AX9000 for a few months now and I'm unable to put them into "production" mainly due to the reason that it seems that 802.1q is not working reliable for me. Sometimes it works for some time but then suddenly stops. I thought it was due to DHCPACC packets not being forwarded to the new switch port after I was connected with the same client to other APs (2 openwrt on Netgear R7800) in the network. But it is unreleated to DHCP... even if I use static IP configuration it is not working. The AP is able to communicate but not the connected clients. If it is a mac ageing problem on the switch then I wonder why it works with the other openwrt APs. The regdb is annoying, too, because of regional restrictions I'm not allowed to use any channel above 140.
Has anybody got a working configuration using 802.1q VLANs?
Would you share the config by chance? The examples in the thread you linked are for roaming between two APs rather than band steering. AP roaming works fine without that service.When I try the config from the thread it does not seem to be able to connect to the other AP because I'm not able to change the network setting - as soon as I change "lan" to "homenet.10" because his is the correct network device it gives me parsing errors. But as I said, roaming between the APs is working good enough.
When I read through your post it seems that the 2.4ghz and 5ghz SSID need to be identical. Is this correct?
ĂČk, got it. If I specify more than 1 SSID it means that steering will happen on these two SSIDs separately.
Anyways, would you share what you changed in the config file to make band steering within a SSID from 2.4 ghz to 5 ghz possible, please?
config usteer
# The network interface for inter-AP communication
option 'network' 'lan'
# Log messages to syslog (0/1)
option 'syslog' '1'
# Disable network communication (0/1)
option local_mode '0'
# Use IPv6 for remote exchange
option 'ipv6' '0'
# Minimum level of logged messages
# 0 = fatal
# 1 = info
# 2 = verbose
# 3 = some debug messages
# 4 = network packet information
# 5 = all debug messages
option 'debug_level' '5'
# Maximum number of neighbor reports set for a node
#option max_neighbor_reports 8
# Maximum amount of time (ms) a station may be blocked due to policy decisions
#option sta_block_timeout 30000
# Maximum amount of time (ms) a local unconnected station is tracked
#option local_sta_timeout 120000
# Maximum amount of time (ms) a measurement report is stored
option measurement_report_timeout 1000
# Local station information update interval (ms)
#option local_sta_update 1000
# Maximum number of consecutive times a station may be blocked by policy
option max_retry_band 0
# Maximum idle time of a station entry (ms) to be considered for policy decisions
#option seen_policy_timeout 30000
# Minimum number of stations delta between APs before load balancing policy is active
#option load_balancing_threshold 0
# Minimum number of stations delta between bands before band steering policy is active
option band_steering_threshold 0
# Interval (ms) between sending state updates to other APs
option remote_update_interval 1000
# Number of remote update intervals after which a remote-node is deleted
#option remote_node_timeout 10
# Allow rejecting assoc requests for steering purposes (0/1)
#option assoc_steering 0
# Allow ignoring probe requests for steering purposes (0/1)
#option probe_steering 0
# Minimum signal-to-noise ratio or signal level (dBm) to allow connections
#option min_connect_snr 0
# Minimum signal-to-noise ratio or signal level (dBm) to remain connected
#option min_snr 0
# Timeout after which a station with snr < min_snr will be kicked
#option min_snr_kick_delay 5000
# Timeout (ms) for which a client will not be steered after rejecting a BSS-transition-request
#option steer_reject_timeout 60000
# Timeout (in ms) after which a association following a disassociation is not seen
# as a roam
#option roam_process_timeout 5000
# Minimum signal-to-noise ratio or signal level (dBm) before attempting to trigger
# client scans for roaming
#option roam_scan_snr 0
option roam_scan_snr -55
# Maximum number of client roaming scan trigger attempts
#option roam_scan_tries 3
option roam_scan_tries 1
# Retry scanning when roam_scan_tries is exceeded after this timeout (in ms)
# In case this option is set to 0, the client is kicked instead
#option roam_scan_timeout 0
# Minimum time (ms) between client roaming scan trigger attempts
#option roam_scan_interval 10000
option roam_scan_interval 0
# Minimum signal-to-noise ratio or signal level (dBm) before attempting to trigger
# forced client roaming
#option roam_trigger_snr 40
# Minimum time (ms) between client roaming trigger attempts
#option roam_trigger_interval 60000
# Timeout (ms) for client roam requests. usteer will kick the client after this times out.
#option roam_kick_delay 10000
# Minimum signal strength difference until AP steering policy is active
#option signal_diff_threshold 0
option signal_diff_threshold 5
# Initial delay (ms) before responding to probe requests (to allow other APs to see packets as well)
#option initial_connect_delay 0
# Enable kicking client on excessive channel load (0/1)
#option load_kick_enabled 0
# Minimum channel load (%) before kicking clients
#option load_kick_threshold 75
# Minimum amount of time (ms) that channel load is above threshold before starting to kick clients
#option load_kick_delay 10000
# Minimum number of connected clients before kicking based on channel load
#option load_kick_min_clients 10
# Reason code on client kick based on channel load (default: WLAN_REASON_DISASSOC_AP_BUSY)
#option load_kick_reason_code 5
# Attempting to steer clients to a higher frequency-band every n ms.
# A value of 0 disabled band-steering.
#option band_steering_interval 120000
# Minimal SNR or absolute signal a device has to maintain over band_steering_interval to be
# steered to a higher frequency band
#option band_steering_min_snr -60
option band_steering_min_snr -15
# Interval (ms) the device is sent a link-measurement request to help assess
# the bi-directional link quality. Setting the interval to 0 disables link-measurements.
#option link_measurement_interval 30000
option link_measurement_interval 0
# Script to run after bringing up a node
#option node_up_script ''
# Message types to include in log
# Available types:
# - probe_req_accept
# - probe_req_deny
# - auth_req_accept
# - auth_req_deny
# - assoc_req_accept
# - assoc_req_deny
# - load_kick_trigger
# - load_kick_reset
# - load_kick_min_clients
# - load_kick_no_client
# - load_kick_client
# - signal_kick
#list event_log_types ''
# List of SSIDs to enable steering on
list ssid_list 'My Single SSID'
I have another (probably dumb) question. How do I build for our target?
I want to build a kernel module so I think it is necessary to have the correct board set.
What I've tried to do:
Downloaded a docker image from dockerhub: openwrt/sdk:ipq807x-generic-v23.05.0
(I also discovered it tracks 23.05 branch instead of tag, but I think it's okay)
Inside the container I ran ./scripts/feeds update -a - this downloaded everything correctly.
Now I want to set the correct target board. But make menuconfig has no options for target switch. If I run make defconfig and then look inside, the resulting .config file by default targets bcm27xx: CONFIG_DEFAULT_TARGET_bcm27xx_bcm2710=y and CONFIG_TARGET_BOARD=bcm27xx. The question is - how do I change it without menuconfig? Do we have some defconfig for our board to replace this one?
Of course leaving everything "as is" and just compiling the kmod will result in a package that I'm unable to install (and I think that's the good thing)
