Questions on Bluetooth

#1

So, I’ve heard a lot of people stating the Bluetooth doesn’t work (or is non-free) for the Librem line.
I’m find utilizing an USB adapter but, wanted to ask some questions.

Any idea when this will be fixed?
People have been stating this for a while now. Purism’s official response seems to be that they “plan” to get free software firmware. But, this doesn’t appear to be happening.
Anybody know something I don’t?

Is it possible to use a free’d wireless card?
I know many other users utilize a more free software friendly card like the N450 Dual Band Wireless miniPCIe Card sold by Technoethical. Despite it not supporting Bluetooth, is it possible for users to swap the default card for this one?

How easy is it to remove?
Personally, if the card requires non-free software then I don’t want the card.
I know users can buy “air gaped” machines but, how can you remove the card altogether?
I didn’t see it in the wiki: https://wiki.puri.sm/hw/l13/v3

My main fear is that an OS will assume I want the non-free drivers, when I can just use a USB adapter.

Is it a Bluetooth and WIFI in one Card?
Basically, do I need to remove the WIFI to also remove the Bluetooth?

#2

I’m confused. The Atheros AR9460 wifi/BT card which ships in Librem laptops does not require non-free firmware for the wifi. It’s as free as you can get. Why would you want to replace it with another non-free card which provides no additional capability or performance?

The bluetooth component of the AR9640 does require non-free driver firmware currently, as we’re continuing to work on RE’ing that so that a completely free driver can be used.

#3

And to add to that, I have developed a kernel patch that prevents loading of the AR3k Bluetooth firmware while still initializing the BT properly using the chip’s built in ROM firmware. I am using this for some time now and do not experience and regressions. The only problem remaining is that one still needs the config file which is part of the non free firmware (the “ramps…” file). This file does not contain actual firmware but only some settings, one of which enables the Wifi - Bluetooth coexistence in the Bluetooth chip so that it can share the antennas with the WiFi card. So without this config file the Bluetooth would work but would be be deaf. I am working with the FSF now if such a binary only config file would be OK to have / ship. If it is this would be the suggested solution to enable Bluetooth in the Librem laptops and I would work on upstreaming the kernel patch.
For everyone interested, this patch looks like this:

--- linux-4.18/drivers/bluetooth/ath3k.c	2018-09-26 08:39:43.000000000 +0200
+++ linux-4.19/drivers/bluetooth/ath3k.c	2018-11-05 07:59:24.739931449 +0100
@@ -528,18 +528,20 @@
 	/* load patch and sysconfig files for AR3012 */
 	if (id->driver_info & BTUSB_ATH3012) {
 		/* New firmware with patch and sysconfig files already loaded */
-		if (le16_to_cpu(udev->descriptor.bcdDevice) > 0x0001)
+		if (le16_to_cpu(udev->descriptor.bcdDevice) > 0x0001) {
+			BT_ERR("ath3k patch already loaded");
 			return -ENODEV;
+		}
 
 		ret = ath3k_load_patch(udev);
 		if (ret < 0) {
-			BT_ERR("Loading patch file failed");
-			return ret;
+			BT_ERR("Loading patch file failed, ignoring");
+			// return ret;
 		}
 		ret = ath3k_load_syscfg(udev);
 		if (ret < 0) {
-			BT_ERR("Loading sysconfig file failed");
-			return ret;
+			BT_ERR("Loading sysconfig file failed, ignoring");
+			// return ret;
 		}
 		ret = ath3k_set_normal_mode(udev);
 		if (ret < 0) {

Cheers
nicole

Does the Librem 15 v4 have Bluetooth software out of the box?
Bluetooth Keyboard
Apt upgrade error purebrowser
Librem 5 — Promise Delivery Chart
#4

For installing OSes like QubesOS that automatically install non-free firmware.

The thought process was that I could just swap out the non-free card and put one in that is more free’d.

The problem isn’t with the WIFI but the Bluetooth fore, my understanding is that they are provided by the same wireless card. Therefore, to disable one you must disable both.
Are you saying this is incorrect?

@MrChromebox

Cool, is there any tutorial for users who want to try implementing this?

Also, from my understanding, most users that do not want proprietary drivers for WIFI is because they can make it send more data than requested or do something malicous on the laptop.
However, because your patch enables it so that no firmware on the main storage gets installed this would not be an issue, correct?

Plus, all currently used Bluetooth and WIFI cards also contain non-free ROM firmware, correct?

@nicole.faerber

#5

There is no tutorial, I am sorry you have to rely on more experienced developers to implement that for you then.

The firmware question has nothing to do with doing “malicious” things, it has to do with freedom, security and privacy - to explain this I would need to into a lot of details and this is not the right place for it.

I can also not comment on “all Bluetooth and WiFi cards” for obvious reasons. What I can say though is that the AR3k Bluetooth chip implemented on the M.2 card in the Librem laptops comes with a built-in ROM firmware that is capable enough to be usable, which the above mentioned kernel patch enables.

Cheers
nicole

#6

I liked the idea when reading this and already thought about testing it on my Librem.

But while thinking about it, I stumbled over the fact that the blob might not be on my disk, but instead I use a blob from my hardware. Isn’t that cheating somehow?

To think it a bit further: What gives me more control? Using the unchangable blob in my hardware or using the blob from my disk (that - taken I’d invest a lot of work - I could probably disassemble somehow to understand or change it)?

In the light of this new bluetooth issue I’d say that using an updated firmware would improve my security and using the old ROM firmware would be risky.

#7

Yes, you are right to some extend and this argument is exactly what is currently debated with the FSF and others. The basic idea is to treat a device which contains the firmware in some form of internal storage as hardware - like some other chip which has a specified function, you get a documentation for it and you can be ind f sure that this hardware will always work the same way and can not be tweaked to do malicious things without you noticing.
But this clearly opens up the question of how to handle security updates. These “pieces of hardware” have become so ‘smart’ and complex that they are likely to have bugs and will need updates at some point - updates you really want to have to protect you. The FSF is aware of this issue and we (and others) are in discussion with them how to best cope with this - maybe by some form of change or exception for the RYF rules, we don’t know yet.

But up to now it is like it is, i.e. firmware is to be stored on the piece of hardware and the OS shall not touch it - unless the firmware is fully open and free. Reverse engineering the two files for the BT of the AR3k would be pretty awesome! This would allow the firmware download and be RYF compliant.The RAMPS file of the AR3k is, I am pretty sure about this, only a binary parameter file. The real code is in the second file that gets loaded (and which can be ignored for now). The RAMPS file has a couple of prettty regular structures which shouldn’t be too hard to rev-eng. That would be very awesome!

Cheers
nicole

Librem 5 — Promise Delivery Chart
Developer tweets about Librem 5 flaws as not open source!
#8

Thanks a lot for the timely answer, the background information and the good work at the root of the problem!

#9

Will there be a blogpost, if the discussion with the FSF and the upstreaming of your patch are done? :slight_smile:

#10

Sure, absolutely, even before that, once we have something to report. ATM everything is pretty much “in the air” but as soon as we start have a plan or path we will for sure talk about it.

Cheers
nicole