RTL8821CE Wireless : lspci on dom0 see it but never worked

Dear all,

On a new laptop ASUS where the wireless board (RTL8821CE) is well listed with the lspci in dom0 the qrexec-daemon systematically generates error without activating the sys-net.

I already read this : How to troubleshoot "no wifi" in qubes

This laptop does not have a RJ45 and even if I tried with tethering (smartphone) I was never able to try the explained articles here : WiFi Driver Installation Without Ethernet (Qubes 4.1.1, Realtek RTL8821CE)

I was just able once to start sys-net terminal after having changed the Virtualization Mode in PV (in place of HVM) in the sys-net Qubes settings.
But where he explained to move Network Controller to ‘Selected’ in sys-net ‘Qube Settings’, I do not have this Network Controller in the Available Applications (in sys-net Qubes Settings).

Please how could I connect my laptop to my router with this RTL8821CE my dom0 and sys-net terminals can see ?

Sincerely thank you and have a nice day.

Can you show the device tab for sys-net?
What kernel version are you running on in dom0?

Dear DVM,

Devices tab is greyed then can not seen what is on it.

Dom0 (from Quebs Global Settings I suppose) is 5.15.94-1.fc32 (is exactly what I got with a uname -a in dom0).

For info I now ran a sudo modprobe 8821ce in fedora template then a qvm shutdown followed by a restart of the sys-net in the dom0. The Enable wifi stil no available as item menu of the NetworkManager. Same situation even after a reboot (where NetorkManager stay without Enabling Wifi menu item and Devices tab not accescible in sys-net Qubes settings) .

Nothing special can be seen in the journalctl -b comand line result in sys-net terminal.

And in sys-net Qubes settings I can change to debian template to see if it could work.
I previously also tried with a debian default template but without doing the dkms-install (then modprobe) explaination saw in other thread.

So now I am stopped there with an available NetworkManager in the systray but without a Enable Wifi existing menu item (even I successfully ran the dkms-install and modprobe of the RTL8821CE).

I do not know what tot do… and I really want to stay using Qubes on this new laptop I bought for it.

Thank you for your help and the time you offered here to us.

Have a good night.

I’m sure that the device tab is greyed out because sys-net is running when you’re opening the settings. Turn it off first and then check if you can access it. If you are able to move things, make sure the ethernet/wifi controller is in “selected” then boot sys-net and test again.

Dear DVM,

as you can see here below unfortunatly the sys-net shutdown did not allow me to access the Devices tab in sys-net Qubes settings.

Devices tab stay unavailable at boot on sys-net Qubes settings even after a forced qvm-shutdown made in dom0 on the concerned sys-net.

Have a nice day.

does the following topic related to your issue:
https://forum.qubes-os.org/t/major-problem-with-qvm-pci-and-devices-in-general/8359/15 ?

the pci_0000 thing.
Is that your case too? If yes, does the workaround proposed works for you?

No about this issue. I just go there to see if I can find solutions or ways to filter what is going on on my Qubes…

Pci_0000 ? Did not see antthing about this on this post.

The lspci shows me the Realtek RTL8821CE and this is how I was then able to find infos on the forum to try finding solutions on my problem.

Now I am stopped at this position even if the rtl8821ce has been add with the dkms-install script then modprobe. And even if I added manually a connection to my SSID router in the NetworkManager thos last one still does not show a Enable WiFi item menu.

Sincerely thank you for your help.

from the reply of the link I posted:

After a quick looking into the source code 5, I found this problem was caused by a failure during a regex matching, which expects every PCI device identifier starts with pci_0000.
But if I run sudo virsh nodedev-list in dom0, I found some of my PCI device identifier starts with pci_10000. This can also be verified using lspci.

See the last three reply on the topic I posted.
Not saying this is your case, I’m asking if this is your case.
There is not so much post about disabled/grayed-out devices tab.

On another thing, your kernel is marked as provided by the qube.
Does it change something if you use the default one (6.1.x) ?

On another thing, your kernel is marked as provided by the qube.
Does it change something if you use the default one (6.1.x) ?

Another guy told me to set it as “provided by the qube” because I was not able to start sys-net when set with the last available kernel (here 5.15…).
I tried back now and still was not able to get sys-net started (see error in first line here in attached image). Then to be able to start sys-net and see the NetworkManager in the systray I have to keep the kernel as provided by the qube.

Here is the result of the pci comand line returns (see image).

Have a nice day.

