Qubes 3.0 freezes unless Broadcom BCM4313 Wi-Fi adapter is disabled

[QubyTester]

Qubes 3.0 with the supplied Fedora 21 and Linux kernels does not support Broadcom BCM4313 Wi-Fi adapter featured on Dell Latitude E6430 and other laptops.

On such laptops, unless BCM4313 Wi-Fi is disabled in BIOS, Qubes installation freezes during the last phase (VM creation, starting network). If BCM4313 is disabled in BIOS, installation succeeds, and afterwards it's possible to re-enable BCM4313 in BIOS and boot Qubes. However, subsecuantly adding BCM4313 device to the sys-netvm freezes the computer.

The issue is apparently because BCM 4313 requires firmware not present in the supplied kernels or linux-firmware package. The available drivers/firmware include proprietary versions from Broadcom (wl, STI) which are not desireable. There is also "open" driver named brcm80211, but it's not supported in Fedora out of the box yet (with the supplied kernels). Some people reported patching the kernel to make it work, which will probably exceed the level of comfort for many Qubes users.

Interestigly, when the same laptop is tested with a Debian-based distro (Tails 1.6), BCM4313 Wi-Fi works OK, since brcm80211 and bcm43xx firmware loader are included there.

Many Dell Latitudes include the features desireable to run Qubes (VTI-d, etc.). Could you please consider using Qubes Fedora/kernel templates or some other solution that would support Broadcom BCM4313?

Thank you,
QubyTester

[marmarek]

I think firmware package is included, this may be about kernel version.
But first make sure you have VT-d enabled in BIOS - in many systems it
is disabled by default.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

I think firmware package is included, this may be about kernel version.
But first make sure you have VT-d enabled in BIOS - in many systems it
is disabled by default.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[QubyTester]

Thanks, but the BIOS is the latest version with VT and VT-d options checked. Running 'qubes-hcl-report' confirms that HVM and IOMMU are both enabled.

