Qubes Windows Tools Network driver issues

jlariviere · July 4, 2022, 4:15pm

I’m running Qubes 4.1. I have some Windows Qubes and followed the directions to install Qubes Windows Tools from the testing repository from this page:

github.com

Qubes-Community/Contents/blob/master/docs/os/windows/windows-tools41.md

Qubes Windows Tools
===================

Qubes Windows Tools (QWT) are a set of programs and drivers that provide integration of Windows 7, 10 and 11 Standalone, TemplateVMs and AppVMs with the rest of the Qubes system. They contain several components than can be enabled or disabled during installation:

- **Shared components (required)** - common libraries used by QWT components
- **Qubes Core Agent** - qrexec agent and services. Needed for proper integration with Qubes
- **Qubes GUI Agent** - video driver and GUI agent that enable the seamless GUI mode that integrates windows apps onto the common Qubes trusted desktop (currently only for Windows 7)
- **Disable UAC** - User Account Control may interfere with QWT and doesn't really provide any additional benefits in Qubes environment
- **Clipboard sender/receiver** - Support for [secure clipboard copy/paste](https://www.qubes-os.org/doc/copy-paste/) between the Windows VM and other AppVMs
- **File sender/receiver** - Support for [secure file exchange](https://www.qubes-os.org/doc/copying-files/) between the Windows VM and other AppVMs
- **Copy/Edit in Disposable VM** - Support for editing files in DisposableVMs as well as for `qvm-run` and generic `qrexec` for the Windows VM (e.g. ability to run custom service within/from the Windows VM)
- **Audio** - Audio support requires R4.1 and is available even without QWT installation if `qvm-features audio-model` is set as `ich6`
- **Xen PV drivers** - drivers for the virtual hardware exposed by Xen for Windows that increase performance compared to QEMU emulated devices and are required for attaching USB devices
   - Base Xen PV Drivers (required): paravirtual bus and interface drivers
   - Xen PV Disk Drivers: paravirtual storage drivers
   - Xen PV Network Drivers: paravirtual network drivers
   - Move user profiles: user profile directory (`C:\users`) is moved to VM's private disk backed by `private.img file` in `dom0` (useful mainly for HVM templates).
	
	> **Note**: Xen PV disk drivers are not installed by default. This is because they seem to cause problems (BSOD = Blue Screen Of Death). We're working with upstream devs to fix this. *However*, the BSOD seems to only occur after the first boot and everything works fine after that. **Enable the drivers at your own risk** of course, but we welcome reports of success/failure in any case (backup your VM first!). With disk PV drivers absent `qvm-block` will not work for the VM, but you can still use standard Qubes inter-VM file copying mechanisms. On the other hand, the Xen PV drivers allow USB device access even without QWT installation if `qvm-features stubdom-qrexec` is set as `1`

This file has been truncated. show original

When I boot into Windows, the network has issues. Windows has an “unidentified network”, no internet access. To get it to work, I have to disable the ‘Xen PV Network Device’, (the VM will freeze), do an emergency pause from Qubes, kill the VM, then restart it, and DO NOT reboot when the prompt comes up saying it needs to reboot to update Xen PV. Networking will work for that session, but on the next boot it will not be working again.

If I remove the Xen PV Network driver, networking will not work at all until QWT is re-installed.

Has anyone else experienced this as well? Any solution? QWT does not appear to have an update (yet).

Thanks!

edit:
Issue occurs on both Windows 10 and Windows 11

hind0 · July 31, 2022, 4:42am

Hey thanks for outlining this issue, I’m having the same problem. Did you ever find a better solution or have any new info? In the meantime I might try installing the driver on a template and running it in an appvm and seeing if that could work as a hacky fix.

Update:
It doesn’t work. The idea was that I could get the template vm frozen in whatever state it is in when the session works, but I guess whatever it is is obviously changed when the vm is shutdown.

hind0 · July 31, 2022, 4:50am

It is weird though. I actually have a windows vm working with the driver, but if I clone it, the clones network do not work.

hind0 · July 31, 2022, 5:42am

Nevermind to all of the above…

I̶ ̶j̶u̶s̶t̶ ̶t̶e̶s̶t̶e̶d̶ ̶i̶t̶ ̶a̶g̶a̶i̶n̶ ̶a̶n̶d̶ ̶t̶h̶e̶ ̶c̶l̶o̶n̶e̶’s̶ ̶n̶e̶t̶w̶o̶r̶k̶ ̶d̶o̶ ̶w̶o̶r̶k̶.̶̶W̶h̶a̶t̶ ̶d̶o̶e̶s̶n̶’̶t̶ ̶w̶o̶r̶k̶ ̶i̶s̶ ̶s̶o̶m̶e̶ ̶m̶o̶d̶i̶f̶i̶e̶d̶ ̶v̶m̶ ̶I̶ ̶r̶a̶n̶ ̶s̶o̶m̶e̶ ̶d̶e̶b̶l̶o̶a̶t̶ ̶s̶c̶r̶i̶p̶t̶s̶ ̶o̶n̶.̶ ̶S̶o̶ ̶I̶ ̶s̶u̶s̶p̶e̶c̶t̶ ̶t̶h̶a̶t̶ ̶i̶t̶ ̶i̶s̶ ̶t̶h̶e̶ ̶c̶a̶u̶s̶e̶.̶

Hmm, actually as I’m typing this I see the network on the cloned vm has turned off. I have rebooted it and it doesn’t seem to connect at all. So I guess my observation of it being on was an outlier. I don’t know what could possibly be causing that (vm network is working, clone it and then the clone does not except for one brief one-off moment).

Some extra info:

The clone should be exactly the same, I didn’t modify it.
I shutdown the currently running VM before I boot the other vm.

I have another set of windows vm’s (so I have two sets, each set is just one vm cloned a couple of times), whixh contains the vms which I ran debloater/optimizarion scripts. For that one, it is only the 1st clone that gets network access. One thing different about that set was I hadn’t specified a NetVM for the initial vm, and I think that 1st clone was the first of the set to be assigned to a NetVM. So maybe that is a clue and could somehow pinpoint to the cause of the issue?
Although for the cause of the second set, it could be due to the debloater acripts as that also diffeeentiates the two vms (I ran the debloater script on the initial vm and left the clone untouched). Buf if so, that doesn’t explain the issue with clones not working.

GWeck · July 31, 2022, 11:04am

Did you check the IP addresses of the clones? If they are different, i.e. each one has a new address, this would collide with the manual IP address setup for the network interface within the Windows VM. That’s a constant source of trouble.

hind0 · July 31, 2022, 5:45pm

Thanks that clears up my confusion with the cloned vms.
I’ve got them to work now by correctly updating the ip by setting it as static, and it is only the vm who has run optimize/debloat scripts which still doesn’t work.

Just out of curiosity, do you know why windows cannot determine the correct one by default?
I noticed the freshly cloned vm uses the old vms ip configuration, but if I update it by setting it as static, and then switching back to automatically obtain addresses, then the addresses are completely different.

GWeck · August 1, 2022, 1:04pm

Setting automatic IP in Windows (and also in Linux) VMs let the VM expect to get the correct IP address via DHCP, the server being sys-firewall, which works well for Linux VMs. For Windows VMs, however, this sometimes does not work (for reasons unknown to me), resulting in some more or less random default IP address.

unman · August 6, 2022, 10:59am

DHCP for qubes is quite fragile for other standalones, not just Windows.
In many cases I have to manually set networking.