Realtek wireless card not detected by Qubes

[Otto Kratik]

I am running Qubes R2 on an Asus laptop, and generally everything works fine with one exception.

My network card is a Realtek RTL 8821AE, which has both Ethernet and wifi capability. It works fine under other OS'es like Windows, normal Linux etc, no issues.

On Qubes, even though it is correctly assigned to NetVM and shows up this way in the graphical VM Manager, the system fails to detect its wifi capability. When clicking on the network system stray icon, it shows:

Ethernet

   Device not managed

And does not give any indication of wireless connectivity option. I have tried changing the kernelopts value with:

qvm-prefs -s netvm kernelopts "nopat iommu=soft swiotlb=8192"

and even higher values like 16384 and 32768, but with no change. I am not totally sure, but it is possible that before I made any change to kernelopts, the network systray icon reported:

"No network devices"

instead of even showing Ethernet ability. I'm not positive though, since it may just have been that I hadn't assigned the Realtek network adapter to netvm yet.

But I neither case, I cannot get WiFi to work properly. Are there any extra steps I should take to try making it work? Other drivers to install, or some such thing? I have already restarted Qubes after each qvm-prefs change.

Thanks.

[Otto Kratik]

So from doing some research around the net such as here (http://forums.fedoraforum.org/showthread.php?t=300794) it seems that the problem may be that Fedora simply has no driver/compatibility for this network card RTL8821, or at least not until kernel version 3.18 or so. This leaves me with a couple of options:

1) Download drivers from Realtek, build/compile from source, and try to install into Template/netvm manually. As a Linux novice, this is way too esoteric a process for me to attempt right now.

2) Try to update the kernel only in one specific TemplateVM (or clone) to 3.19, which can then be set as template for NetVM in the hope that it will recognize the network card and work better with it. Is there an *easy* way to do this, without changing or affecting dom0 or any other Template? I don't want to do "sudo qubes-dom0-update kernel-3.19*" because dom0 is currently working fine and I'd rather not risk messing it up.

3) Try to install Debian 7 template and use this for NetVM instead of Fedora 21, hoping that it will recognize and work with RTL8821 network card more successfully. Since Tails works perfectly with this laptop and wifi card out of the box, and is based on Debian, I am presuming it has a higher chance of compatibility with less modification.

Is there any advice or suggestion with regard to the above options or considerations?

[Andrew]

Otto Kratik:

There should be a very easy way to do 2). In Dom0:
`sudo qubes-dom0-update qubes-kernel-vm` (you might have to use
'--enablerepo=qubes-dom0-current-testing' to get 3.19).

No need to do anything to any templates. Just choose the new kernel on
the 'Advanced' tab in the NetVM's 'VM settings' in Qubes Manager.

Dom0 and all other VMs will still use the same kernels as before.
Actually, this might not be the case for other VMs--it might update your
default kernel to the new one. You can just change the default kernel
back (if you want) in Qubes Manager > System > Global Settings.

Andrew

[Connor Page]

On Wednesday, 19 August 2015 00:15:16 UTC+1, Andrew wrote:
>
> There should be a very easy way to do 2). In Dom0:
> `sudo qubes-dom0-update qubes-kernel-vm` (you might have to use
> '--enablerepo=qubes-dom0-current-testing' to get 3.19).
>

The latest kernel in R2 repo is 3.12.40.
kernels and modules live independently from templates. I see the security benefits but it drives me crazy sometimes.

