Jump to content

julianhm

Members
  • Posts

    2
  • Joined

  • Last visited

  1. Update: To get access to higher channels, I disabled the built-in AP6212 Broadcom chip, and I went with an off-the-shelf chip (RTL8188FTV which is available in module and USB-A forms). Then I just reused the included wireless FPC antenna. Install driver I forked and modified for Sunxi here: https://github.com/julianwhitehm/rtl8188ftv_Allwinner - All working ok and channels properly unlock with iw reg set AU
  2. Good day Armbian Forums! I'm having some trouble with builds of Armbian (up to and including 21.08.6 | kernel 5.10.60-sunxi) seeing wireless access points that are configured to channels 12 & 13 on my Orange Pi Zero Plus2 boards (H3 + 256mb RAM). Specifically, the default Android image (a generic Chinese-language Android multimedia system) that's loaded onto these boards can see and connect to access points that have been set to all channels (1-13) successfully, but any Armbian image I have tried fails to see anything (and subsequently cannot connect) to routers on channels 12 & 13. Due to the nature of this, I believe it may be a region setting or driver I'm missing here. Additionally, in my region (Australia) channels 12 & 13 are allowed, and routers routinely use them. With REGDOMAIN=AU set in /etc/default/crda (and system rebooted), running iw reg get reports country AU set correctly; then running iwlist wlan0 channel reports channels 1-13 are listed, which should be what we want. But then, if I run nmcli dev wifi, or iwlist wlan0 scan | grep SSID, or even use armbian-config's wifi utility, I do not see any routers set to channels 12 & 13. Manually connecting to the SSID via nmcli also fails - it just does not see any routers. Changing these routers to channel 11 and below, they appear with all three commands, and can be connected to successfully. What I have found: Wi-Fi chip is reported to be: "Broadcom BCM43438 combo and Bluetooth Low Energy" wifi (brcmfmac), 70:4A:0E:6C:0C:7C, hw, mtu 1500 If I cd to /usr/lib/firmware/brcm and run ls | grep 43438, a bcm43438-sdio.hcd file is there. Running dmesg | grep brcm command reports the following: root@orangepizeroplus2-h3:/home/julian# dmesg | grep brcm [ 8.368914] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1 [ 8.413375] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.xunlong,orangepi-zero-plus2-h3.txt failed with error -2 [ 8.413395] brcmfmac mmc1:0001:1: Falling back to sysfs fallback for: brcm/brcmfmac43430-sdio.xunlong,orangepi-zero-plus2-h3.txt [ 9.060813] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43430-sdio for chip BCM43430/1 [ 9.101374] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available [ 9.107035] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43430/1 wl0: Mar 30 2016 11:30:56 version 7.45.77.h8.4 FWID 01-ee8a6268 The above tells me that there's an issue with the driver and clm_blob [9.101374] and as such we may have limited channels available (and I'm hoping if that's the issue, it's fixable) - However, I have read elsewhere that perhaps the clm_blob is contained within the driver already and to ignore that message (telling us what we're experiencing). And, if that is case, is there a configuration file I'm missing to 'unlock' these channels? Research tells me it's either the driver or a misconfiguration. Unfortunately, due to the nature of their use (embedded applications in environments where higher channels may be required), requiring the end user to change their Wi-Fi channel is not a feasible option. Many thanks for your help!
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines