Loading additional ath10k firmware

[thesunexpress]

I am having trouble with a requirement for additional firmware.
The Alpine Linux image that you provide with this deployment apparently requires additional Ath10K firmware in order to get the onboard wireless NIC correctly initialized. From the handy included console, the Linux kernel complains about missing firmware. How does one go about 'injecting' additional Atheros firmware into the provided freebsd-wifibox-appliance.snapshot-<n>.img ?

In case it helps:
The WiFi chip in question is a QCA6174, as reported by both FreeBSD & Linux, although printed on the actual hardware itself it says it is a QCNFA-324 device.

The firmware that gets loaded by Arch Linux for this chip appears to be:
https://github.com/kvalo/ath10k-firmware/blob/master/QCA6174/hw3.0/4.4.1/firmware-6.bin_WLAN.RM.4.4.1-00157-QCARMSWPZ-1

Any pointers on how to get this done would be greatly appreciated.

[pgj]

Currently, injection of any kind of extension over the prepackaged contents is a bit laborious but not impossible effort. Please study the wifibox-alpine(5) man page to learn how to modify the virtual machine image yourself. According to the Alpine Linux web site, the necessary firmware files are provided by the linux-firmware-ath10k package.

# mount -o remount,rw /
# apk update
fetch http://dl-cdn.alpinelinux.org/alpine/v3.15/main/x86_64/APKINDEX.tar.gz
v3.15.0-161-g8cb73c5080 [http://dl-cdn.alpinelinux.org/alpine/v3.15/main]
OK: 4809 distinct packages available
# apk add linux-firmware-ath10k
(1/1) Installing linux-firmware-ath10k (20211027-r0)
1 error; 323 MiB in 72 packages
# ls -lh /lib/firmware/ath10k/
total 36K    
drwxr-xr-x    3 root     root        4.0K Dec 31 10:24 QCA4019
drwxr-xr-x    4 root     root        4.0K Dec 31 10:24 QCA6174
drwxr-xr-x    3 root     root        4.0K Dec 31 10:24 QCA9377
drwxr-xr-x    3 root     root        4.0K Dec 31 10:24 QCA9887
drwxr-xr-x    3 root     root        4.0K Dec 31 10:24 QCA9888
drwxr-xr-x    3 root     root        4.0K Dec 31 10:24 QCA988X
drwxr-xr-x    3 root     root        4.0K Dec 31 10:24 QCA9984
drwxr-xr-x    3 root     root        4.0K Dec 31 10:24 QCA99X0
drwxr-xr-x    3 root     root        4.0K Dec 31 10:24 WCN3990
wifibox:~# ls -lh /lib/firmware/ath10k/QCA6174/
total 8K     
drwxr-xr-x    2 root     root        4.0K Dec 31 10:24 hw2.1
drwxr-xr-x    2 root     root        4.0K Dec 31 10:24 hw3.0
wifibox:~# ls -lh /lib/firmware/ath10k/QCA6174/hw3.0/
total 3M     
-rw-r--r--    1 root     root      618.5K Oct 29 08:09 board-2.bin
-rw-r--r--    1 root     root        7.9K Oct 29 08:09 board.bin
-rw-r--r--    1 root     root      716.6K Oct 29 08:09 firmware-4.bin
-rw-r--r--    1 root     root      686.4K Oct 29 08:09 firmware-6.bin
-rw-r--r--    1 root     root      590.3K Oct 29 08:09 firmware-sdio-6.bin

And then restart the guest. Please let me know if that solved the problem for you, so I could include this package in the next virtual machine image.

[thesunexpress]

Yeah, it'd be fun if I could get the image to get any sort of connection to a WiFi AP, but that's the problem. I need the additional / updated firmware in order to connect to a WiFi AP to begin with......
Let's see what I can find out from the manpage.

[pgj]

Aw, yes, you are absolutely right! :-D Sorry that I completely forgot to consider this possibility. But I was also under the assumption that you were still able to connect the wifibox guest to the Internet. But fear not, let me try to help you out with a workaround.

The guest shares its /var partition with the host, which is at /var/run/wifibox/appliance/ on the host. The required package could be placed somewhere there, for example to cache/apk by downloading directly to there (as root):

# cd /var/run/wifibox/appliance/cache/apk/
# curl -O https://dl-cdn.alpinelinux.org/alpine/v3.15/main/x86_64/linux-firmware-ath10k-20211027-r0.apk
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 7558k  100 7558k    0     0  2703k      0  0:00:02  0:00:02 --:--:-- 2704k

Then, on the guest:

# mount -o remount,rw /
# apk add --no-network /var/cache/apk/linux-firmware-ath10k-20211027-r0.apk
WARNING: Ignoring http://dl-cdn.alpinelinux.org/alpine/v3.15/main: No such file or directory
1 error; 323 MiB in 72 packages

[thesunexpress]

It is indeed a chicken-vs-egg-vs-chicken situation.
It is true, the host can connect to a WiFi AP via USB dongle, but without USB passthrough to the Alpine image, one is left just as far afield. Which is why I figured injecting the image as a solution. Good move on sharing the /var partition!
I shall give this a try tonight/tomorrow after recovery from festivities.
But first, happy new-year party time!

[thesunexpress]

You sir, are a genius.
This was so easy to get working, that I'm still giggling in astonishment. The only "issue" I have now, is that my efforts into getting the if_athp ath10k driver for FreeBSD to a workable state is being called into question. Given the current state of 80211ac / 80211ax, or rather the lack thereof, wifibox is a much MUCH better solution.
Out of curiosity, would it be prudent to set a password for the root account of the Alpine Linux disk image? The wifibox console root account doesn't require one, but might that be / become a security issue at all?

You have my many thanks!

[pgj]

Thank you too for testing. I am glad that my hints worked. Could you please give me the model of your notebook so I could include it in the compatibility table? Is this a notebook?

Regarding if_athp development, I think it is still better to have something integrated in the FreeBSD kernel (i.e. the traditional way of porting Linux drivers) because it does not require I/O MMU virtualization, that much of resource (since, note that one must run a complete Linux kernel and userland to pull this off), and support for suspend-resume is better. If I recall correctly, Björn Zeeb has been actively working on the 80211ac / 80211ax stack for the iwlwifi port which will make it easier to import other drivers. But it has been a long process, and will work for FreeBSD 13 and later only, so wifibox is provided as a temporary aid until it is done and offer something for the older systems. It can serve a good reference point as well to see "we are there" in terms of stability and performance.

I did not see a reason to set a default password for the root account. It is not possible to login to the system remotely due to lack of an SSH server or any other similar service, and the console also has to be explicitly enabled and recommended for maintenance only. Or is there any other attack vector I forgot to consider?

[thesunexpress]

Dell XPS 9380 --- WiFi NIC = QCA6174, and printed onto the actual device is "Killer 1435-S" & "QCNFA324".
A native if_athp driver would be nice to have, but it seems a rather stagnant endeavor at the moment. I've been spending much time debugging and building the source made available by erikarn & Geramy here on github, without much success so far... but even so that would produce a driver incapable of 80211ac nor 80211ax.
Considering how few resources this method with wifibox actually uses, I'd call it superior to any alternative --- USB WiFi dongles etc. I'm using the default settings provided: 1 cpu / 128MB memory, and there's literally no performance penalty.
There was a fair bit of iwlwifi updates sailing by in a recent git pull on base src but we are still a long ways away.

As for the password-less root access to the console, it is probably safe... it would be an extremely niche & desperate case for anyone to try and break into this sort of deployment. Indeed, with lack of any means of gaining access other than a very specific console socket access, makes things virtually inaccessible. The tyrannical sys-admin in me doesn't like password-less accounts in general.

A bit of advice for the man page I can offer, is to include the following instructions particularly for laptop users:

• Add to /etc/rc.conf
background_dhclient="YES"
background_dhclient_tap0="YES"
defaultroute_delay="0"

This drastically reduces boot times, so you aren't sitting around for 30+ seconds waiting for a positive link & issuing of an IP. Obviously this only makes sense for those who launch wifibox at boot time & use wifibox as their primary access to network. It even offers a slight benefit to those using static IPs, instead of launching a dhclient, with no waiting on a route.

[pgj]

Thanks for the all resourceful comments and the information for the compatibility table! I created a separate issue for the advice about the man page, as well as another issue for adding the missing firmware package. That said, would you mind if I closed this issue?

[thesunexpress]

Go right ahead! I consider this issue fully remedied & very useful to add to the knowledge base.

I do have a new issue, potentially, still doing some extra tests to see what the cause could be... But I'll start a new issue for it because it is totally unrelated to adding additional essential firmware to the Alpine Linux VM image.

[pgj]

Okay, great.

[avysk]

Does this approach still work?

On guest:

wifibox:~# dmesg | grep ath10k
[    0.956388] ath10k_pci 0000:00:06.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
[    1.164240] ath10k_pci 0000:00:06.0: Failed to find firmware-N.bin (N between 2 and 6) from ath10k/QCA6174/hw3.0: -2
[    1.164244] ath10k_pci 0000:00:06.0: could not fetch firmware files (-2)
[    1.164245] ath10k_pci 0000:00:06.0: could not probe fw (-2)
wifibox:~# which apk
wifibox:~#

In other words: firmware is required; apk is not present in guest.

alexey@barad-dur:~ $ freebsd-version
14.0-STABLE
alexey@barad-dur:~ $ wifibox version
wifibox version 0.13.0
Disk image checksum: 83ee05a63c76d5cdc18a2441eb30bebe58f4149b1dfe7659ac92eb338cc2cf45

[avysk]

Problem between chair and keyboard, never mind.