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#3321 - wireless phy, capable of bands g and a but set as AP to band g (2.4 GHz) still doing radar scan #8181

Open
openwrt-bot opened this issue Sep 5, 2020 · 3 comments
Labels

Comments

@openwrt-bot
Copy link

wwortel:

OpenWrt SNAPSHOT, r14382+7-ad0f0df909
Ubiquiti Routerstation ar71xx with 3 pcs. PCIe 2.4/5 GHz radio
wlan0 set AP 5 GHz
wlan1,2 set as AP 2.4 GHz

from dmesg:
daemon.notice hostapd: wlan2: DFS-CAC-COMPLETED success=1 freq=5640 ht_enabled=1 chan_offset=-1 chan_width=2 cf1=5630 cf2=0
daemon.warn hostapd: current_mode != IEEE80211A
daemon.notice hostapd: wlan1: DFS-CAC-COMPLETED success=1 freq=5640 ht_enabled=1 chan_offset=-1 chan_width=2 cf1=5630 cf2=0
daemon.warn hostapd: current_mode != IEEE80211A

When set to 2.4 GHz band no radar scan on 5 GHz band should be done but apparently it is being done. As the radio circuit cannot do G and A band service at the same time
this interferes with continuous service in the 80211 G band.
No idea where this 5630 GHz frequency stems from that the log shows. wlan1 is set to channel 12 and wlan2 to channel 1. Being AP they are not supposed to scan, let alone on 5 GHz.
iwinfo:
wlan0 ESSID: "some a"
Access Point: 00:0C:42:xxxxxx
Mode: Master Channel: 128 (5.640 GHz)
Tx-Power: 18 dBm Link Quality: 70/70
Signal: -29 dBm Noise: -95 dBm
Bit Rate: 81.0 MBit/s
Encryption: WPA PSK (CCMP)
Type: nl80211 HW Mode(s): 802.11abgn
Hardware: 168C:0029 168C:4204 [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy0

wlan1 ESSID: "some b"
Access Point: 00:1B:B1:xxxxxx
Mode: Master Channel: 12 (2.467 GHz)
Tx-Power: 18 dBm Link Quality: unknown/70
Signal: unknown Noise: -95 dBm
Bit Rate: unknown
Encryption: WPA PSK (CCMP)
Type: nl80211 HW Mode(s): 802.11abgn
Hardware: 168C:0029 168C:2096 [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy1

wlan2 ESSID: "some c"
Access Point: 00:0C:42:xxxxxx
Mode: Master Channel: 1 (2.412 GHz)
Tx-Power: 16 dBm Link Quality: unknown/70
Signal: unknown Noise: -95 dBm
Bit Rate: unknown
Encryption: WPA PSK (CCMP)
Type: nl80211 HW Mode(s): 802.11abgn
Hardware: 168C:0029 168C:4204 [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy2

@thelinuxdude
Copy link

thelinuxdude commented Sep 29, 2023

We see the same thing, has anyone looked into this?

Thu Sep 28 20:22:38 2023 daemon.warn hostapd: current_mode != IEEE80211A                    
Thu Sep 28 20:22:38 2023 daemon.notice hostapd: wlan1: DFS-NOP-FINISHED freq=5280 ht_enabled=0 chan_offset=0
Thu Sep 28 20:22:38 2023 daemon.warn hostapd: current_mode != IEEE80211A                                
Thu Sep 28 20:22:38 2023 daemon.notice hostapd: wlan1: DFS-NOP-FINISHED freq=5300 ht_enabled=0 chan_offset=0
Thu Sep 28 20:22:38 2023 daemon.warn hostapd: current_mode != IEEE80211A                                    
Thu Sep 28 20:22:38 2023 daemon.notice hostapd: wlan1: DFS-NOP-FINISHED freq=5320 ht_enabled=0 chan_offset=0
Thu Sep 28 20:22:38 2023 daemon.warn hostapd: current_mode != IEEE80211A  ```



The problem for use is the mt7615 has to radios one is being used to STA to 5GHz and the other is 2.4 AP, the wlan1 is the 2.4 AP and it executes the section above and all our stations from the from 2.4 AP.  It requires a `wifi up radio0` (radio0 is our 2.4). to recover.

@thelinuxdude
Copy link

Also it appears it is trying to be addressed here but unsure if it handles the case when not using 5GHz and only 2.4 AP. https://patches.linaro.org/project/linux-wireless/patch/54c9a89210608d2a9b9adf37a8c2a743275e5723.1630081048.git.chad@monroe.io/

@thelinuxdude
Copy link

@nbd168 @ryderlee1110 I know this is old, but do either of you recall if this situation has been fixed in the driver for the mt7615?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants