Forums

Resolved
0 votes
Apologies if this is a dumb question but why is Clearos 7 still running on kernel version 3.10? My current kernel is 3.10.0-1127.19.1, my system is set to update automatically and I can't find anything to suggest Clearos uses anything newer. I realise that Centos isn't the quickest distro to apply updates, but 3.10 came out in 2013 - even if it's under LTS there must be a lot of new features missing, including in the INFOSEC field.

My specific problem is that I'm trying to install a Qualcomm Atheros QCA9984 802.11ac wireless module (Compex WLE1216VX) in our firewall / wireless AP. This uses the ath10k drivers. According to the Linux Wireless wiki this uses firmware ver. 10.4, which requires kernel version 4.2 or above. Package linux-firmware-20191203-76.gite8a0f4c.el7.noarch provides this, including a folder specifically for QCA9984, but it fails to load - this is the error message I get:
Nov 12 13:24:58 gateway.wasielewski kernel: ath10k_pci 0000:06:00.0: irq 49 for MSI/MSI-X
Nov 12 13:24:58 gateway.wasielewski kernel: ath10k_pci 0000:06:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
Nov 12 13:24:58 gateway.wasielewski kernel: ath10k_pci 0000:06:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe
Nov 12 13:24:58 gateway.wasielewski kernel: ath10k_pci 0000:06:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 0 testmode 0
Nov 12 13:24:58 gateway.wasielewski kernel: ath10k_pci 0000:06:00.0: firmware ver 10.4-3.9.0.2-00046 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast crc32 a09d5bfe
Nov 12 13:25:00 gateway.wasielewski kernel: ath10k_pci 0000:06:00.0: failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=11 from ath10k/QCA9984/hw1.0/board-2.bin
Nov 12 13:25:00 gateway.wasielewski kernel: ath10k_pci 0000:06:00.0: failed to fetch board-2.bin or board.bin from ath10k/QCA9984/hw1.0
Nov 12 13:25:00 gateway.wasielewski kernel: ath10k_pci 0000:06:00.0: failed to fetch board file: -2
Nov 12 13:25:00 gateway.wasielewski kernel: ath10k_pci 0000:06:00.0: could not probe fw (-2)
I can't find much online relating to these errors, but as the firmware ver. no. is the current one and the package is recent (file datestamp 1 April 2020) I'm guessing it can't load because of the kernel version mismatch.

The wireless wiki refers to a backports project, but the site hosting the code for that appears to be dead, and in any case that would be very much a second best solution. Of course if I'm missing something blindingly obvious please let me know.

