How do you configure your network settings in sys-net? Do you use Network Manager applet in dom0 tray?
Can you upload screenshots with your network settings to check if there’s an error there?
1 Like
I would like to know how to log error messages on the interface. If it is set up, I assume it will connect to the internet, but is it set up by the dom0?
With this:
I meat for you to check the logs in sys-net terminal with sudo journalctl -b and search for “ens6” and “enp0s6” there.
1 Like
Thanks, I read the log that came up with sudo journalctl -b, but there are no words like ens6 , enp0s6. The network settings are configured in the properties that come up when I right-click on the computer icon in the top right corner, as I can’t find Network Manager. I think it might be here. I have no network settings on the dom0 side.
Maybe you didn’t scroll it with PageUp/PageDown or with arrows?
You can also print full log in the terminal with this command if it’s easier for you to scroll in GUI window:
sudo journalctl -b --no-pager
Then it means you’re using Network Manager applet.
2 Likes
Ah! I didn’t realise I could scroll down… I just checked and if it’s a NetworkManager log, it’s there. But I don’t think there are any words like ens6 in the interface.
Since interface with this name is present then it should be somewhere in the log.
You can search for a string in journalctl with / key. For example, type /ens6 and then press Enter.
You can read journalctl help about its shortcuts if you press h key.
1 Like
I tried typing the command but without success, so I did a search from the terminal toolbar.
kernel: r8169 0000:00:06.0 ens6 : No native access to PCI extended config space, falling back to CSI
ens6: Link is Down NetworkManager: device(ens6) :. state change: unavailable → unmanaged(reason ‘sleeping’ , sys-iface-state:‘managed’)
The following messages are picked up from the lines that appeared in ens6 that seem to be important.
How did you configure your network interface? Is it using DHCP or is it configured manually?
If it’s DHCP then can you try to configure it using manual method?
1 Like
Just these messages are not enough to understand what is happening there. If I could see the full log maybe I could think of a possible issue but with just these messages I have no clues.
1 Like
Yes, I tried with DHCP and specified manually, I did not change the settings for PFSense either, I am still using DHCP, the DHCP range is also set to 192.168.1.10 - 192.168.1.245, I have not changed the settings for PFSense, I am still using DHCP.
Can you copy the sys-net log and upload it here?
You can write the log in file in sys-net terminal with this command:
sudo journalctl -b > logfile
1 Like
OK, I have pulled the log. Hopefully there are some clues…
interfacelog.yaml (63.5 KB)
I didn’t know how to export the logfile, so I pasted it into a text editor and brought it here. it has a yaml extension, but I think you should change the extension to txt.
Did you copy a full log?
I don’t see these messages there:
1 Like
Apologies. I had closed Terminal with the log and saved another one. It should be listed here.
Interfacelog_2.yaml (57.6 KB)
I managed to get them back on board! Using this thread as a reference,
I tried this command and checked the connection with DHCP,
I deleted all the other sys-net files I had created and did a Restart, and was able to get the net connection back. Thank goodness.
Thank you, APPARATUS, for your long hours of help. Now I can resume the PFSense DoH/DoT implementation again!
Be aware that permissive=true option has a downside:
NOTE: The permissive flag increases attack surface and possibility of side channel attacks. While using the no-strict-reset flag, do not require PCI device to be reset before attaching it to another VM. This may leak usage data even without malicious intent. Both permissive and no-strict-reset options may not be necessary and you should try one first, then the other, before using both.
I’d suggest you to first try to use just no-strict-reset=true option:
Get your network card DEVID from the output of this command in dom0 terminal:
qvm-pci ls | grep sys-net
Then run the commands below in dom0 terminal but replace xx_xx.x with DEVID of your network card:
qvm-pci detach sys-net dom0:xx_xx.x
qvm-pci attach -o no-strict-reset=True --persistent sys-net dom0:xx_xx.x
If it won’t work then try to use pci=nomsi kernel option for sys-net:
And only use permissive=true as your last resort if nothing else works.
1 Like
Thank you very much.I got a command not found with qvm-pcils, and I was trying to see if there was some other command,
qvm-pci | grep sys-net
I was able to extract sys-net here. dom0:09_00.0, seems to be my ethernet ID.
As for detaching the devices registered by sys-net, I did it one by one.
qvm-pci detach sys-net
and then
‘qvm-pci attach -ono-strict-reset=True --persistent sys-net dom0:09_00.0’
This successfully registered them again.
I would like to ask you one question: you say that there is a risk of side-channel attacks with the settings you have made this time, but what would an attacker be targeting? This time, I registered an Ethernet device, but was there a vulnerability in the LAN itself?
Actually I was wrong and the best way to try and fix the problem sorted by lowering your security would be this:
pci=nomsi kernel option (most secure) > no-strict-reset=True > permissive=true > permissive=true + no-strict-reset=True (least secure)
no-strict-reset=True has security risk as well, but less than permissive=true.
More info about it here:
In case device reset is disabled for any reason, detaching the device should be considered a risk. Ideally, devices for which the
no-strict-resetoption is set are attached once to a VM which isn’t shut down until the system is shut down.
Additionally, Qubes restricts the config-space a VM may use to communicate with a PCI device. Only whitelisted registers are accessible. However, some devices or applications require full PCI access. In these cases, the whole config-space may be allowed. You’re potentially weakening the device isolation, especially if your system is not equipped with a VT-d Interrupt Remapping unit. This increases the VM’s ability to run a side channel attack and vulnerability to the same. See Xen PCI Passthrough: PV guests and PCI quirks and Software Attacks on Intel VT-d (page 7) for more details.
1 Like