Re: Gobi 3000 (1199:901F)
On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: > On 01/09/2015 02:24 PM, Dan Williams wrote: > > On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: > >> On 01/09/2015 12:01 PM, Jeremy Moles wrote: > >>> Hey everyone! I'm not entirely sure where else to ask this, and I'm > >>> somewhat desperate at this point having tried everything I'm capable of. > >>> > >>> We have a machine here with the card listed in the subject. It shows > >>> up in lsusb as: > >>> > >>> 1199:901f Sierra Wireless, Inc. > >>> > >>> It will work in Linux so far if--and ONLY IF--you boot into Windows > >>> first and then soft reboot into Linux. it appears that Windows does > >>> something to the modem that Linux (currently) does not, and I was > >>> wondering if anyone here had any advice on what I might try. > >>> > >>> What I've done so far: > >>> > >>> 1) There is a knob in the sysfs hierarchy for this device that lets me > >>> change the "config" (or something like that, I'm actually working on > >>> this machine remotely and the customer isn't available right now!) > >>> from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after > >>> doing so the tty's appear and the device is ready to be perturbed. It > >>> responds to ATI commands and whatnot, but again, won't work properly > >>> unless booted in Windows first. I should mention I found this knob > >>> entirely by accident while hacking on qcserial and trying to accept > >>> different "port" numbers as they enumerated themselves... > >>> > >>> 2) I downloaded the CodeAurora GobiSerial driver (which, according to > >>> the changelog has a fix for "powering on" a device) and modified it to > >>> work with 3.17 and 3.18 kernels (essentially, this involved > >>> re-exporting usb-serial.c symbols like usb_serial_probe the code > >>> relied on). However, I haven't had a chance to try this yet, and I'm > >>> not entirely convinced (after looking through the code) it really does > >>> anything qcserial doesn't. > >>> > >>> Anyways, if anyone has any advice, please let us know! > >>> ___ > >>> networkmanager-list mailing list > >>> networkmanager-list@gnome.org > >>> https://mail.gnome.org/mailman/listinfo/networkmanager-list > >>> > >> I should also mention I JUST found this thread: > >> > >> http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html > >> > >> Which explains exactly what I was seeing when talking about my #1 > >> attempt (the config option in sysfs; again, it's miraculously I found > >> that at all). > >> > >> I can't piece together everything the thread is talking about, but it > >> may job someone's memory. I can also try e-mailing the author of that > >> thread directly. > > When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? > > Also grab 'dmesg' output to see what driver messages there are. Next, > > if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and > > lets see what we have. > > > > Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list > > -m 0' in case the previous one didn't work. > > > > Dan > > > > Thank you for your reponse, Dan. I've attached the information you asked > for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd > at your leisure. > > You'll notice how the 'power-state' differs depending on the boot type. > Also, the --firmware-list command failed to run, saying: > > error: modem has no firmware capabilities Yeah, I see now that the modem is using QMI instead of MBIM. So instead, try these twice, once under Linux and once after rebooting from Windows: qmicli -d /dev/cdc-wdm0 --dms-list-stored-images qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode qmicli -d /dev/cdc-wdm0 --dms-get-revision THe other possibility is that the machine's rfkill handling isn't known to Linux, but since Windows knows, when you warm-boot to Linux the WWAN rfkill is disabled. What model laptop is this? (if it's a laptop) Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Aw: Re: Re: Only root can utilize nm-applet and nmcli as part of NetworkManager - how can other users use it w/o root?
On Sat, 2015-01-10 at 14:12 +0100, Thomas Schneider wrote: > Hi! > > I checked if this could be related to pklocalauthority that is > documented here > (http://www.freedesktop.org/software/polkit/docs/0.105/pklocalauthority.8.html) > > Checking the relevant config file for NetworkManager looks good to me. > But it's not clear why manfred cannot utilize NetworkManager as he > belongs to group netdev. > > user@pc1-asus:~$ sudo > cat > /var/lib/polkit-1/localauthority/10-vendor.d/org.freedesktop.NetworkManager.pkla > [Adding or changing system-wide NetworkManager connections] > Identity=unix-group:netdev;unix-group:sudo > Action=org.freedesktop.NetworkManager.settings.modify.system > ResultAny=no > ResultInactive=no > ResultActive=yes > > user@pc1-asus:~$ id manfred > uid=1005(manfred) gid=1005(manfred) > Gruppen=1005(manfred),117(netdev),1013(verwandte),126(tbb),127(openvpn),128(fcron) Try this: pkaction -v -a org.freedesktop.NetworkManager.settings.modify.system What do you get when running this as the user 'manfred'? Also when you do this, please grab the results of 'loginctl show-session X' where X is the session for 'manfred'. I know you sent the mail to me private with this output, but I want to make sure that loginctl and pkaction output is from the same run. Thanks! Dan > Should I now go with the new compilation of NetworkManager using > --with-session-tracking=[ck|systemd]? > Is there a way to identify which options have been used with the > packaged shipped by the distribution? > > THX > > Gesendet: Freitag, 09. Januar 2015 um 23:13 Uhr > Von: "Dan Williams" > An: "Thomas Schneider" > Cc: poma , networkmanager-list@gnome.org > Betreff: Re: Aw: Re: Only root can utilize nm-applet and nmcli as part > of NetworkManager - how can other users use it w/o root? > On Fri, 2015-01-09 at 20:49 +0100, Thomas Schneider wrote: > > Hi, > > > > here's an update on your questions > > > > Let's start with the version of nmcli: > > user@pc1-asus:~$ nmcli -v > > nmcli-Werkzeug, Version 0.9.10.0 > > > > Now permissions: > > user@pc1-asus:~$ nmcli general permissions > > BEFUGNIS WERT > > > > org.freedesktop.NetworkManager.enable-disable-network nein > > Ok, this indicates that PolicyKit is denying the permissions to these > users. The most likely reason is that NM has been built with > --with-session-tracking=[ck|systemd] and something is not properly > setting up the login sessions with ConsoleKit or systemd. > > PolicyKit has a concept of active (eg, using the computer right now) > and > inactive (idle or non-human users) sessions. NetworkManager uses these > for fast-user-switching and some permissions control. It's likely that > all users on your machine are considered "inactive" according to > PolicyKit and thus being denied. > > What do you get for the following commands? > > ck-list-sessions > loginctl > loginctl show-session X (repeat for all sessions from 'loginctl') > > if you're using ConsoleKit, your session manager needs to tell > ConsoleKit that it's starting a new session. I'm not quite sure how > that happens with systemd, but it does somehow. > > Alternatively, if you don't care about user permissions and want to > allow any user to control networking you can build NM with > --with-session-tracking=none and --with-polkit=no to disable this > functionality. > > Dan > > > org.freedesktop.NetworkManager.enable-disable-wifi nein > > > > org.freedesktop.NetworkManager.enable-disable-wwan nein > > > > org.freedesktop.NetworkManager.enable-disable-wimax nein > > > > org.freedesktop.NetworkManager.sleep-wake nein > > > > org.freedesktop.NetworkManager.network-control nein > > > > org.freedesktop.NetworkManager.wifi.share.protected nein > > > > org.freedesktop.NetworkManager.wifi.share.open nein > > > > org.freedesktop.NetworkManager.settings.modify.system nein > > > > org.freedesktop.NetworkManager.settings.modify.own Legitimierung > > org.freedesktop.NetworkManager.settings.modify.hostname > Legitimierung > > > > Output when running nm-applet w/o root permission: > > user@pc1-asus:~$ nm-applet > > (nm-applet:1167): libnm-glib-CRITICAL **: nm_secret_agent_register: > > assertion 'priv->registered == FALSE' failed > > (nm-applet:1167): nm-applet-WARNING **: VPN Connection activation > > failed: (org.freedesktop.NetworkManager.PermissionDenied) Not > > authorized to control networking. > > > > Error message in /var/log/syslog: > > Jan 9 20:41:34 pc1-asus NetworkManager[5393]: Failed to > > activate 'Netzwerk-Thomas-VPN': Not authorized to control > networking. > > > > The current config file for the required VPN connection is: > > user@pc1-asus:~$ sudo cat /etc/NetworkManager/system-connections/VPN > > [connection] > > id=VPN > > uuid=a6ae2fac-4776-4f74-962c-a63113xx > > type=vpn > > permissions=user::; > > autoconnect=false > > [vpn] > > service-type=org.freedesktop.NetworkManager.openvpn > > connection-type=tls > > auth=SHA256 > > remote= > > cipher=AES-256-CBC > > comp-lzo=
Re: Gobi 3000 (1199:901F)
On 01/12/2015 10:46 AM, Dan Williams wrote: On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: On 01/09/2015 02:24 PM, Dan Williams wrote: On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: On 01/09/2015 12:01 PM, Jeremy Moles wrote: Hey everyone! I'm not entirely sure where else to ask this, and I'm somewhat desperate at this point having tried everything I'm capable of. We have a machine here with the card listed in the subject. It shows up in lsusb as: 1199:901f Sierra Wireless, Inc. It will work in Linux so far if--and ONLY IF--you boot into Windows first and then soft reboot into Linux. it appears that Windows does something to the modem that Linux (currently) does not, and I was wondering if anyone here had any advice on what I might try. What I've done so far: 1) There is a knob in the sysfs hierarchy for this device that lets me change the "config" (or something like that, I'm actually working on this machine remotely and the customer isn't available right now!) from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after doing so the tty's appear and the device is ready to be perturbed. It responds to ATI commands and whatnot, but again, won't work properly unless booted in Windows first. I should mention I found this knob entirely by accident while hacking on qcserial and trying to accept different "port" numbers as they enumerated themselves... 2) I downloaded the CodeAurora GobiSerial driver (which, according to the changelog has a fix for "powering on" a device) and modified it to work with 3.17 and 3.18 kernels (essentially, this involved re-exporting usb-serial.c symbols like usb_serial_probe the code relied on). However, I haven't had a chance to try this yet, and I'm not entirely convinced (after looking through the code) it really does anything qcserial doesn't. Anyways, if anyone has any advice, please let us know! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list I should also mention I JUST found this thread: http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html Which explains exactly what I was seeing when talking about my #1 attempt (the config option in sysfs; again, it's miraculously I found that at all). I can't piece together everything the thread is talking about, but it may job someone's memory. I can also try e-mailing the author of that thread directly. When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? Also grab 'dmesg' output to see what driver messages there are. Next, if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and lets see what we have. Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list -m 0' in case the previous one didn't work. Dan Thank you for your reponse, Dan. I've attached the information you asked for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd at your leisure. You'll notice how the 'power-state' differs depending on the boot type. Also, the --firmware-list command failed to run, saying: error: modem has no firmware capabilities Yeah, I see now that the modem is using QMI instead of MBIM. So instead, try these twice, once under Linux and once after rebooting from Windows: For the time being, I can only provide the information with the machine being directly booted into Linux. When I have additional access later today, I will provide the results of these commands after having booted into Windows first. For now, however, read on... # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images error: couldn't list stored images: QMI protocol error (71): 'InvalidQmiCommand' # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode [/dev/cdc-wdm0] Operating mode retrieved: Mode: 'low-power' HW restricted: 'no' # qmicli -d /dev/cdc-wdm0 --dms-lget-revision [/dev/cdc-wdm0] Device revision retrieved: Revision: 'SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 2014/06/04 15:01:26' qmicli -d /dev/cdc-wdm0 --dms-list-stored-images qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode qmicli -d /dev/cdc-wdm0 --dms-get-revision THe other possibility is that the machine's rfkill handling isn't known to Linux, but since Windows knows, when you warm-boot to Linux the WWAN rfkill is disabled. What model laptop is this? (if it's a laptop) This is a Lenovo W540 with the Gobi 5000 Lenovo-certified card installed. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gobi 3000 (1199:901F)
On Mon, 2015-01-12 at 11:04 -0500, Jeremy Moles wrote: > On 01/12/2015 10:46 AM, Dan Williams wrote: > > On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: > >> On 01/09/2015 02:24 PM, Dan Williams wrote: > >>> On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: > On 01/09/2015 12:01 PM, Jeremy Moles wrote: > > Hey everyone! I'm not entirely sure where else to ask this, and I'm > > somewhat desperate at this point having tried everything I'm capable of. > > > > We have a machine here with the card listed in the subject. It shows > > up in lsusb as: > > > > 1199:901f Sierra Wireless, Inc. > > > > It will work in Linux so far if--and ONLY IF--you boot into Windows > > first and then soft reboot into Linux. it appears that Windows does > > something to the modem that Linux (currently) does not, and I was > > wondering if anyone here had any advice on what I might try. > > > > What I've done so far: > > > > 1) There is a knob in the sysfs hierarchy for this device that lets me > > change the "config" (or something like that, I'm actually working on > > this machine remotely and the customer isn't available right now!) > > from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after > > doing so the tty's appear and the device is ready to be perturbed. It > > responds to ATI commands and whatnot, but again, won't work properly > > unless booted in Windows first. I should mention I found this knob > > entirely by accident while hacking on qcserial and trying to accept > > different "port" numbers as they enumerated themselves... > > > > 2) I downloaded the CodeAurora GobiSerial driver (which, according to > > the changelog has a fix for "powering on" a device) and modified it to > > work with 3.17 and 3.18 kernels (essentially, this involved > > re-exporting usb-serial.c symbols like usb_serial_probe the code > > relied on). However, I haven't had a chance to try this yet, and I'm > > not entirely convinced (after looking through the code) it really does > > anything qcserial doesn't. > > > > Anyways, if anyone has any advice, please let us know! > > ___ > > networkmanager-list mailing list > > networkmanager-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/networkmanager-list > > > I should also mention I JUST found this thread: > > http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html > > Which explains exactly what I was seeing when talking about my #1 > attempt (the config option in sysfs; again, it's miraculously I found > that at all). > > I can't piece together everything the thread is talking about, but it > may job someone's memory. I can also try e-mailing the author of that > thread directly. > >>> When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? > >>> Also grab 'dmesg' output to see what driver messages there are. Next, > >>> if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and > >>> lets see what we have. > >>> > >>> Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list > >>> -m 0' in case the previous one didn't work. > >>> > >>> Dan > >>> > >> Thank you for your reponse, Dan. I've attached the information you asked > >> for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd > >> at your leisure. > >> > >> You'll notice how the 'power-state' differs depending on the boot type. > >> Also, the --firmware-list command failed to run, saying: > >> > >> error: modem has no firmware capabilities > > Yeah, I see now that the modem is using QMI instead of MBIM. So > > instead, try these twice, once under Linux and once after rebooting from > > Windows: > > For the time being, I can only provide the information with the machine > being directly booted into Linux. When I have additional access later > today, I will provide the results of these commands after having booted > into Windows first. For now, however, read on... > > # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images > error: couldn't list stored images: QMI protocol error (71): > 'InvalidQmiCommand' > > # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode > [/dev/cdc-wdm0] Operating mode retrieved: > Mode: 'low-power' > HW restricted: 'no' > > # qmicli -d /dev/cdc-wdm0 --dms-lget-revision > [/dev/cdc-wdm0] Device revision retrieved: > Revision: 'SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 > 2014/06/04 15:01:26' > > > qmicli -d /dev/cdc-wdm0 --dms-list-stored-images > > qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode > > qmicli -d /dev/cdc-wdm0 --dms-get-revision > > > > THe other possibility is that the machine's rfkill handling isn't known > > to Linux, but since Windows knows, when you warm-boot to Linux the WWAN > > r
Re: Gobi 3000 (1199:901F)
On 01/12/2015 12:34 PM, Dan Williams wrote: On Mon, 2015-01-12 at 11:04 -0500, Jeremy Moles wrote: On 01/12/2015 10:46 AM, Dan Williams wrote: On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: On 01/09/2015 02:24 PM, Dan Williams wrote: On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: On 01/09/2015 12:01 PM, Jeremy Moles wrote: Hey everyone! I'm not entirely sure where else to ask this, and I'm somewhat desperate at this point having tried everything I'm capable of. We have a machine here with the card listed in the subject. It shows up in lsusb as: 1199:901f Sierra Wireless, Inc. It will work in Linux so far if--and ONLY IF--you boot into Windows first and then soft reboot into Linux. it appears that Windows does something to the modem that Linux (currently) does not, and I was wondering if anyone here had any advice on what I might try. What I've done so far: 1) There is a knob in the sysfs hierarchy for this device that lets me change the "config" (or something like that, I'm actually working on this machine remotely and the customer isn't available right now!) from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after doing so the tty's appear and the device is ready to be perturbed. It responds to ATI commands and whatnot, but again, won't work properly unless booted in Windows first. I should mention I found this knob entirely by accident while hacking on qcserial and trying to accept different "port" numbers as they enumerated themselves... 2) I downloaded the CodeAurora GobiSerial driver (which, according to the changelog has a fix for "powering on" a device) and modified it to work with 3.17 and 3.18 kernels (essentially, this involved re-exporting usb-serial.c symbols like usb_serial_probe the code relied on). However, I haven't had a chance to try this yet, and I'm not entirely convinced (after looking through the code) it really does anything qcserial doesn't. Anyways, if anyone has any advice, please let us know! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list I should also mention I JUST found this thread: http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html Which explains exactly what I was seeing when talking about my #1 attempt (the config option in sysfs; again, it's miraculously I found that at all). I can't piece together everything the thread is talking about, but it may job someone's memory. I can also try e-mailing the author of that thread directly. When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? Also grab 'dmesg' output to see what driver messages there are. Next, if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and lets see what we have. Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list -m 0' in case the previous one didn't work. Dan Thank you for your reponse, Dan. I've attached the information you asked for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd at your leisure. You'll notice how the 'power-state' differs depending on the boot type. Also, the --firmware-list command failed to run, saying: error: modem has no firmware capabilities Yeah, I see now that the modem is using QMI instead of MBIM. So instead, try these twice, once under Linux and once after rebooting from Windows: For the time being, I can only provide the information with the machine being directly booted into Linux. When I have additional access later today, I will provide the results of these commands after having booted into Windows first. For now, however, read on... # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images error: couldn't list stored images: QMI protocol error (71): 'InvalidQmiCommand' # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode [/dev/cdc-wdm0] Operating mode retrieved: Mode: 'low-power' HW restricted: 'no' # qmicli -d /dev/cdc-wdm0 --dms-lget-revision [/dev/cdc-wdm0] Device revision retrieved: Revision: 'SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 2014/06/04 15:01:26' qmicli -d /dev/cdc-wdm0 --dms-list-stored-images qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode qmicli -d /dev/cdc-wdm0 --dms-get-revision THe other possibility is that the machine's rfkill handling isn't known to Linux, but since Windows knows, when you warm-boot to Linux the WWAN rfkill is disabled. What model laptop is this? (if it's a laptop) This is a Lenovo W540 with the Gobi 5000 Lenovo-certified card installed. Under Linux, can you use 'sudo minicom -D /dev/ttyUSBx' where x is the number of each of the USB serial ports, and run "at!pcinfo" on each one in turn? Only ttyUSB2 responds to input, and "at!pcinfo" simply returned "ERROR". However, "ati" returned: Manufacturer: Sierra Wireless, Incorporated Model: EM7355 Revision: SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 2014/06/04 1
Re: Gobi 3000 (1199:901F)
On Mon, 2015-01-12 at 12:39 -0500, Jeremy Moles wrote: > On 01/12/2015 12:34 PM, Dan Williams wrote: > > On Mon, 2015-01-12 at 11:04 -0500, Jeremy Moles wrote: > >> On 01/12/2015 10:46 AM, Dan Williams wrote: > >>> On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: > On 01/09/2015 02:24 PM, Dan Williams wrote: > > On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: > >> On 01/09/2015 12:01 PM, Jeremy Moles wrote: > >>> Hey everyone! I'm not entirely sure where else to ask this, and I'm > >>> somewhat desperate at this point having tried everything I'm capable > >>> of. > >>> > >>> We have a machine here with the card listed in the subject. It shows > >>> up in lsusb as: > >>> > >>> 1199:901f Sierra Wireless, Inc. > >>> > >>> It will work in Linux so far if--and ONLY IF--you boot into Windows > >>> first and then soft reboot into Linux. it appears that Windows does > >>> something to the modem that Linux (currently) does not, and I was > >>> wondering if anyone here had any advice on what I might try. > >>> > >>> What I've done so far: > >>> > >>> 1) There is a knob in the sysfs hierarchy for this device that lets me > >>> change the "config" (or something like that, I'm actually working on > >>> this machine remotely and the customer isn't available right now!) > >>> from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after > >>> doing so the tty's appear and the device is ready to be perturbed. It > >>> responds to ATI commands and whatnot, but again, won't work properly > >>> unless booted in Windows first. I should mention I found this knob > >>> entirely by accident while hacking on qcserial and trying to accept > >>> different "port" numbers as they enumerated themselves... > >>> > >>> 2) I downloaded the CodeAurora GobiSerial driver (which, according to > >>> the changelog has a fix for "powering on" a device) and modified it to > >>> work with 3.17 and 3.18 kernels (essentially, this involved > >>> re-exporting usb-serial.c symbols like usb_serial_probe the code > >>> relied on). However, I haven't had a chance to try this yet, and I'm > >>> not entirely convinced (after looking through the code) it really does > >>> anything qcserial doesn't. > >>> > >>> Anyways, if anyone has any advice, please let us know! > >>> ___ > >>> networkmanager-list mailing list > >>> networkmanager-list@gnome.org > >>> https://mail.gnome.org/mailman/listinfo/networkmanager-list > >>> > >> I should also mention I JUST found this thread: > >> > >> http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html > >> > >> Which explains exactly what I was seeing when talking about my #1 > >> attempt (the config option in sysfs; again, it's miraculously I found > >> that at all). > >> > >> I can't piece together everything the thread is talking about, but it > >> may job someone's memory. I can also try e-mailing the author of that > >> thread directly. > > When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? > > Also grab 'dmesg' output to see what driver messages there are. Next, > > if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and > > lets see what we have. > > > > Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list > > -m 0' in case the previous one didn't work. > > > > Dan > > > Thank you for your reponse, Dan. I've attached the information you asked > for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd > at your leisure. > > You'll notice how the 'power-state' differs depending on the boot type. > Also, the --firmware-list command failed to run, saying: > > error: modem has no firmware capabilities > >>> Yeah, I see now that the modem is using QMI instead of MBIM. So > >>> instead, try these twice, once under Linux and once after rebooting from > >>> Windows: > >> For the time being, I can only provide the information with the machine > >> being directly booted into Linux. When I have additional access later > >> today, I will provide the results of these commands after having booted > >> into Windows first. For now, however, read on... > >> > >> # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images > >> error: couldn't list stored images: QMI protocol error (71): > >> 'InvalidQmiCommand' > >> > >> # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode > >> [/dev/cdc-wdm0] Operating mode retrieved: > >> Mode: 'low-power' > >> HW restricted: 'no' > >> > >> # qmicli -d /dev/cdc-wdm0 --dms-lget-revision > >> [/dev/cdc-wdm0] Device revision retrieved: > >> Revision: 'SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 > >> 2014/06/04 15:01:26' >
Re: Gobi 3000 (1199:901F)
On 01/12/2015 12:42 PM, Dan Williams wrote: On Mon, 2015-01-12 at 12:39 -0500, Jeremy Moles wrote: On 01/12/2015 12:34 PM, Dan Williams wrote: On Mon, 2015-01-12 at 11:04 -0500, Jeremy Moles wrote: On 01/12/2015 10:46 AM, Dan Williams wrote: On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: On 01/09/2015 02:24 PM, Dan Williams wrote: On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: On 01/09/2015 12:01 PM, Jeremy Moles wrote: Hey everyone! I'm not entirely sure where else to ask this, and I'm somewhat desperate at this point having tried everything I'm capable of. We have a machine here with the card listed in the subject. It shows up in lsusb as: 1199:901f Sierra Wireless, Inc. It will work in Linux so far if--and ONLY IF--you boot into Windows first and then soft reboot into Linux. it appears that Windows does something to the modem that Linux (currently) does not, and I was wondering if anyone here had any advice on what I might try. What I've done so far: 1) There is a knob in the sysfs hierarchy for this device that lets me change the "config" (or something like that, I'm actually working on this machine remotely and the customer isn't available right now!) from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after doing so the tty's appear and the device is ready to be perturbed. It responds to ATI commands and whatnot, but again, won't work properly unless booted in Windows first. I should mention I found this knob entirely by accident while hacking on qcserial and trying to accept different "port" numbers as they enumerated themselves... 2) I downloaded the CodeAurora GobiSerial driver (which, according to the changelog has a fix for "powering on" a device) and modified it to work with 3.17 and 3.18 kernels (essentially, this involved re-exporting usb-serial.c symbols like usb_serial_probe the code relied on). However, I haven't had a chance to try this yet, and I'm not entirely convinced (after looking through the code) it really does anything qcserial doesn't. Anyways, if anyone has any advice, please let us know! ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list I should also mention I JUST found this thread: http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html Which explains exactly what I was seeing when talking about my #1 attempt (the config option in sysfs; again, it's miraculously I found that at all). I can't piece together everything the thread is talking about, but it may job someone's memory. I can also try e-mailing the author of that thread directly. When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'? Also grab 'dmesg' output to see what driver messages there are. Next, if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and lets see what we have. Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list -m 0' in case the previous one didn't work. Dan Thank you for your reponse, Dan. I've attached the information you asked for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd at your leisure. You'll notice how the 'power-state' differs depending on the boot type. Also, the --firmware-list command failed to run, saying: error: modem has no firmware capabilities Yeah, I see now that the modem is using QMI instead of MBIM. So instead, try these twice, once under Linux and once after rebooting from Windows: For the time being, I can only provide the information with the machine being directly booted into Linux. When I have additional access later today, I will provide the results of these commands after having booted into Windows first. For now, however, read on... # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images error: couldn't list stored images: QMI protocol error (71): 'InvalidQmiCommand' # qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode [/dev/cdc-wdm0] Operating mode retrieved: Mode: 'low-power' HW restricted: 'no' # qmicli -d /dev/cdc-wdm0 --dms-lget-revision [/dev/cdc-wdm0] Device revision retrieved: Revision: 'SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 2014/06/04 15:01:26' qmicli -d /dev/cdc-wdm0 --dms-list-stored-images qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode qmicli -d /dev/cdc-wdm0 --dms-get-revision THe other possibility is that the machine's rfkill handling isn't known to Linux, but since Windows knows, when you warm-boot to Linux the WWAN rfkill is disabled. What model laptop is this? (if it's a laptop) This is a Lenovo W540 with the Gobi 5000 Lenovo-certified card installed. Under Linux, can you use 'sudo minicom -D /dev/ttyUSBx' where x is the number of each of the USB serial ports, and run "at!pcinfo" on each one in turn? Only ttyUSB2 responds to input, and "at!pcinfo" simply returned "ERROR". However, "ati" returned: Manufacturer: Sierr
Re: Gobi 3000 (1199:901F)
On Mon, 2015-01-12 at 12:44 -0500, Jeremy Moles wrote: > On 01/12/2015 12:42 PM, Dan Williams wrote: > > On Mon, 2015-01-12 at 12:39 -0500, Jeremy Moles wrote: > >> On 01/12/2015 12:34 PM, Dan Williams wrote: > >>> On Mon, 2015-01-12 at 11:04 -0500, Jeremy Moles wrote: > On 01/12/2015 10:46 AM, Dan Williams wrote: > > On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote: > >> On 01/09/2015 02:24 PM, Dan Williams wrote: > >>> On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote: > On 01/09/2015 12:01 PM, Jeremy Moles wrote: > > Hey everyone! I'm not entirely sure where else to ask this, and I'm > > somewhat desperate at this point having tried everything I'm > > capable of. > > > > We have a machine here with the card listed in the subject. It shows > > up in lsusb as: > > > > 1199:901f Sierra Wireless, Inc. > > > > It will work in Linux so far if--and ONLY IF--you boot into Windows > > first and then soft reboot into Linux. it appears that Windows does > > something to the modem that Linux (currently) does not, and I was > > wondering if anyone here had any advice on what I might try. > > > > What I've done so far: > > > > 1) There is a knob in the sysfs hierarchy for this device that lets > > me > > change the "config" (or something like that, I'm actually working on > > this machine remotely and the customer isn't available right now!) > > from 1 to 0, or 0 to 1. This ends up being necessary in fact, as > > after > > doing so the tty's appear and the device is ready to be perturbed. > > It > > responds to ATI commands and whatnot, but again, won't work properly > > unless booted in Windows first. I should mention I found this knob > > entirely by accident while hacking on qcserial and trying to accept > > different "port" numbers as they enumerated themselves... > > > > 2) I downloaded the CodeAurora GobiSerial driver (which, according > > to > > the changelog has a fix for "powering on" a device) and modified it > > to > > work with 3.17 and 3.18 kernels (essentially, this involved > > re-exporting usb-serial.c symbols like usb_serial_probe the code > > relied on). However, I haven't had a chance to try this yet, and I'm > > not entirely convinced (after looking through the code) it really > > does > > anything qcserial doesn't. > > > > Anyways, if anyone has any advice, please let us know! > > ___ > > networkmanager-list mailing list > > networkmanager-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/networkmanager-list > > > I should also mention I JUST found this thread: > > http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html > > Which explains exactly what I was seeing when talking about my #1 > attempt (the config option in sysfs; again, it's miraculously I found > that at all). > > I can't piece together everything the thread is talking about, but it > may job someone's memory. I can also try e-mailing the author of that > thread directly. > >>> When it's cold-booted under Linux, can you grab 'lsusb -v -d > >>> 1199:901F'? > >>> Also grab 'dmesg' output to see what driver messages there are. Next, > >>> if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' > >>> and > >>> lets see what we have. > >>> > >>> Next warm-boot from Windows to Linux and run 'sudo mmcli > >>> --firmware-list > >>> -m 0' in case the previous one didn't work. > >>> > >>> Dan > >>> > >> Thank you for your reponse, Dan. I've attached the information you > >> asked > >> for to this e-mail, formatted in a way it can be easily > >> diff'd/vimdiff'd > >> at your leisure. > >> > >> You'll notice how the 'power-state' differs depending on the boot type. > >> Also, the --firmware-list command failed to run, saying: > >> > >> error: modem has no firmware capabilities > > Yeah, I see now that the modem is using QMI instead of MBIM. So > > instead, try these twice, once under Linux and once after rebooting from > > Windows: > For the time being, I can only provide the information with the machine > being directly booted into Linux. When I have additional access later > today, I will provide the results of these commands after having booted > into Windows first. For now, however, read on... > > # qmicli -d /dev/cdc-wdm0 --dms-list-stored-images > error: couldn't list stored images: QMI protocol err