Driver:
The stock Fedora drivers 'b43' and 'b43legacy' do not support BCM4313 (http://linuxwireless.sipsolutions.net/en/users/Drivers/b43/ ). Ignoring the available proprietary 'broadcom-wl' driver, the 'brcm80211' package should be the solution (http://linuxwireless.sipsolutions.net/en/users/Drivers/brcm80211/), but I don't see it or any clear working instructions on how to get brcm80211 in Fedora.

Firmware:
Package 'linux-firmware' is installed. I also see 'b43-openfwwf', but it knowingly supports only BCM4306, BCM4311/1, BCM4318, BCM4320.
The mentioned Tails (Debian, kernel 3.16 where BCM4313 works OK) includes the package 'firmware-brcm80211' with its b43xx loader, but Fedora in Qubes currently doesn't have such package out-the-box.

Kernel:
Someone said Broadcom BCM4313 support is enabled starting with kernel 3.15 (unconfirmed). The current kernels available to Qubes AppVMs are older. Any chance the AppVMs may see a newer kernel soon?

Appreciate any specific guidance to get my built-in Wi-Fi working in Qubes.

[QubyTester]

Thanks, but the BIOS is the latest version with VT and VT-d options checked. Running 'qubes-hcl-report' confirms that HVM and IOMMU are both enabled.

Driver:
The stock Fedora drivers 'b43' and 'b43legacy' do not support BCM4313 (http://linuxwireless.sipsolutions.net/en/users/Drivers/b43/ ). Ignoring the available proprietary 'broadcom-wl' driver, the 'brcm80211' package should be the solution (http://linuxwireless.sipsolutions.net/en/users/Drivers/brcm80211/), but I don't see it or any clear working instructions on how to get brcm80211 in Fedora.

Firmware:
Package 'linux-firmware' is installed. I also see 'b43-openfwwf', but it knowingly supports only BCM4306, BCM4311/1, BCM4318, BCM4320.
The mentioned Tails (Debian, kernel 3.16 where BCM4313 works OK) includes the package 'firmware-brcm80211' with its b43xx loader, but Fedora in Qubes currently doesn't have such package out-the-box.

Kernel:
Someone said Broadcom BCM4313 support is enabled starting with kernel 3.15 (unconfirmed). The current kernels available to Qubes AppVMs are older. Any chance the AppVMs may see a newer kernel soon?

Appreciate any specific guidance to get my built-in Wi-Fi working in Qubes.

[marmarek]

Hmm, you should have at least 3.18 in the VM. If not - check VM
settings. And try to update kernel-qubes-vm package (from dom0).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Hmm, you should have at least 3.18 in the VM. If not - check VM
settings. And try to update kernel-qubes-vm package (from dom0).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

The page you've linked about brcm8211:
"Please note: at least BCM4313 is not fully supported."
Anyway our 3.18 kernel include both brcmsmac and brcmfmac modules.
Also in a fresh Qubes installation I see firmware for 4313 in /lib/firmware/brcm.

[marmarek]

The page you've linked about brcm8211:
"Please note: at least BCM4313 is not fully supported."
Anyway our 3.18 kernel include both brcmsmac and brcmfmac modules.
Also in a fresh Qubes installation I see firmware for 4313 in /lib/firmware/brcm.

[teki69]

QubyTester, I've encountered the very same issues as you with my Dell E6420's BCM43228 adapter.
I solved the freeze issue (occurring upon adding the card to a netvm) by enabling PCI Arbitrator's permissive mode for that device. Refer to "PCI Passthrough Issues" section in https://www.qubes-os.org/doc/AssigningDevices/ for guidance.
I hope it'll work for you too.

[teki69]

QubyTester, I've encountered the very same issues as you with my Dell E6420's BCM43228 adapter.
I solved the freeze issue (occurring upon adding the card to a netvm) by enabling PCI Arbitrator's permissive mode for that device. Refer to "PCI Passthrough Issues" section in https://www.qubes-os.org/doc/AssigningDevices/ for guidance.
I hope it'll work for you too.

[Nashy73]

I am attempting to install Qubes on a MacBook Air and I have had little success following the instructions for putting the Broadcom wireless device into PCI passtrough so I'm going to try the other option of removing it from the Mac altogether to get the install to work. My question is once installed I'm assuming I need to put the Broadcom device back into the machine? or will that take result in the machine freezing on boot again? This may be a very stupid question! I am new to all this so be kind please.

[Nashy73]

I am attempting to install Qubes on a MacBook Air and I have had little success following the instructions for putting the Broadcom wireless device into PCI passtrough so I'm going to try the other option of removing it from the Mac altogether to get the install to work. My question is once installed I'm assuming I need to put the Broadcom device back into the machine? or will that take result in the machine freezing on boot again? This may be a very stupid question! I am new to all this so be kind please.

[andrewdavidwong]

@Nashy73: Please consider posting your question to the qubes-users mailing list instead. (You can read more about our mailing lists here.)

qubes-users is intended for these sorts of questions and receives much more traffic, which means that your question is more likely to receive a response there.

[andrewdavidwong]

@Nashy73: Please consider posting your question to the qubes-users mailing list instead. (You can read more about our mailing lists here.)

qubes-users is intended for these sorts of questions and receives much more traffic, which means that your question is more likely to receive a response there.

[mannp]

@Nashy73 did you manage to get your issues sorted as I have the same problem with my macbook air on v4rc3.

The passthru trick doesn't seem to work and the lockup still occurs.

With the qubes forum being google it sort of defeats the object of a secure system, sharing the issues with google.

[mannp]

@Nashy73 did you manage to get your issues sorted as I have the same problem with my macbook air on v4rc3.

The passthru trick doesn't seem to work and the lockup still occurs.

With the qubes forum being google it sort of defeats the object of a secure system, sharing the issues with google.

[andrewdavidwong]

With the qubes forum being google it sort of defeats the object of a secure system, sharing the issues with google.

It would be the same with any public mailing list, since Google crawls the entire public Web. (And if the mailing list weren't public, how would you read or post on it? Would we have to vet you first to make sure you don't work for Google? How would we know? etc.)

[andrewdavidwong]

With the qubes forum being google it sort of defeats the object of a secure system, sharing the issues with google.

It would be the same with any public mailing list, since Google crawls the entire public Web. (And if the mailing list weren't public, how would you read or post on it? Would we have to vet you first to make sure you don't work for Google? How would we know? etc.)

[mannp]

Yeh now you are going to an extreme.

Using a forum for registered users such as discourse allows you to setup whether you want to be crawled by googles bots or not.

[mannp]

Yeh now you are going to an extreme.

Using a forum for registered users such as discourse allows you to setup whether you want to be crawled by googles bots or not.

[andrewdavidwong]

Yeh now you are going to an extreme.

Using a forum for registered users such as discourse allows you to setup whether you want to be crawled by googles bots or not.

Sure, but that doesn't make it hard for Google (or anyone) to see the contents of the mailing lists. All they have to do is sign up for a free account, just like everyone else. Your objection was:

With the qubes forum being google it sort of defeats the object of a secure system, sharing the issues with google.

If you believe that "sharing the issues with google" defeats the security of Qubes, then how does requiring someone at Google to take a few seconds to sign up for a free Discourse account preserve the security of Qubes? This is not plausible. The security of Qubes doesn't depend on whether Google (or anyone) has access to our public mailing lists.

[andrewdavidwong]

Yeh now you are going to an extreme.

Using a forum for registered users such as discourse allows you to setup whether you want to be crawled by googles bots or not.

Sure, but that doesn't make it hard for Google (or anyone) to see the contents of the mailing lists. All they have to do is sign up for a free account, just like everyone else. Your objection was:

With the qubes forum being google it sort of defeats the object of a secure system, sharing the issues with google.

If you believe that "sharing the issues with google" defeats the security of Qubes, then how does requiring someone at Google to take a few seconds to sign up for a free Discourse account preserve the security of Qubes? This is not plausible. The security of Qubes doesn't depend on whether Google (or anyone) has access to our public mailing lists.

[mannp]

Fair point, google can get where they want to go, so why bother, as you say.

I guess the issue is more about useability, sense of community, ease of use, ability to find information to help users help themselves, getting with the times, using the tools to market qubes and not just throw people off to a draconian system that is awful to find things and is just set in the past.

I understand qubes is written by techs for techs but that system just says 'can't be bothered.......

Clearly just my opinion.

[mannp]

Fair point, google can get where they want to go, so why bother, as you say.

I guess the issue is more about useability, sense of community, ease of use, ability to find information to help users help themselves, getting with the times, using the tools to market qubes and not just throw people off to a draconian system that is awful to find things and is just set in the past.

I understand qubes is written by techs for techs but that system just says 'can't be bothered.......

Clearly just my opinion.