Recommendations for fully compat Wireless/my usb errors

sevas

unread,

Mar 8, 2018, 3:25:12 AM3/8/18

to qubes-users

Been looking through the files and google trying to find out how to make my USB wireless card work. I didnt try no-strict-reset or permissive mode because it said something something SECURITY something and so I skipped over it without a second thought.

After hours and hours of troubleshooting, I realize that that was my problem. I needed no-strict-reset because of FLR. I have no idea what FLR is.

Bus 001 Device 006: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter

I guess thats my card. One of those RT numbers.

Anyway. I have a few questions.

Question 1: Should I fix my wireless card with a car or a hammer?

Question 2: What kind of wireless card should I buy or what should I be on the lookout for to make sure its compatible with qubes? (long range for bonus pts!)

Question 3: What kind of security am I forfeiting when I use this frothy no-strict-reset card?

Question 4: Is there anything I can do for my card? Heres the error output:

I think one of these 1st two sections is the output when the VM is already started and I attach the device and the other is when I start it with the device already attached. Or maybe not. It could the the before and after of
dom0$ qvm-prefs -s netvm kernelopts "iommu=soft swiotlb=16384" Who knows.... Not me, I mean.

dom0 lvm[923]: Monitoring thin pool qubes_dom0-pool00-tpool.
dom0 qubesd[9781]: b' WARNING: Sum of all thin volume sizes (328.68 GiB) exceeds the size of thin pool qubes_dom0/pool00 and the size of whole volume group (166.68 GiB)!\n'
dom0 dmeventd[923]: No longer monitoring thin pool qubes_dom0-pool00-tpool.
dom0 lvm[923]: Monitoring thin pool qubes_dom0-pool00-tpool.
dom0 qubesd[9781]: b' WARNING: Sum of all thin volume sizes (338.68 GiB) exceeds the size of thin pool qubes_dom0/pool00 and the size of whole volume group (166.68 GiB)!\n'
dom0 libvirtd[9825]: 2018-03-08 05:27:18.209+0000: 9861: error : virPCIDeviceReset:1002 : internal error: Unable to reset PCI device 0000:00:14.0: no FLR, PM reset or bus reset available
dom0 qubesd[9781]: Start failed: internal error: Unable to reset PCI device 0000:00:14.0: no FLR, PM reset or bus reset available
dom0 dmeventd[923]: No longer monitoring thin pool qubes_dom0-pool00-tpool.

This was definitely during attach while VM running:
ERROR: Devices tab: Got empty response from qubesd. see journalctl in dom0 for details.
followed by:
dmesg:
[ 122.885838] xhci_hcd 0000:00:14.0: USB bus 2 deregistered
[ 122.889909] xhci_hcd 0000:00:14.0: remove, state 1
[ 122.889917] usb usb1: USB disconnect, device number 1
[ 122.889918] usb 1-5: USB disconnect, device number 2
[ 122.982262] usb 1-6: USB disconnect, device number 3
[ 122.982600] usb 1-7: USB disconnect, device number 4
[ 122.984305] xhci_hcd 0000:00:14.0: USB bus 1 deregistered
[ 122.984842] kauditd_printk_skb: 5 callbacks suppressed
[ 122.984843] audit: type=1130 audit(1520492985.409:136): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 122.989660] pciback 0000:00:14.0: seizing device

Yuraeitha

unread,

Mar 8, 2018, 4:02:32 AM3/8/18

to qubes-users

I think what you need to do here is merge the sys-net with your sys-usb. I'm not 100% sure since I don't use usb-modems my self on Qubes, but with an USB modem, you're probably supposed to keep that USB controller in sys-net AppVM. You could also alternatively install the Qubes VM network management tools in sys-usb, but that might cause undeeded complexities. It might just be easier to move your USB controller to the sys-net AppVM.

If you got multiple USB controllers, then you can keep one USB controller in sys-net, and the other(s) in your sys-usb on the safe side of the firewall. Unfortunately you'll have to keep at least one USB controller in sys-net, or an VM like it. Careful not to try to enable USB modems on the wrong side of the firewall btw.

Yuraeitha

unread,

Mar 8, 2018, 4:04:23 AM3/8/18

to qubes-users

On Thursday, March 8, 2018 at 9:25:12 AM UTC+1, sevas wrote:

Definitely never try get usb-modems working if your USB controller is still in dom0 though, if you get that working, then you're exposing all of dom0 to the internet directly.

awokd

unread,

Mar 8, 2018, 5:17:14 AM3/8/18

to Yuraeitha, qubes-users

On Thu, March 8, 2018 9:02 am, Yuraeitha wrote:
> On Thursday, March 8, 2018 at 9:25:12 AM UTC+1, sevas wrote:

>> After hours and hours of troubleshooting, I realize that that was my
>> problem. I needed no-strict-reset because of FLR. I have no idea what
>> FLR is.
>>
>>
>> Bus 001 Device 006: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070
>> Wireless Adapter

>>

>> Question 1: Should I fix my wireless card with a car or a hammer?

Go ahead and try the no-strict-reset option.

>> Question 2: What kind of wireless card should I buy or what should I be
>> on the lookout for to make sure its compatible with qubes? (long range
>> for bonus pts!)

Try looking through the HCL for known good ones, or picking one and
searching the mailing list for reported problems. There's no HCL for PCI
devices, but I'm wondering if it might be good to have one.

>> Question 3: What kind of security am I forfeiting when I use this
>> frothy no-strict-reset card?

See the link in the same doc.

>> Question 4: Is there anything I can do for my card? Heres the error
>> output:

#1

> I think what you need to do here is merge the sys-net with your sys-usb.

That might also resolve the issue if both controllers are reported as
being under the same device, but in this case I think trying
no-strict-reset first is probably worthwhile.

Yuraeitha

unread,

Mar 8, 2018, 5:46:55 AM3/8/18

to qubes-users

@awokd
Agreed, it's not clear what is causing the issue, trying these suggestions definitely could work too.

@sevas
I definitely agree with awokd that you can put the no pci reset, he makes a good point here. If you came from a more unsecure OS anyway before you went Qubes, and you're not putting your life or well-being on the line, then you can probably take bit bigger risks like this one. The exploits through firmware is more exotic attacks in this day and age, but that might change in the future if they become more commonplace, i.e. by A.I's automatically finding exploits in the many, many different firmwares, and turns this from an exotic attack into a common and everyday type of attack. Generally though, if you're not putting something on the line here, you can afford to make mistakes and learn a bit, mistakes are the best learners after all, just as long as you can afford the consequences of course. Just keep in mind that it's important that you improve these things over time and never just settle, small stepes, rom wasn't build in a single day, so too is your Qubes usage going to improve over time as well if you keep learning small bits every day. Lax a bit down now on these issues, and try find out why and how they work, so you can increase your knowledge of security. Try identify the biggest threats first, and keep the lower ones for later, prioritizing to maximize your IT security understanding as time goes on.

Reply all

Reply to author

Forward