Mobile broadband-not enabled
beso
One7two99
- what version of Qubes are you running?
- what modell of mobile broadband card are you using?
- how is the broadband card connected? Probably as an internal USB device.
- are you using sys-usb to connect the card to your sys-net VM? Or are you passing through the whole USB controller?
- have you tried to boot up a Fedora live Linux and check if your mobile broadband is working there?
- what does "keeps connecting" means?
My suggestion:
Try to get the mobile broadband card working without Qubes (Linux Live Boot from USB-Stick).
If you got it working try to make it work in Qubes.
[799]
beso
- Laptop is ThinkPad X1 Carbon 4th gen.
- Qubes release 3.2(R3.2)
- Previous linux distros worked (ubuntu 16.04)
- from qvm-usb I can see that card is: Sierra Wireless Incorporated Sierra Wireless EM7455 Qualcomm Snapdragon X7
- do I have to attach it somewhere?
- As I mentioned I can create new broadband connection and even select it from applet menu but it keeps connecting(applet shows "circles" as trying connect).
I am trying to make screenshot if it helps
beso
PS.
[user@sys-net ~]$ ifconfig
enp0s1f6: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether 54:ee:75:aa:4d:e3 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 26 memory 0xe1200000-e1220000
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 636 bytes 74412 (72.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 636 bytes 74412 (72.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vif2.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.137.1.1 netmask 255.255.255.255 broadcast 0.0.0.0
inet6 fe80::fcff:ffff:feff:ffff prefixlen 64 scopeid 0x20<link>
ether fe:ff:ff:ff:ff:ff txqueuelen 32 (Ethernet)
RX packets 102007 bytes 32168371 (30.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 228493 bytes 219299357 (209.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlp0s2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.43.181 netmask 255.255.255.0 broadcast 192.168.43.255
inet6 fe80::e6a4:71ff:fe8a:d310 prefixlen 64 scopeid 0x20<link>
ether e4:a4:71:8a:d3:10 txqueuelen 1000 (Ethernet)
RX packets 238240 bytes 225553537 (215.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 108834 bytes 37072683 (35.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
beso
sudo dmesg:
[ 3847.841147] NetworkManager[6145]: segfault at 38 ip 0000732046957569 sp 00007ffe0cc871f0 error 4 in libnm-wwan.so[732046950000+11000]
Yuraeitha
Yes, because you passed the USB controller to your sys-USB, correct? In that case, that means if you attach an USB modem, it'll be passed to your sys-USB, and not your sys-net that should have the internet device instead.
The solution could be to merge your sys-net with sys-usb, though, I never felt truly safe having my USB exposed like that. Though logically speaking, its not anymore exposed in sys-net, than compared with any other non Qubes-OS system out there. Either way, I believe this is pretty likely your problem.
Try test it first, you can worry about the security after wards.
See if it works if you passthrough your USB controller to your sys-net instead, and then try apply your USB modem there.
If it still doesn't work, then it's probably either (in order of likelihood, the first is most likely imho).
- No driver/module for your USB modem. It may be visible in i.e. "lspci", but it'll have no functionality, no less any signal.
- PCI strictness is too strict, and qvm-prefs strictreset option set to false is not enough.
- Pass-through is not supported in your USB modem.
But these potential issues, you only need to worry about, after you get USB into sys-net, instead of sys-usb.
Yuraeitha
Also, if you have multiple of USB controllers, try sacrifice one controller to sys-net, while keeping the remaining in sys-usb.
I believe you have a laptop since you want to use an USB modem, but even laptops tend to have at least two USB controllers now a days and some years back.
So verify how many USB controllers you got (NOT! ports, but controllers, that is to be blond, how many USB controlling chips are there in your hardware). Many developers like to put multiple of ports on a single controller. Be sure you got more than one controller, and then only pass one of them to your sys-net, and keeping the other in sys-usb.
Then in practice, avoid any USB ports used for the exposed USB controller, and then keep remaining USB controllers in the safer sys-usb.
beso
It is too "much" for me. It means, too complicated. I only have sys-net, no separated sys-usb. As I understand all my usb-s connected to sys-net (attached picture previous post) I will mpost my outputs below form sys-net:
lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 006: ID 138a:0090 Validity Sensors, Inc.
Bus 002 Device 005: ID 13d3:5248 IMC Networks
Bus 002 Device 004: ID 8087:0a2b Intel Corp.
Bus 002 Device 003: ID 1199:9079 Sierra Wireless, Inc.
Bus 002 Device 002: ID 046d:c52f Logitech, Inc. Unifying Receiver
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
lspci:
00:00.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:01.6 Ethernet controller: Intel Corporation Ethernet Connection I219-V (rev 21)
00:02.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
Yuraeitha
Not a problem if its new to you, I'm not an expert my self, although I have some, albeit limited, experience. We can try see if we can work it out, and there is also the chances someone more knowledgeable dropping by with a solution. But lets try have a crack at it meanwhile. I do believe it should be fixable, unless its lack of driver/hardware support within the USB modem itself in regards to virtualization technology. Lets hope this is not the case, otherwise you got a problem.
Okay so, you did a lspci, and we can see you have a USB 3.0 xHCI Controller.
It looks like you ran lspci in a virtual machine, correct? Try again in dom0 instead, this way we can see all the controllers, not just the ones passed into your VM. What I'm curious about, is if you got more than one controller, and it looks like you might, since there is often a USB 2.0 controller next to a USB 3.0 controller. But we need to be sure first.
At which case, if you do, then you can simply pass your USB 2.0 controller to your sys-net, and only use your USB 2.0 ports for your internet modem, nothing else. Keep every other USB activity to your faster USB 3.0 port.
The lsusb is also from the terminal inside your VM right? It does look like the driver/module at least works to some extent, perhaps even fully. Which is a good sign. But first things first.
beso
Correct, previous were from sys-net vm.
dom0 lspci is:
00:00.0 Host bridge: Intel Corporation Skylake Host Bridge/DRAM Registers (rev 08)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07)
00:08.0 System peripheral: Intel Corporation Skylake Gaussian Mixture Model
00:13.0 Non-VGA unclassified device: Intel Corporation Device 9d35 (rev 21)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 21)
00:1c.0 PCI bridge: Intel Corporation Device 9d10 (rev f1)
00:1c.2 PCI bridge: Intel Corporation Device 9d12 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection I219-V (rev 21)
02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader (rev 01)
04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
Yuraeitha
hmm, so you only have one controller, which is an integrated USB 2 and USB 3 controller. That's unfortunate, but not the end, it just means we have to find another way. I've seen the same recently for USB 3.0 and USB 3.1. Is your machine a new machine, by any chance? Perhaps the same merger trend is happening for USB 2 and USB 3. But this doesn't matter, fact is, you only have one USB controller, and we gotta make due with what can be made due with.
By the way,
04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
Is this an on-board wireless card by any chance? or is this the plugged in USB modem? I assume its your USB modem being shown there. If its sitting in your USB port while you used lspci, then it is your USB modem you can see there. You may be able to passthrough your USB modem because it contains a controller too, instead of your USB controller. This way, you are not sacrificing your USB to sys-net. The question is if this will work, there is a good chance that it might.
Did you passthrough the USB card or the wireless card previously?
Also, I believe it may cause issues if you try to pass both USB Controller and the USB wireless card. Because if both are passed, then (to my understand), they can't talk to each others anymore. So you must only pass one of them. Preferably the Wireless Network Controller.
Also if there is any memory chips in the USB controller or the Wireless network controller, and they do not support PCI Reset. Then you need to restart your machine to be sure the system can switch the PCI device to the VM after having been away from dom0 (that is, another or even sometimes the same VM). There is an approach to avoid restart, but its less secure, and frankly, its just much faster to simply restart. If you're unsure if it has PCI reset, doesn't matter, faster and simpler to just restart to fix. Basically, restart fixes all these types of PCI reset issues.
So, try this out, pass your
- 04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
to your sys-net.
- Make sure no other hardware is passed to it, remove any other, especially the USB Controller.
- Now try shut down Qubes, and start it up again. Try see if you can get any signals now.
- We might need extra steps, like a driver maybe, or change pci reset strictness, but lets try this first before we try additional steps.
Yuraeitha
My apologies, I confused Wi-FI with Mobile brand. I'm pretty darn tired and exhausted. Of course
04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
is Wi-Fi controller, and not a Mobile USB controller.
My bad. Still, do you see the USB modem in lspci if you plug it in? You might have to restart if you have just used your USB controller on a VM. And be sure you run lspci before any VM with the USB controller starts.
If it still doesn't appear in the list, then you might have to use your USB Controller in your sys-net instead.
beso
Laptop is 4th gen. Thinkpad Carbon. It has built-in wwan. There is nothing I can plug. I can also give next output I found from net.
mmcli -m /org/freedesktop/ModemManager1/Modem/0:
/org/freedesktop/ModemManager1/Modem/0 (device id '470d21e64cbf0d90b7e3aff526483e7aa8e11c43')
-------------------------
Hardware | manufacturer: 'Generic'
| model: 'MBIM [1199:9079]'
| revision: 'SWI9X30C_02.20.03.00'
| supported: 'gsm-umts, lte'
| current: 'gsm-umts, lte'
| equipment id: '014582001591578'
-------------------------
System | device: '/sys/devices/pci-0/pci0000:00/0000:00:00.0/usb2/2-2'
| drivers: 'cdc_mbim'
| plugin: 'Generic'
| primary port: 'cdc-wdm0'
| ports: 'cdc-wdm0 (mbim), wwp0s0f0u2i12 (net)'
-------------------------
Numbers | own : 'unknown'
-------------------------
Status | lock: 'none'
| unlock retries: 'sim-pin2 (3)'
| state: 'disabled'
| power state: 'low'
| access tech: 'unknown'
| signal quality: '0' (cached)
-------------------------
Modes | supported: 'allowed: 3g, 4g; preferred: none'
| current: 'allowed: 3g, 4g; preferred: none'
-------------------------
Bands | supported: 'unknown'
| current: 'unknown'
-------------------------
IP | supported: 'ipv4, ipv6, ipv4v6'
-------------------------
3GPP | imei: '014582001591578'
| enabled locks: 'fixed-dialing'
| operator id: 'unknown'
| operator name: 'unknown'
| subscription: 'unknown'
| registration: 'unknown'
-------------------------
SIM | path: '/org/freedesktop/ModemManager1/SIM/0'
-------------------------
Bearers | paths: 'none'
Yuraeitha
I made an extra post same time you posted, so I withdrew it as it became unuseful with this new information.
Integrated eh, well that explains a bit :)
From your output, the line
device: '/sys/devices/pci-0/pci0000:00/0000:00:00.0/usb2/2-2'
Seems to indicate that your internal integrated Mobile card is run over an internal USB.
This is similar to my Qubes tablet, where my touchscreen is tied to my USB. If I try to pass my USB to a VM, I then loose all touch input.
Similar in your case, if anything else is tied to USB, it will follow wherever you pass your USB. This means, if you pass your USB, it should make your integrated device: '/sys/devices/pci-0/pci0000:00/0000:00:00.0/usb2/2-2' follow your USB into that VM.
Question is, whether your hardware support this or not, it was much simpler when it was just an USB controller. This integrated hardware tied to your USB, may or may not complicate it.
At least I think it's tied to your USB; given that the IP address is written in zero's, which suggests it's like a dummy PCI address for the internet mobile chip, since it's actually using the USB pci address instead.
Okay, lets try this instead.
- Pass your USB Controller to your sys-net VM.
- Try put in a different USB device, like a flash pen, or USB external harddrive, something that can verify if your USB passthrough works in sys-net. Be sure you remove it properly when its time to remove it, if its anything with important data on, better use an empty one to be safe. First remove within the VM, then outside the VM afterwards, always in this order.
- If it doesn't work, then try restart, and try again, see if it works.
- If it still doesn't work, then there is something wrong with the USB. This may explain the issue, but on the other hand, if your USB works, then it indicates another issue.
Putting it into perspective, assuming your Mobile is tied to your USB controller, whether your USB controller works in sys-net is therefore assumed to be pretty essential. Finding out whether the USB itself works or not for other USB devices in the sys-net, provides us with new information and new approaches we can try.
beso
I have Logitech mouse which works perfectly.
Yuraeitha
oh I see, this leaves me a little puzzled.
Is your USB Controller always in the sys-net? That solves some mysteries. I guess you must be using the backward mouse signal to dom0 Qubes feature.
I assume the lspci and lsusb, was run inside the sys-net VM, and not any other VM, and that this is still the case now, correct?
If so, then your mobile chip should already be in contact with sys-net. Which probably means either of the few possibilities
Fault reason 1) Strict reset issues.
Fault reason 2) Mobile chip is without a supported driver or module.
Fault reason 3) Mobile chip does not support virtualization.
Fault reason 1):
Try run "qvm-prefs sys-net pci_strictreset" in dom0, tell the output here. It'll either say False, or True. If it's false, then there is nothing to change. If it says true, then try put it to false. This is a quick try fix, it's a longshot since I believe sys-net does this automatically, but it's easy to quickly check if it's set to false or true.
Now, about the fault 2), the possibility of a faulty driver:
Since you mentioned it worked in Ubuntu 16, perhaps it's not a driver issue. If you are serious about trying to get this to work, perhaps it's a good idea to try take an Ubuntu live boot media (dont install, just a live media), and then once more test if it works in Ubuntu. Once confirming it works, try find out which driver or module Ubuntu is using.
If this is the same driver that Qubes uses inside the sys-net VM, and you're sure it's tied to the USB controller, and you're sure the USB controller is properly connected to your sys-net. Then that seems like it only leaves one explanation, that the mobile chip does not support virtualization.
Another approach to fault 2), could be to try use debian as your sys-net. Because Ubuntu is based on debian, debian might have a module that works better, than the one used in fedora. The drivers inside the kernel should be the same, but to my understanding, the modules may vary from distribution to distribution (I'm a little unsure how it works in details, but anyway). Be mindful that I do not know if its a good idea to go around and change to debian for sys-net, I have no idea what this might or might not do to the Qubes tools in your sys-net. Maybe, you can make a backup of your sys-net and sys-firewall, just in case, to be safe in case your internet breaks by doing this approach. If you dont want to risk anything, then only use the Ubuntu live boot method, and avoid this approach.
Fault 3)
Basically, if none of the two method works, then it seems like the mobile chip lack virtualization support, possibly due to the driver code it uses. This is why you need to find out which driver is working (i.e. live Ubuntu uses), because this way, you can find out if its a driver or module issue, or not.
If not, then that leaves the last possibility, that it's not supporting virtualization. That is, under the assumption, that your mobile chip indeed is tied directly to your USB controller.
beso
1) Command "qvm-prefs sys-net pci_strictreset" got me "false"
2) This internal wwan worked with ubuntu 16.04
At the moment I tried with my external usb gsm stick and it works. So I use now workaround.
Many thanks for Your assistance.
Yuraeitha
Awesome that you found a work around!
btw a minor thing to keep in mind, after the template the USB is tied to gets updated, you might want to try again, like if Fedora 23 to Fedora 25, or Fedora to Fedora 26/27, or if there is a kernel upgrade in general for that VM. It might fix the issue assuming its a driver/module that previously did not work well with virtualization. But that might, or might not, change over time, especially if its a new device.