On Thursday, November 23, 2017 at 1:50:53 AM UTC+2, Yuraeitha wrote: > On Wednesday, November 22, 2017 at 11:13:35 PM UTC, beso wrote: > > On Thursday, November 23, 2017 at 1:07:28 AM UTC+2, Yuraeitha wrote: > > > On Wednesday, November 22, 2017 at 10:49:46 PM UTC, beso wrote: > > > > On Thursday, November 23, 2017 at 12:37:59 AM UTC+2, Yuraeitha wrote: > > > > > On Wednesday, November 22, 2017 at 10:03:22 PM UTC, beso wrote: > > > > > > On Wednesday, November 22, 2017 at 11:49:16 PM UTC+2, Yuraeitha > > > > > > wrote: > > > > > > > On Wednesday, November 22, 2017 at 9:37:38 PM UTC, beso wrote: > > > > > > > > On Wednesday, November 22, 2017 at 11:22:47 PM UTC+2, Yuraeitha > > > > > > > > wrote: > > > > > > > > > On Wednesday, November 22, 2017 at 9:11:18 PM UTC, beso wrote: > > > > > > > > > > On Wednesday, November 22, 2017 at 5:48:43 PM UTC+2, beso > > > > > > > > > > wrote: > > > > > > > > > > > On Wednesday, November 22, 2017 at 3:00:41 PM UTC+2, beso > > > > > > > > > > > wrote: > > > > > > > > > > > > On Monday, October 2, 2017 at 2:06:38 PM UTC+3, beso > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Monday, October 2, 2017 at 12:01:41 AM UTC+3, > > > > > > > > > > > > > One7two99 wrote: > > > > > > > > > > > > > > Hello Beso, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Mobile Broadband is enabled in > > > > > > > > > > > > > > > NetworkManager Applet. > > > > > > > > > > > > > > > I can create new Mobile Broadband > > > > > > > > > > > > > > > connection but it keeps connecting > > > > > > > > > > > > > > > and nothing else > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am using mobile broadband within Qubes and am > > > > > > > > > > > > > > happy to help, but honestly your question/problem > > > > > > > > > > > > > > is to unqualified. > > > > > > > > > > > > > > > > > > > > > > > > > > > > - 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] > > > > > > > > > > > > > > > > > > > > > > > > > > - 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 > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > sudo dmesg: > > > > > > > > > > [ 3847.841147] NetworkManager[6145]: segfault at 38 ip > > > > > > > > > > 0000732046957569 sp 00007ffe0cc871f0 error 4 in > > > > > > > > > > libnm-wwan.so[732046950000+11000] > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > 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) > > > > > > > > > > > > > > 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. > > > > > > > > > > > > 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) > > > > > > > > > > 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. > > > > > > > > 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' > > > > > > 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. > > > > I have Logitech mouse which works perfectly. > > 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.
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. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/030860f3-d6e6-444d-bc68-7bec47e6c7f4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