Otto, your two options are to upgrade to R3 or to create a standalone netvm where you can compile the modules yourself from the vendor's sources or linux backports. In my experience vendor's sources always require some patching :( Check the linux kernel web page for backports of newest drivers to older kernels.

https://wireless.wiki.kernel.org

[Otto Kratik]

Thanks for the replies, Andrew and Connor. If a newer kernel is not currently available for Fedora under Qubes R2, then I suppose I'll try the Debian 7 template first with netvm before giving up entirely. Compiling drivers from source is not something I'm presently willing to undertake, and I'm holding off on Qubes R3 since it's still in release-candidate status and I prefer to work with full releases only. I also need glitch-free Windows 7 HVM functionality with QWT, so stuck on R2 for now.

I realize that the Debian template may not make much difference if it's also still using an older kernel, but some folks seem to report better success there than with Fedora using this card, even a couple of years ago under prior kernels. So I'll give it a try.

[Connor Page]

I reckon that will be a waste of time. Let us know, anyway

[Otto Kratik]

On Wednesday, August 19, 2015 at 12:00:29 PM UTC-4, Connor Page wrote:

I reckon that will be a waste of time. Let us know, anyway

I am going to try this on the weekend, and will report back either way indeed. It's a shame there isn't any way (presumably) to force install the 3.19 kernel from a Qubes R3 repository onto R2 for testing purposes. I have a few follow-up questions on the assumption that migrating to R3 is my only option, but those will get a little off track from this thread so I'm going to start a new one for them. 

[Otto Kratik]

On Friday, August 21, 2015 at 3:40:10 PM UTC-4, Otto Kratik wrote:

I am going to try this on the weekend, and will report back either way indeed. It's a shame there isn't any way (presumably) to force install the 3.19 kernel from a Qubes R3 repository onto R2 for testing purposes. I have a few follow-up questions on the assumption that migrating to R3 is my only option, but those will get a little off track from this thread so I'm going to start a new one for them. 

I installed the Debian-7 template onto Qubes R2 the usual way:

qubes-dom0-update qubes-template-debian-7

Then, I downloaded the realtek firmware package found below, which is described specifically as being a backport of drivers, intended to be used with Debian7/Wheezy, and listed to contain the exact driver I need for my network card (rtl8821ae) in the index:

https://packages.debian.org/wheezy-backports/firmware-realtek

From a gnome-terminal in the Debian 7 template, I installed the firmware package using:

dpkg -i firmware-realtek_0.43~bpo70+1_all.deb

And the install completed correctly. Checking manually under /lib/firmware/rtlwifi/ I see that the desired binary, "rtl8821aefw.bin" is there as expected.

However, after setting NetVM to use Debian-7 as its template, assigning the network card to NetVM, and restarting both Qubes R2 and the template/VM several times, and also trying various values for swiotlb for netvm, my network card is still not recognized properly by Qubes. I invariably see the message "No network devices available" or alternately "Wired connection: Device not managed" when checking network manager.

With normal stock Debian Wheezy (non-Qubes) and this driver installed, my card is recognized correctly and I have full wireless capability as expected. Is there any obvious reason why it should work fine under Debian standalone, but not in a Debian-7 template or a netVM based upon such a template?

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Check kernel messages for driver initialization errors.
Also check if you have device listed by lspci in your netvm.

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJV3ymRAAoJENuP0xzK19csr1sH/2KZv5XvzOfYlGhFdVABIxAj
PkM+C2MUl6IDQEIIObDmFn9PE8wXb5Nvk3bFCXNR5N1HnzntkufnG4dxvsxePVox
DevClWDoZDgNW7f8DHRIywHM3XSFFiouSL6o0RxENp65VYANGnytqFE45+ahwhwQ
FrmKCCL1XyB4vzqNAlc5aTLufiWkf7R7jTX6c9ak7UAhFJB4cIkGXOUBe3I+tvsS
ViHr1UQHyyTa6gjubOXKpSFtTLC5B0GzzOMXaIuIKNRJRFSDVnIvMJtFxksAjM0W
F/3vz66CMlgGqNS7+/blzxIIuvexFF4GWrtSCrCFvH1RFW2HAcYAepUArvwA1Rc=
=C1wc
-----END PGP SIGNATURE-----

[Otto Kratik]

On Thursday, August 27, 2015 at 11:15:30 AM UTC-4, Marek Marczykowski-Górecki wrote:

Check kernel messages for driver initialization errors.
Also check if you have device listed by lspci in your netvm.

From within Netvm terminal, lspci correctly shows Realtek Semiconductor Co Ltd Device 8821

How do I check kernel messages for driver initialization errors?

Sorry, I am still new to Linux/Qubes.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

`dmesg` command. Search for anything related to the device name and/or
its PCI location (listed by lspci).

- --
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJV34FRAAoJENuP0xzK19csxnkH/iwnL698i28czasAm1avwlaS
0gNhq+zx00NLdoGIwqyN4htPNDPtyvwlj0WtvgBOKCj8yIO+P5Czg4kCpQE1N9BH
+nEQudlc8wOIVU98e8GvsT8aBJ2uuhm1CCPkiOyJlyHVLsQ9pZJd2bBM3H6RXP2+
pqs+OVqmO+JoEUMeDVT7NxRypNBlq1jebSGmPeyFe50JPrL6Bv7VqI8b3U9HfCey
URJQajGNQJyYX0DkHOYpjmXCCraPmt2ogJgCi8UayuDQ5fYAqB26/19Mz33FpboT
oHOdpbnRTyzgshVvu0MIuJCiIxJuHe5z4fKeo3RikgEo3WZQXAuVnVmLCjrShP8=
=0ip1
-----END PGP SIGNATURE-----

[Connor Page]

On Thursday, 27 August 2015 15:42:26 UTC+1, Otto Kratik wrote:
> On Friday, August 21, 2015 at 3:40:10 PM UTC-4, Otto Kratik wrote:
>
> I am going to try this on the weekend, and will report back either way indeed. It's a shame there isn't any way (presumably) to force install the 3.19 kernel from a Qubes R3 repository onto R2 for testing purposes. I have a few follow-up questions on the assumption that migrating to R3 is my only option, but those will get a little off track from this thread so I'm going to start a new one for them. 
>
>
>
>
> I installed the Debian-7 template onto Qubes R2 the usual way:
>
>
> qubes-dom0-update qubes-template-debian-7
>
>
>
>
> Then, I downloaded the realtek firmware package found below, which is described specifically as being a backport of drivers, intended to be used with Debian7/Wheezy, and listed to contain the exact driver I need for my network card (rtl8821ae) in the index:
>
>
> https://packages.debian.org/wheezy-backports/firmware-realtek

what use is of firmware if there is no driver to load that firmware?

[Otto Kratik]

On Friday, August 28, 2015 at 7:22:57 AM UTC-4, Connor Page wrote:

what use is of firmware if there is no driver to load that firmware?

I suppose that I am not entirely clear on the difference between drivers and firmware, as pertains to a hardware peripheral like a network card. I don't doubt that there must apparently be an important distinction between the two... I just don't know what it is, and hoped that installing the latter would be sufficient to enable my network card to work correctly. If it is all just futile though, perhaps I will give up and try installing Qubes R3 instead, since using a newer kernel version will be easier there.

[Qubed One]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Just a thought... you might try removing the wired ethernet card from
the net-vm, leaving only the wireless. Output of dmesg in the net-vm
could help to further troubleshoot if needed.

>>
>> With normal stock Debian Wheezy (non-Qubes) and this driver
>> installed, my card is recognized correctly and I have full
>> wireless capability as expected. Is there any obvious reason why
>> it should work fine under Debian standalone, but not in a
>> Debian-7 template or a netVM based upon such a template?
>

-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJV4Ih1XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2N0FGNkY4NTIxMzYxNjI1REE1MjY1QTcw
MUNBRjYzOTFBQkM0OTgzAAoJEAHK9jkavEmDLaYP/3aerf8iWexVhbt9P0Wvvifq
JYxgrTCsmEpSP4YOJ9qtvrzIMahDMBHJyAUjIz3ZGzWDeK8b97m6xzBjv23jIo0y
FLQJs8HzTJtWEdHVbLy9E4oAko6bXN/YMobaFFnhcvrk+anlmkelXXBGh/TmYbop
6fTQGpvP7gh0+l8Gtf4E+TQRBifi37ut5s/M6ZTJwQWFCV3ogmOnN3iuupm/fBRX
9IOkoUl2mrTkqZqjajY12RiFNH6veertfcGHz7NZnRCFZjwC6BoX/M/w3mg0gQP0
TjCMGYVnAc6IXCHm2TRWI9AZjHLuCRNOK4/e82+wBAd3TaQJb9tyWnACuOaLuMjA
YyCpZU475bdp++NchdzO8hP1BDtmAhMqWHtXUCqnz7xVQrVBBkS+OIoWGtf3rts2
OGmDFMbFzKt9N0JQfp3YEE9ryZi4RK5IED4ZEG2iIOfdI/92YzZefgdAIVDCI62z
senhIGQO3RTYvqqtnUDno6vkh4ceTKQTWTK6xmcuMqW4TGGQsKddyRHlcvtOjB/6
2nmVwUaYxOWsNip/zTpX0X5LzrEnIT0ElvPUBhTZ7ixG24UtwbVzIYdd1eaD+khh
9MxXiSY3pXH5yTPBqaoYUnhoVt/zz16Zq7tPIjpTCmuh/Xeb+mMV0+tjvpzt418G
0ppYYSBveUjcTC2HoYy1
=RZZ9
-----END PGP SIGNATURE-----

[Otto Kratik]

On Friday, August 28, 2015 at 12:12:49 PM UTC-4, Qubed One wrote:

Just a thought... you might try removing the wired ethernet card from
the net-vm, leaving only the wireless. Output of dmesg in the net-vm
could help to further troubleshoot if needed.

In my laptop's case, the one single network card (RTL8821ae) provides both Ethernet and wifi functionality, so they are lumped together in that way.

In any event, I decided to try jumping to R3rc2 instead of further investigating the issue under R2.

The new version detects and activates the wireless card instantly out of the box, with no additional configuration necessary. So I will probably just try to go forward from here with R3 rather than hopping back and forth between versions, as long as I don't encounter anything of a game-stopping-glitch variety with the current version.

[Connor Page]

...and we're back to the original advice :) don't worry, a lot of us have upgraded to R3 so many bugs have been reported, patched or at least known. I'm sure you'll find help here.
proprietary drivers are split into open source kernel modules that are licenced under GPL and firmware that only vendors (and sometimes hackers) have the sources to. there must be a kernel module that knows how to load and run the firmware. firmwares are not free, so they usually are put in a separate repo.