So you got pci devices belonging to domain 0000 and others to domain 10000.
Did you read the latest post on the topic I posted?
To be more specific, this reply from @doc :
This is the same issue as you (the disabled/grayed-out devices tab).

You got exactly the same 3 devices into domain 10000.
And you got one more, the SATA controller: this one could be related to your second HDD.
Unfortunately, with the proposed patch, the second HDD may not work.

I read it then :

  1. I wil first try to test what is explained at the point 1. to 4.

  2. adding the line in the pci.py will be easy but

  3. I do not really know where must I put this adapted pci.py

  4. and where must I restart the qubesd service ? Is it well in the dom0 (I guess) ?

I finish here with a “stupid” question but … if it is so “simple like this” (by simply adding a line in a python script) why it is not still updated on the new Qubes version ?

And a little remark : I said I still have the kernel 5.15… (and not yet the 6. …) because on the 4.1.2
downloaded image it is the default kernel until I could update it when I will have a wifi connection :relaxed:

Thank you for you answer on the above questions (at point 3) and 4)). Have a nice day.

from the related github issue https://github.com/QubesOS/qubes-issues/issues/8143:
The file is located here (in dom0):
To restart qubesd, yes it’s in dom0 with the command:
service qubesd restart (a reboot works too).

Ha yes, indeed. I didn’t think about that, xd
But the kernel 6.x won’t change the grayed-out devices tab anyway.

There is no such thing as “stupid question”:
You don’t know what you don’t know. :slight_smile:

It’s still not implemented because it’s not a proper fix.
It’s a workaround that will ignore pci devices under domain that is not 0000
(ignored only for pci passthrough).

I think this sentence is wrong. As dom0 see it, it will probably work.
It’s just that you will not be able to passthrough the SATA controller (and probably not need to).


》You don’t know what you don’t know.
You right; asking the question means you do not know and when you do not know means you probably does not have accreditations to know it then it is why you do not have to know :slight_smile:

Well, pci.py successfully modified as expected (followed by a reboot) now Devices is (ungreyed) available on sys-net (and fedora template too).
RTL8821CE is well selected in the sys-net Devices but still does not display a “Enable WiFi” menu item in the NetworkManager.

Sys-net “Include in memory balancing” is disabled, Kernel is “provided by qube” and Virtualization Mode is HVM.

As previously said I manually created a connection to my SSID routeur but do not see if it works in the NetworkManager. The NetworkManager (red) icon stay crossed.

RTL8821CE should be supported from the linux kernel.

You got 5.15.94. You can try again by settings the kernel to this one instead of “provided by qube”.
(now that the device tab works, maybe that will work)
You can also try to update dom0, the default kernel is now 6.1.35.

If that still don’t work, you can try this driver: https://github.com/tomaspinho/rtl8821ce
(The maintenair of the repo say that the kernel driver for the 8821ce chip is broken)
Wich you already did and installed:

Let the kernel to the default one (5.15 or 6.1), if that doesn’t work, you can try with provide by qube.

Does your Network controller actually use the rtl8821ce driver you installed ?
you can find out with:

[user@dom0 ~]$ lspci -k
[... ]
3c:00.0 Network controller: ...
	    Subsystem: ...
	    Kernel driver in use: pciback
	    Kernel modules: iwlwifi

Your kernel driver in use and module should be 8821ce (the github driver) and not rtw88_8821ce (the linux kernel).

Maybe you didn’t activate the new driver after you installed it?
To activate the driver.

sudo modprobe 8821ce

(you don’t need to remove the old one, just blacklist it)
and from the next reply of the above link:

That’s runtime configuration, but you likely also need persistent one:

sudo tee /etc/modprobe.d/rtl8821ce.conf << EOF > /dev/null
blacklist rtw88_8821ce
install rtw88_8821ce /bin/false
sudo tee /etc/modules-load.d/rtl8821ce.conf << EOF > /dev/null

also from the github page: (he said the same as above: blacklist rtw88_8821ce)

A lot of people seems to struggle with this network controller.
For record, here the keywords I used:

Notice that’s not Qubes specific. :slight_smile:
But now we started, be free to ask if something went wrong.


Of course trying with the kernel 5.15 (in place of the provided by qube one) was the first think I tried when I saw the Devices tab available.
But as I get back the error when sys-net tried to start after a reboot then I came back to the 5.15.

Here is the result of lscpi -k :
Processing: 20230801_152300.jpg…

