Re: [PATCH] Do not skip wifi slave connections
On Thu, 2017-05-18 at 12:33 -0400, Nikolay Martynov wrote: > > Anyway, the patch LGTM. > > Thanks! Hi, patch merged: https://git.gnome.org/browse/network-manager-applet/commit/?id=15187f557234ee63d2d4730a16ba1c78bc43a516 Thanks, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ModemManager mmcli
Hi Dan, We are trying to operate GPS routing application using: mmcli -m 0 --location-get We are issuing the command once per second, and have noticed some failures where the command either fails or provides no data: cr044# mmcli -m 0 --location-get /org/freedesktop/ModemManager1/Modem/0 - 3GPP location | Mobile country code: '302' | Mobile network code: '610' | Location area code: '11204' | Cell ID: '79330668' - GPS NMEA traces | Not available - Raw GPS | Not available - CDMA BS | Not available cr044 [mmcli -m 0 --location-get] ~ I've attached the journal and status and see there is quite a bit of activity involving several client ID's. The status shows our attempt to restart the service via: systemctl restart ModemManager seems to give an error of: QMI protocol error (14): 'CallFailed' I was wondering if this is an acceptable way of obtaining this GPS info and if the attached logs give an obvious reason for our failure. Thanks in advance, Phil cr044# systemctl status ModemManager ??? ModemManager.service - Modem Manager Loaded: loaded (/lib/systemd/system/ModemManager.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2017-05-19 11:04:15 PDT; 22min ago Main PID: 8368 (ModemManager) CGroup: /system.slice/ModemManager.service ??8368 /usr/sbin/ModemManager ??8374 /usr/lib/libqmi/qmi-proxy May 19 11:25:18 cr044 ModemManager[8368]: Modem /org/freedesktop/ModemManager1/Modem/1: state changed (registered ) May 19 11:25:18 cr044 ModemManager[8368]: [/dev/cdc-wdm0] Allocating new client ID... May 19 11:25:18 cr044 ModemManager[8368]: [/dev/cdc-wdm0] Registered 'wds' (version 1.36) client with ID '9' May 19 11:25:21 cr044 ModemManager[8368]: [/dev/cdc-wdm0] Allocating new client ID... May 19 11:25:21 cr044 ModemManager[8368]: [/dev/cdc-wdm0] Registered 'wds' (version 1.36) client with ID '10' May 19 11:25:21 cr044 ModemManager[8368]: error: couldn't start network: QMI protocol error (14): 'CallFailed' May 19 11:25:21 cr044 ModemManager[8368]: call end reason (1): 'generic-unspecified' May 19 11:25:21 cr044 ModemManager[8368]: verbose call end reason (2,204): [internal] unknown-cause May 19 11:25:21 cr044 ModemManager[8368]: Modem /org/freedesktop/ModemManager1/Modem/1: state changed (connecting ) May 19 11:25:21 cr044 ModemManager[8368]: Simple connect state (8/8): All done cr044 [systemctl status ModemManager] ~ cr044# journalctl -b -u ModemManager --since 11:00 -- Logs begin at Fri 2017-05-19 07:16:48 PDT, end at Fri 2017-05-19 11:24:48 PDT. -- May 19 11:01:09 cr044 ModemManager[7898]: Caught signal, shutting down... May 19 11:01:09 cr044 ModemManager[7898]: Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connected -) May 19 11:01:09 cr044 ModemManager[7898]: Cannot read from istream: connection broken May 19 11:01:29 cr044 ModemManager[7898]: Disabling modems took too long, shutting down with '1' modems around May 19 11:01:29 cr044 ModemManager[8071]: ModemManager (version 1.4.2) starting in system bus... May 19 11:01:29 cr044 ModemManager[8071]: [/dev/cdc-wdm0] Opening device with flags 'version-info, proxy'... May 19 11:01:29 cr044 ModemManager[8071]: cannot connect to proxy: Could not connect: Connection refused May 19 11:01:29 cr044 ModemManager[8071]: spawning new qmi-proxy (try 1)... May 19 11:01:29 cr044 ModemManager[8071]: [/dev/cdc-wdm0] Checking version info (10 retries)... May 19 11:01:31 cr044 ModemManager[8071]: Couldn't find support for device at '/sys/devices/pci:00/:00:19.n May 19 11:01:31 cr044 ModemManager[8071]: Couldn't find support for device at '/sys/devices/pci:00/:00:1c.n May 19 11:01:31 cr044 ModemManager[8071]: Couldn't find support for device at '/sys/devices/pci:00/:00:1c.n May 19 11:01:33 cr044 ModemManager[8071]: [/dev/cdc-wdm0] No transaction matched in received message May 19 11:01:33 cr044 ModemManager[8071]: [/dev/cdc-wdm0] No transaction matched in received message May 19 11:01:33 cr044 ModemManager[8071]: [/dev/cdc-wdm0] No transaction matched in received message May 19 11:01:33 cr044 ModemManager[8071]: [/dev/cdc-wdm0] QMI Device supports 26 services: May 19 11:01:33 cr044 ModemManager[8071]: [/dev/cdc-wdm0]ctl (1.5) May 19 11:01:33 cr044 ModemManager[8071]: [/dev/cdc-wdm0]wds (1.36) May 19 11:01:33 cr044 ModemManager[8071]: [/dev/cdc-wdm0]dms (1.14) May 19 11:01:33 cr044 ModemManager[8071]: [/dev/cdc-wdm0]nas (1.25) May 19 11:01:33 cr044 ModemManager[8071]: [/dev/cdc-wdm0]qos (1.3) May 19 11:01:33 cr044 ModemManager[8071]: [/dev/cdc-wdm0]wms (1.10) May 19 11:01:33 cr044 ModemManager[8071]: [/dev/cdc-wdm0]pds (1.0) May 19 11:01:33 cr044 ModemManager[8071]: [/dev/cdc-wdm0]
Re: ModemManager mmcli
On Fri, 2017-05-19 at 12:47 -0600, Phil Daum wrote: > Hi Dan, > > We are trying to operate GPS routing application using: mmcli -m 0 > --location-get > > We are issuing the command once per second, and have noticed some > failures > where the command either fails or provides no data: Can you run: mmcli -G DEBUG and then reproduce the problem? That'll get debug logs which will be much more useful. Also, the output of 'mmcli -m 0' would be good when the problem happens, so we can see what state it's in. Feel free to out sensitive stuff like your IMEI, phone #, etc. Dan > cr044# mmcli -m 0 --location-get > > /org/freedesktop/ModemManager1/Modem/0 > - > 3GPP location | Mobile country code: '302' > | Mobile network code: '610' > | Location area code: '11204' > | Cell ID: '79330668' > - > GPS NMEA traces | Not available > - > Raw GPS | Not available > - > CDMA BS | Not available > cr044 [mmcli -m 0 --location-get] ~ > > I've attached the journal and status and see there is quite a bit of > activity involving several client ID's. The status shows our attempt > to > restart the service via: systemctl restart ModemManager seems to give > an > error of: > > QMI protocol error (14): 'CallFailed' > > I was wondering if this is an acceptable way of obtaining this GPS > info and > if the attached logs give an obvious reason for our failure. > > Thanks in advance, > Phil > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Network Manager 1.0.X Wi-Fi Autoconnect Issues
> -Original Message- > From: Dan Williams [mailto:d...@redhat.com] > Sent: Thursday, May 18, 2017 4:55 PM > To: Matthew Starr; networkmanager-list@gnome.org > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues > > On Thu, 2017-05-18 at 20:23 +, Matthew Starr wrote: > > > -Original Message- > > > From: Dan Williams [mailto:d...@redhat.com] > > > Sent: Thursday, May 18, 2017 2:24 PM > > > To: Matthew Starr; networkmanager-list@gnome.org > > > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues > > > > > > On Thu, 2017-05-18 at 18:43 +, Matthew Starr wrote: > > > > > -Original Message- > > > > > From: Dan Williams [mailto:d...@redhat.com] > > > > > Sent: Thursday, May 18, 2017 1:31 PM > > > > > To: Matthew Starr; networkmanager-list@gnome.org > > > > > Subject: Re: Network Manager 1.0.X Wi-Fi Autoconnect Issues > > > > > > > > > > On Thu, 2017-05-18 at 15:54 +, Matthew Starr wrote: > > > > > > I have tried using NetworkManager 1.0.0 and 1.0.12 on an > > > > > > embedded device built with buildroot that has Ethernet (eth0), > > > > > > Wi-Fi client (mlan0), Wi-Fi Access Point (uap0), and Cellular > > > > > > interfaces > > > > > > (ttyACM0 > > > > > > and ppp0). The Wi-Fi AP (uap0) interface is ignored by > > > > > > Network Manager based on my NetworkManager.conf file. I am > > > > > > able to boot the device and Network Manager will automatically > > > > > > configure and connect with Ethernet, Wi-Fi Client, and > > > > > > Cellular interfaces every time. > > > > > > > > > > > > If I move out of range of the Wi-Fi access point the device > > > > > > will disconnect and if I move back into range in under an > > > > > > hour, NetworkManager will reestablish the connection. If I > > > > > > wait multiple hours before moving back into range of the Wi-Fi > > > > > > access point, Network Manager will not reestablish a > > > > > > connection automatically with the access point (I waited hours > > > > > > with the AP within range and visible in Wi-Fi scan results). > > > > > > When Network Manager is not automatically reestablishing a > > > > > > connection to the access point I can use nmcli to bring up the > > > > > > profile associated with the access point and it connects > > > > > > immediately. > > > > > > > > > > > > Why is Network Manager not able to auto connect to a Wi-Fi AP > > > > > > after a longer period of time of not seeing the AP? Is there > > > > > > a timeout within Network Manager? Is this a bug? > > > > > > > > > > Like you say, it does look like NM is trying to auto-activate > > > > > the connection, but it's not doing it correctly. The most > > > > > likely thing happening is that it does try to activate, but it's > > > > > not able to find the "best" connection for the device. > > > > > Somehow the existing WiFi connection profile isn't matching. > > > > > > > > > > Can you run 'nmcli con show > > > > start>'? > > > > > > > > Dan, > > > > > > > > This issue has occurred on several different access point I have > > > > attempted to connect to all from different vendors (Linksys, > > > > Ubiquiti, D-link). > > > > > > Ok, that doesn't ellucidate anything. Are you able to apply a > > > debugging patch to NetworkManager and rebuild it? Alternatively, > > > you could use 'gdb' to step through the code and see where it's not > > > proceeding with the activation in nm-policy.c. > > > > > > Dan > > > > > > > Some additional testing I just finished shows that version 1.6.2 > > exhibits the exact same behavior. > > > > I am able to apply patches easily and rebuild. I could run gdb but it > > is not quite as easy on my current setup. > > Which version do you prefer patches for? > > Dan My more immediate need is with the 1.0.12 version, but I plan to do a release within the next 6 months with the 1.6.X or 1.8.X version. -Matt ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