Thanks,
Andrew
Thursday, November 12 2020, 02:13 PM
Share this post:
Responses (14)
  • Accepted Answer

    Wednesday, January 06 2021, 09:01 PM - #Permalink
    Resolved
    0 votes
    I set up ELRepo and installed the kernel-ml-headers and kernel-ml-devel packages, but these look to be the same as with the Centos .el7 source packages - in fact the only *.c files I can find in the entire source tree are under the ./scripts directory. The situation is the same with the Fedora kernel-headers and kernel-devel packages, which as far as the file structure and build system are concerned are pretty much the same.

    When I was testing I downloaded the ath source tree alongside the Fedora one and tried using symlinks to connect to the ath10k source, as all I really needed to do was build the ath10k kernel modules. However this didn't work - there seemed to be significant differences between the two structures as to where file dependencies were located. I can't find any posts online relating to this, which seems odd as it can't be an uncommon requirement. I'll try posting in some more generic Linux forums.
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, January 06 2021, 10:17 AM - #Permalink
    Resolved
    0 votes
    I can't answer that. There is no such thing as a ClearOS kernel any more. We use the one provided directly by upstream Centos and I think they use the one provided by RedHat.

    Have you looked at the ElRepo kernels?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, January 06 2021, 10:13 AM - #Permalink
    Resolved
    0 votes
    I see those *.h files, but there are no *.c files in the /usr/lib/modules/3.10.0-1127.19.1.el7.x86_64/kernel/drivers/net/wireless/ath/ath10k directory - or anything else apart from Kconfig and Makefile. Same also for the parent directory, which holds generic code common across Atheros chipsets.

    Is there any issue about this being "non-free" software due to dependency on proprietary firmware which isn't under GPL?
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, January 06 2021, 09:45 AM - #Permalink
    Resolved
    0 votes
    Extract from "locate ath10k":
    /usr/src/kernels/3.10.0-1127.19.1.el7.x86_64/drivers/net/wireless/ath/ath10k
    /usr/src/kernels/3.10.0-1127.19.1.el7.x86_64/drivers/net/wireless/ath/ath10k/Kconfig
    /usr/src/kernels/3.10.0-1127.19.1.el7.x86_64/drivers/net/wireless/ath/ath10k/Makefile
    /usr/src/kernels/3.10.0-1127.19.1.el7.x86_64/include/config/ath10k
    /usr/src/kernels/3.10.0-1127.19.1.el7.x86_64/include/config/ath10k.h
    /usr/src/kernels/3.10.0-1127.19.1.el7.x86_64/include/config/ath10k/debugfs.h
    /usr/src/kernels/3.10.0-1127.19.1.el7.x86_64/include/config/ath10k/pci.h
    There are some .h files. Are they not what you wanted? They are supplied by kernel-devel.
    The reply is currently minimized Show
  • Accepted Answer

    Monday, January 04 2021, 11:27 PM - #Permalink
    Resolved
    0 votes
    I've made a fair bit of progress which I'll summarise here. Some of this is about Atheros h/w and 5GHz in general rather than my specific module, but hopefully it may prove useful to someone. This should also be flagged under something like wireless LAN rather than kernel (though custom kernel modules are involved).

    Some general observations

    • Due to the more complex regulatory requirements only Atheros chipsets (ath9k and ath10k) properly support AP mode on Linux, and even that isn't straightforward.
    • The definitive source of info is the official Linux Wireless wiki. At least as far as Qualcom Atheros is concerned the maintainer is Kalle Valo, who AFAIK is a Qualcom employee - so when people complain that info and downloads aren't available from Qualcom or device vendors, pretty much everything that is publicly available is here. Unfortunately there isn't a discussion forum on the wiki, or any other forum I can find dedicated to Linux wireless.
    • The firmware linked to from the wiki is the official Qualcom firmware, which eventually makes it's way into the main Linux tree.
    • Ben Greear at Candela Technologies (CT) has an NDA with Qualcom and has customised versions of the firmware. He also has custom kernels that take advantage of the additional functionality; however this is all oriented very much to OpenWrt. Ben does this largely pro bono though he has a Kickstarter donations page - I am going to make a donation as I couldn't have sorted this without resources from his website and github.
    • Even dual-mode wireless modules will only support one band at a time. The (very) few that operate in both bands simultaneously simply have two radios on a single card. Simultaneous (as opposed to selectable) dual-mode routers and APs have two wireless modules.


    WLE1216VX-specific setup

    • I found CT custom firmware for the WLE1216VX on a Dropbox page by following a thread from Ben Greear's github Issues page; however it doesn't appear to be contained in the main CT firmware page. With this firmware the standard ath10k drivers (ath10k_core and ath10k_pci) load successfully and a wireless device is created. I tested this on a Fedora 5.9.10 kernel (as well as the custom kernel mentioned below); not tried with the ClearOS / Centos kernel but no reason to expect it won't work on any reasonably current kernel. See attached ZIP file.
    • There is a patch to select frequency band. The default is 5GHz. To select band modprobe ath10k_core with the appropriate parameter: ath10k_core dual_band=2|5. iw list only shows functionality for the current selected band; to switch you have to reload the driver. Presumably driver and firmware support will improve in future and eventually move into the kernel mainline. As I am only interested in using the module for 5GHz 802.11ac this isn't a problem. (The original OpenWrt patch is also in the Dropbox ZIP file + version cleaned up for Linux attached.)
    • The EEPROM has the regulatory domain set to 0x0 (i.e. United States). A kernel commit made about a year ago to the ath module means that if this value or 0x8000 is found, the regulatory domain is set to 0x64 (WOR4_WORLD) which is the most restrictive possible. All 5GHz channels either have the passive scan flag set ("No IR") or else are disabled, which means AP functionality is impossible regardless of the h/w capabilities. From what I can see in mailing list discussions this outcome was unintentional and there is a request to have it reverted. In the meantime the 402-ath_regd_optional.patch (attached) allows this to be overridden and the regulatory domain is taken from iw reg get. This likely also affects other h/w using ath9k and ath10k.
    With all of the above in place the ath10k driver and firmware is loaded, the wireless device is created, and 5GHz channels appropriate to the regulatory domain are shown in iw list. ACS works straightaway. However to use DFS it's necessary to compile the module with the CONFIG_CFG80211_CERTIFICATION_ONUS and CONFIG_ATH10K_DFS_CERTIFIED options selected. This is in standard kernel source code (no patch required) but isn't compiled as standard - the idea seems to be that by selecting these options you are pledging that your h/w implements DFS correctly and that you will follow The Rules. I think this issue must apply to all DFS-capable 5GHz h/w, not just this particular product or Atheros chipsets.

    Once I had done all of the above 802.11ac functionality works pretty much out of the box - much more easily than I expected. ACS (with or without DFS) works seamlessly, and I can get DFS working with 80 MHz or 160 MHz channel width (vht_oper_chwidth=1 or 2) though not 80+80 MHz (vht_oper_chwidth=3). One issue I was anticipating was automating config reload following a radar detection event. However I haven't seen this at all yet, although as we live in SW London about midway between LHR and LGW airports I was expecting it to be a frequent occurrence. Mostly hostapd starts on channel 100 (5500 MHz) and stays there, though occasionally on channel 36 (lowest in 5 GHz band); I don't know if this is because of radar or because the channel scan algorithm simply selects that as best. There are only one or two 5 GHz APs in range, so hard to tell.

    This has all been done on a x86_64 test rig on Fedora 33. One issue with building kernel modules on ClearOS / Centos is that while I have installed kernel-devel and kernel-headers packages, the Atheros wireless drivers branch doesn't contain any *.h or *.c files though it does have Kconfig and Makefile. Are there other packages needed for these? (I downloaded the entire kernel source tree from the Linux wireless wiki and built a custom kernel; I don't think there is anything in the latest version that is necessary, but it was the only way I could build the modules and it does ensure all recent changes are included.)

    I'm getting additional antenna h/w so I can install the WLE1216VX in the ClearOS system in parallel with the 2.4 GHz module - once I have the kernel module source sorted. I'll carry on tuning the 802.11ac settings once that is all stable.

    Happy New Year!
    Andrew
    The reply is currently minimized Show
  • Accepted Answer

    Monday, January 04 2021, 11:24 PM - #Permalink
    Resolved
    0 votes
    Duplicate post - to be deleted.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 19 2020, 12:21 PM - #Permalink
    Resolved
    0 votes
    It looks like you have tried just about everything. :(

    FWIW, ElRepo are now at kernel version 5.9.9 and you can use this in ClearOS.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 19 2020, 11:50 AM - #Permalink
    Resolved
    0 votes
    I've tried this on other x86_64 hardware up to the latest kernel (5.9.8) on Fedora 33, and with the latest revision of firmware downloaded directly from Git, and always get the same error. I've posted a report to the Linux Wireless dev mailing list (https://marc.info/?l=linux-wireless&m=160574568703161&w=2). As this particular product is fairly new it may be some of the hardware parameters (bmi-chip-id,bmi-board-id etc.) simply aren't recognised in the current firmware.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 19 2020, 10:22 AM - #Permalink
    Resolved
    0 votes
    linux-firmware was not updating as Centos had just released 7.9 and it belongs to that release. You can try installing it directly from centos-unverified, or you can update to ClearOS 7.9 beta.
    The reply is currently minimized Show
  • Accepted Answer

    Saturday, November 14 2020, 08:18 AM - #Permalink
    Resolved
    0 votes
    You could try the later firmware:
    yum update linux-firmware --enablerepo=centos-unverified
    I can't work out why it is not coming across but I have my suspicions. The person I need to ask is back from holiday next week.

    Alternatively go for a kernel-ml from ElRepo. They have a 5.9.8 available and they update within days of kernel.org pushing a new one. it is really bleedin' edge. It should be fully compatible with ClearOS.

    I am not really doing the app-wireless-ap but feed back to the developer. He is a Community developer doing it in his own time. I do test it occasionally and have fed back some tweaks . I also produce the final rpm's and inject them into the repos.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, November 13 2020, 11:42 PM - #Permalink
    Resolved
    0 votes
    Hi Nick,

    Thanks as always for the swift and comprehensive reply. I guessed there would be a good reason for the old kernel ver. no. Maybe the answer will be helpful if anybody else wonders the same.

    The PCI ID from lspci -nn is 168c:0046. If I am interpreting the "alias" section of modinfo ath10k_pci output correctly, this is supported (3rd line). In addition to the files listed in the "firmware" section there is a ath10k/QCA9984/hw1.0 directory (i.e. the exact chipset ID) which does contain the "missing" board-2.bin file. I've tried the module in other hardware/OS combinations and get essentially the same error each time, so it clearly isn't the kernel version as I first suspected. The most recent OS I tried was on Fedora kernel 5.8.18-100 with linux-firmware-20201022-113, which was built about three weeks ago. I'll follow this up now with the wireless firmware people.

    One of the reasons for wanting to use this module is that it looks like it has interesting potential under 802.11ac for TX beamforming / MU-MIMO (it supports 4 antennae) and DFS. I'll do a write up on those when I get it all working.

    I don't use the Wireless AP page in the web console as it has very limited functionality, although I know you and others are working to improve that. I also found that if you "Update" it overwrites hostapd.conf with the very limited config data visible, without making a backup. I configure hostapd directly, and it would be very challenging to have a web GUI that could reliably support all the functionality available (e.g. the guest WiFi VLAN I wrote up for the site last year). However I've got some suggestions for improvements, which I'll post separately when done.

    Thanks,
    Andrew
    The reply is currently minimized Show
  • Accepted Answer

    Friday, November 13 2020, 06:08 PM - #Permalink
    Resolved
    0 votes
    I've pushed an update to app-wireless-ap into contribs-testing. You can install it with:
    yum install app-wireless-ap --enablerepo=clearos-contribs-testing
    It should install version 1.1.2. If it does not, please wait an hour and try again as the repos sync.

    There are some issues. Channel selection is only 1-9 and fails the program fails (for me) if you set it to automatic. Changing WPA does nothing. It is also not good at reading back in all current selections.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 12 2020, 06:27 PM - #Permalink
    Resolved
    0 votes
    Looking further, the ClearOS kernel probably covers your device:
    [root@server ~]# modinfo ath10k_pci
    filename: /lib/modules/3.10.0-1127.19.1.el7.x86_64/kernel/drivers/net/wireless/ath/ath10k/ath10k_pci.ko.xz
    firmware: ath10k/QCA9377/hw1.0/board.bin
    firmware: ath10k/QCA9377/hw1.0/firmware-5.bin
    firmware: ath10k/QCA6174/hw3.0/board-2.bin
    firmware: ath10k/QCA6174/hw3.0/board.bin
    firmware: ath10k/QCA6174/hw3.0/firmware-6.bin
    firmware: ath10k/QCA6174/hw3.0/firmware-5.bin
    firmware: ath10k/QCA6174/hw3.0/firmware-4.bin
    firmware: ath10k/QCA6174/hw2.1/board-2.bin
    firmware: ath10k/QCA6174/hw2.1/board.bin
    firmware: ath10k/QCA6174/hw2.1/firmware-5.bin
    firmware: ath10k/QCA6174/hw2.1/firmware-4.bin
    firmware: ath10k/QCA9887/hw1.0/board-2.bin
    firmware: ath10k/QCA9887/hw1.0/board.bin
    firmware: ath10k/QCA9887/hw1.0/firmware-5.bin
    firmware: ath10k/QCA988X/hw2.0/board-2.bin
    firmware: ath10k/QCA988X/hw2.0/board.bin
    firmware: ath10k/QCA988X/hw2.0/firmware-5.bin
    firmware: ath10k/QCA988X/hw2.0/firmware-4.bin
    firmware: ath10k/QCA988X/hw2.0/firmware-3.bin
    firmware: ath10k/QCA988X/hw2.0/firmware-2.bin
    license: Dual BSD/GPL
    description: Driver support for Qualcomm Atheros 802.11ac WLAN PCIe/AHB devices
    author: Qualcomm Atheros
    retpoline: Y
    rhelversion: 7.8
    srcversion: F2D44D2E2282B72418667F7
    alias: pci:v0000168Cd00000050sv*sd*bc*sc*i*
    alias: pci:v0000168Cd00000042sv*sd*bc*sc*i*
    alias: pci:v0000168Cd00000046sv*sd*bc*sc*i*
    alias: pci:v0000168Cd00000056sv*sd*bc*sc*i*
    alias: pci:v0000168Cd00000040sv*sd*bc*sc*i*
    alias: pci:v0000168Cd0000003Esv*sd*bc*sc*i*
    alias: pci:v0000168Cd00000041sv*sd*bc*sc*i*
    alias: pci:v0000168Cd0000003Csv*sd*bc*sc*i*
    depends: ath10k_core
    intree: Y
    vermagic: 3.10.0-1127.19.1.el7.x86_64 SMP mod_unload modversions
    signer: CentOS Linux kernel signing key
    sig_key: B1:6A:91:CA:C9:D6:51:46:4A:CB:7A:D9:B8:DE:D5:57:CF:1A:CA:27
    sig_hashalgo: sha256
    parm: irq_mode:0: auto, 1: legacy, 2: msi (default: 0) (uint)
    parm: reset_mode:0: auto, 1: warm only (default: 0) (uint)
    It is a problem if the firmware does not work. It won't show up in the IP Settings screen unless you install the testing version of app-network:
    yum update app-network --enablerepo=clearos-updates-testing
    Hang fire for an update to app-wireless-ap. I've just received one from the author and I'll have a look at it tomorrow.
    Hunting round, there is an update for linux-firmware in centos-unverified you could try. I am not sure why it has not worked its way into our repos. I'll investigate.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, November 12 2020, 05:51 PM - #Permalink
    Resolved
    0 votes
    RedHat don't work like that. They major on stability so pick on a kernel then back=port patched into it. A while ago the 3.10 kernel was considered to be equivalent to around 4.14. I've no idea what it is.

    If you want something cutting edge, install an ElRepo kernel. They are compatible with ClearOS.

    ClearOS has the ath10k_pci driver. What are your PCI ID's from "lspci -nn".
    The reply is currently minimized Show
Your Reply