I used the tomaspinho script (running this script on the fedora template (as recommanded) returned error even with sudo then I succefully ran the four lines it contains) and activated the 8821ce (in the fedora-template .
Uploading: 20230801_153341.jpg…

I can not blacklist anything because both .conf files does not exist in modprobe.d and modules-load.d in fedora template, sys-net or even dom0.

Then I will first now to see how to get the kernel modules set with 8821ce and not rtw8821ce as it is now (with the fact I can not blacklist it) :

Thank you for your really appreciated help.

You need to create these files with the command provided in my previous reply or manually.
modprobe will process any file with the extension .conf present in the directory.
The name of the file is up to you.
I think this must be done in the sys-net template.

It’s with sudo modprobe 8821ce but you must blacklist rtw88_8821ce so that the network controller use the 8821ce.

You can use lsmod | grep 8821 to check that the 8821ce module is loaded.
Check with lspci -k in sys-net if everything is good.


I tried the blackikist comand then modprobe (even by going first in the modprobe.d folder because you said : " modprobe will process any file with the extension .conf present in the directory".

I tried tgis blacklist process in sys-net (and even on fedora template) after saw it did not changed anything.

Here is the dom0 lspci and lsmod command line result (in background) and in the red window the error returned from the modprobe command line done in sys-net.
The lspci -k just returned a (unique) line describing the RTL8821CE and the lsmod | grep 8821 did not return something.

Then I stay in the same situtation.
Except if you still have more idea, the only next step I could try is a dom0 update.

Thank you for your help.

The fact that lsmod | grep 8821 didn’t return anything, I guess the blacklist worked.
What are the kernel module and in use in sys-net ?

You don’t need to do that.
The service modprobe (don’t know the name) will process the .conf files, not the command modprobe.

sudo modprobe 8821ce say that it didn’t found the module.
lsmod say the same (or the output would not be empty).
So you didn’t install it or failed to do so !?
Try with “kernel provided by qube”.
Does lsmod see the module ?
Does the modprobe command still say not found?

You should try to make sudo ./dkms-install.sh works.
Be sure to be in the right directory: cd rtl8821ce/.
Make sure the script is executable as well: chmod +x dkms-install.sh
Try again the install in the sys-net template and add the module with modprobe.
(try with both 5.15 kernel first, and provided by qube if that doesn’t work).

I guess you use the default fedora template and not a minimal.
Just in case:

[user@disp9866 ~]$ sudo dnf install -y dkms make kernel-devel openssl bc
[user@disp9866 ~]$ cd rtl8821ce/
[user@disp9866 rtl8821ce]$ sudo ./dkms-install.sh
About to run dkms install steps...
Finished running dkms install steps.
[user@disp9866 rtl8821ce]$ lsmod | grep 8821
[user@disp9866 rtl8821ce]$ ll /lib/modules/6.1.35-1.qubes.fc32.x86_64/extra/
total 4.0M
-rw-r--r--  1 root root 3.9M Aug  2 16:29 8821ce.ko
drwxr-xr-x. 2 root root 4.0K Jun 24 02:00 module/
-rw-r--r--. 1 root root  14K Jun 24 02:00 u2mfn.ko
-rw-r--r--. 1 root root 118K Jun 24 02:00 v4l2loopback.ko
[user@disp9866 rtl8821ce]$ sudo modprobe 8821ce
[user@disp9866 rtl8821ce]$ lsmod | grep 8821
8821ce               2027520  0
cfg80211             1150976  1 8821ce

I guess, because you git cloned in a disposable and then copied the content to the template,
some files have lost theirs permission.
Therefore, you need to make executable the script (chmod +x).
You can keep the default kernel (5.15).
Everything should works … it did for me. tested on minimal fedora template in a disposable vm.

If that doesn’t work, post the output of sudo ./dkms-install.sh.
By example, it told me that I needed openssl and bc.

Dear szz9pza,

Tomorrow I will look to your two last answer and try to see if it could progress.

Reading you in regard of disposable fedora template sounds that could be on fact my main leak of Qubes syructure knowledge.

It is the main problem I met : it is difficult for me to well understand where each command line must be done. Some guys said (where it sounds logical) it must be done in sys-net where others lets know that sometimes it must be done in the fedora template.
But perhaps did I personnaly misunderstood.

This is why I will take time tomorrow to see if I could reproduce what you explained in your last two answers here above.

Still thank you for your help and I apologize to take your time so many times.

Have a good day.