Hi,

I am running Network manager v= ersion 0.9.4.0 on Ubuntu, and I see that my syslog is flooded with the mess= ages shown below:

2015-= 05-31T13:54:02.922826-07:00 ctrl-112 NetworkManager[893]: WARNING <warn&= gt; error monitoring device for netlink events: No buffer space available

2015-05-31T13:56:02.986451-07:00 ctrl-112 NetworkManager[893]: WAR= NING <warn> error monitoring device for netlink events: No buffer spa= ce available

2015-05-31T13:58:02.922670-07:00 ctrl-112 NetworkMan= ager[893]: WARNING <warn> error monitoring device for netlink events:= error processing netlink message: Out of memory

2015-05-31T14:00= :02.986715-07:00 ctrl-112 NetworkManager[893]: WARNING <warn> error m= onitoring device for netlink events: No buffer space available

admin@ctrl-112:~$ free -m
             total       used       free     shared    buffers     cached
Mem:         56369       7021      49348          0        252       1005
-/+ buffers/cache:       5763      50606
Swap:         1901          0       1901

Wha= t can be the possible cause of these messages? What is the best approach to= debug this? Any suggestions will be appreciated.

Cheers,

Alok

--001a1136ec5cb9a8ed0517a22e9f-- From dcbw@redhat.com Fri Jun 5 16:39:21 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id C8FF9769E7 for ; Fri, 5 Jun 2015 16:39:21 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvvp9rzYCPxq for ; Fri, 5 Jun 2015 16:39:20 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by restaurant.gnome.org (Postfix) with ESMTP id D6E22768B5 for ; Fri, 5 Jun 2015 16:39:04 +0000 (UTC) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 827AF8E3FC; Fri, 5 Jun 2015 16:39:03 +0000 (UTC) Received: from vpn-229-147.phx2.redhat.com (vpn-229-147.phx2.redhat.com [10.3.229.147]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t55Gd2CZ011832; Fri, 5 Jun 2015 12:39:03 -0400 Message-ID: <1433522342.5784.14.camel@redhat.com> Subject: Re: DHCP renewal changes routing table From: Dan Williams To: Thomas Haller Date: Fri, 05 Jun 2015 11:39:02 -0500 In-Reply-To: <1433418347.14044.8.camel@redhat.com> References: <1433418347.14044.8.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: networkmanager-list@gnome.org X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 16:39:21 -0000 On Thu, 2015-06-04 at 13:45 +0200, Thomas Haller wrote: > On Do, 2015-06-04 at 04:55 -0600, Nicolas Bock wrote: > > Hi, > > > > When I run the Juniper Network Connect client (ncsvc) it terminates > > every time the DHCP license is renewed. The log files of ncsvc are > > unfortunately rather cryptic, but it appears as if the DHCP renewal > > leads to a change in the routing table which triggers a "rmon.error" > > in ncsvc which then tears down the VPN tunnel. Using timestamps the > > following two events correlate: > > > > 20150603133456.514649 ncsvc[p6870.t6870] rmon.error Route to > > destination 192.168.1.1 is missing mask 255.255.255.255 with gw > > 0.0.0.0, metric 1, if_id 0, disconnecting (routemon.cpp:628) > > > > which coincides with the following journal entries: > > > > Jun 03 13:34:55.454967 host NetworkManager[1805]: address > > 192.168.1.16 > > Jun 03 13:34:55.454985 host NetworkManager[1805]: plen 24 > > Jun 03 13:34:55.454990 host NetworkManager[1805]: expires in 300 > > seconds > > Jun 03 13:34:55.455026 host NetworkManager[1805]: gateway 192.168.1.1 > > Jun 03 13:34:55.455035 host NetworkManager[1805]: nameserver > > '192.168.1.1' > > Jun 03 13:34:55.455210 host NetworkManager[1805]: (wlp6s0): DHCPv4 > > state changed bound -> bound > > Jun 03 13:34:55.456679 host dbus[1799]: [system] Activating via > > systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus > > -org.freedesktop.nm-dispatcher.service' > > Jun 03 13:34:55.461372 host dbus[1799]: [system] Successfully > > activated service 'org.freedesktop.nm_dispatcher' > > Jun 03 13:34:55.462021 host nm-dispatcher[8295]: Dispatching action > > 'dhcp4-change' for wlp6s0 > > Jun 03 13:34:56.514958 host systemd-networkd[1803]: tun0 : lost > > carrier > > > > Besides the ncsvc error listed above I sometimes also see this one: > > > > 20150603132151.174661 ncsvc[p6870.t6870] rmon.error Unauthorized new > > route to 192.168.1.0/0.0.0.0 has been added (conflicts with > > our route to 0.0.0.0), disconnecting (routemon.cpp:598) > > > > Both seem to indicate that the routing table is changed on DHCP > > renewal. Is there a way to prevent networkmanager from doing this? Or > > is this problem caused by something else possibly? > > as you suspect, this is caused by NetworkManager. At various times > (e.g. when activating a connection, or on new DHCP lease), NM will > reinstall routes. > > > recently there was a related email thread: > https://mail.gnome.org/archives/networkmanager-list/2015 > -May/msg00016.html > > but no solution either. > > > We could change NM not only do any system-modification when it will > actually have any effect. > Like, re-installing a route, only if it is not yet currently there. In NM 1.0.x we still have nm_platform_ip4_route_sync() which already checks array_contains_ip4_route(), so shouldn't that prevent re-installation of device-specific routes that are already there? Or this is only about the default route and subnet routes from the NMDefaultRouteManager? Dan From thaller@redhat.com Fri Jun 5 19:12:22 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 82A5F76AAF for ; Fri, 5 Jun 2015 19:12:22 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixudLqo9QHnn for ; Fri, 5 Jun 2015 19:12:21 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by restaurant.gnome.org (Postfix) with ESMTP id 7126376A87 for ; Fri, 5 Jun 2015 19:12:04 +0000 (UTC) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 599143824E3; Fri, 5 Jun 2015 19:12:03 +0000 (UTC) Received: from x250 (ovpn-204-26.brq.redhat.com [10.40.204.26]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t55JC0fP009271 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 5 Jun 2015 15:12:02 -0400 Message-ID: <1433531504.7434.1.camel@redhat.com> Subject: Re: DHCP renewal changes routing table From: Thomas Haller To: Dan Williams Date: Fri, 05 Jun 2015 21:11:44 +0200 In-Reply-To: <1433522342.5784.14.camel@redhat.com> References: <1433418347.14044.8.camel@redhat.com> <1433522342.5784.14.camel@redhat.com> Organization: Red Hat Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-SJep0VC48x9sDDrlvQgq" Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: networkmanager-list@gnome.org X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 19:12:22 -0000 --=-SJep0VC48x9sDDrlvQgq Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fr, 2015-06-05 at 11:39 -0500, Dan Williams wrote: > On Thu, 2015-06-04 at 13:45 +0200, Thomas Haller wrote: > > On Do, 2015-06-04 at 04:55 -0600, Nicolas Bock wrote: > > > Hi, > > >=20 > > > When I run the Juniper Network Connect client (ncsvc) it=20 > > > terminates=20 > > > every time the DHCP license is renewed. The log files of ncsvc=20 > > > are=20 > > > unfortunately rather cryptic, but it appears as if the DHCP=20 > > > renewal=20 > > > leads to a change in the routing table which triggers a=20 > > > "rmon.error"=20 > > > in ncsvc which then tears down the VPN tunnel. Using timestamps=20 > > > the=20 > > > following two events correlate: > > >=20 > > > 20150603133456.514649 ncsvc[p6870.t6870] rmon.error Route to=20 > > > destination 192.168.1.1 is missing mask 255.255.255.255 with gw=20 > > > 0.0.0.0, metric 1, if_id 0, disconnecting (routemon.cpp:628) > > >=20 > > > which coincides with the following journal entries: > > >=20 > > > Jun 03 13:34:55.454967 host NetworkManager[1805]: address=20 > > > 192.168.1.16 > > > Jun 03 13:34:55.454985 host NetworkManager[1805]: plen 24 > > > Jun 03 13:34:55.454990 host NetworkManager[1805]: expires in 300=20 > > > seconds > > > Jun 03 13:34:55.455026 host NetworkManager[1805]: gateway=20 > > > 192.168.1.1 > > > Jun 03 13:34:55.455035 host NetworkManager[1805]: nameserver=20 > > > '192.168.1.1' > > > Jun 03 13:34:55.455210 host NetworkManager[1805]: (wlp6s0):=20 > > > DHCPv4=20 > > > state changed bound -> bound > > > Jun 03 13:34:55.456679 host dbus[1799]: [system] Activating via=20 > > > systemd: service name=3D'org.freedesktop.nm_dispatcher' unit=3D'dbus > > > -org.freedesktop.nm-dispatcher.service' > > > Jun 03 13:34:55.461372 host dbus[1799]: [system] Successfully=20 > > > activated service 'org.freedesktop.nm_dispatcher' > > > Jun 03 13:34:55.462021 host nm-dispatcher[8295]: Dispatching=20 > > > action=20 > > > 'dhcp4-change' for wlp6s0 > > > Jun 03 13:34:56.514958 host systemd-networkd[1803]: tun0 : lost=20 > > > carrier > > >=20 > > > Besides the ncsvc error listed above I sometimes also see this=20 > > > one: > > >=20 > > > 20150603132151.174661 ncsvc[p6870.t6870] rmon.error Unauthorized=20 > > > new=20 > > > route to 192.168.1.0/0.0.0.0 has been added (conflicts=20 > > > with=20 > > > our route to 0.0.0.0), disconnecting (routemon.cpp:598) > > >=20 > > > Both seem to indicate that the routing table is changed on DHCP=20 > > > renewal. Is there a way to prevent networkmanager from doing=20 > > > this? Or=20 > > > is this problem caused by something else possibly? > >=20 > > as you suspect, this is caused by NetworkManager. At various times > > (e.g. when activating a connection, or on new DHCP lease), NM will > > reinstall routes. > >=20 > >=20 > > recently there was a related email thread: > > https://mail.gnome.org/archives/networkmanager-list/2015 > > -May/msg00016.html > >=20 > > but no solution either. > >=20 > >=20 > > We could change NM not only do any system-modification when it will > > actually have any effect. > > Like, re-installing a route, only if it is not yet currently there. >=20 > In NM 1.0.x we still have nm_platform_ip4_route_sync() which already > checks array_contains_ip4_route(), so shouldn't that prevent > re-installation of device-specific routes that are already there? Or > this is only about the default route and subnet routes from the > NMDefaultRouteManager? Yes, NMRouteManager would not install routes that are already present. But from DHCP a new address/route could be announced, or another interface might activate/deactivate... http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-route= -manager.c?id=3Dd38c3851f803c4e2f6faa1f88dfe55f952148891#n558 Thomas --=-SJep0VC48x9sDDrlvQgq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJVcfRwAAoJECnCNm5N/FcoqLEP/RJIlI+XBVzUVsIIaV3J38Zn LiAyqbw6SLw6V7daKTudXO/h5tTsIB1WPbsAPLnOfXVMfZegm5T6bfAuZF2+SixC kzbg5JfGAHn2c+R+pI+ZqBuV8exo1d8kMXJP7x9OQSW3Hdjep9LJ/apXA4sf6Tb0 PdJ08vUh6TCsuumT9LbjltRSwS9I4sE3Qq+XfBzHSd4IIocHiQYGGwNgtfgqQ530 rs74xy47K6gt+7OvVdPVrA96JnYtPpQ1wYn+w9l5jjyBevboJTHZ+B6qiFd625Sg OKw+QZa15efWcIeILdkuh7fwqm0sUL7mFWUdDZf/WGMfOPa+JrXyfbJUVVz8zl8N NkHE3WqZ9p1WoAzE/pODKuDPRxJBTMI2c+cKU/7T/K+ZzzoOzgpxRcbWKuCcvpF8 +Udx2umjTN9gt3VEXSuR0mOC+oyOthpmB/5OkTftdCGZUbM3OcQcsD0PWzzFVfo7 Cy35baolGW2xTAskoLWrLb3GF92Ui9iKTf02BW/Pq7PcpIAm9n4mhVitRx73RyiN bDrEOaeGmQSbsc6fQtKQKpEbgWX4D6IJqtlHsuOiKHGaz3XyW5C0Tkz262ymhe7N JqhK04Dfo/4Zq4uHaXmPXjo3zOLH+ufnMLRaw82H329wD2DQlF2QSMwDGg+TS2eN Q9BnfCL8BO6jdh4tZNQj =hTRf -----END PGP SIGNATURE----- --=-SJep0VC48x9sDDrlvQgq-- From aleksander@aleksander.es Fri Jun 5 20:00:34 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 1687976A87 for ; Fri, 5 Jun 2015 20:00:34 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6z8wwkJDWNs for ; Fri, 5 Jun 2015 20:00:32 +0000 (UTC) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by restaurant.gnome.org (Postfix) with ESMTP id 702E976A61 for ; Fri, 5 Jun 2015 20:00:10 +0000 (UTC) Received: by oihb142 with SMTP id b142so60733921oih.3 for ; Fri, 05 Jun 2015 13:00:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=f9JQelVPs521zBZREmqJ7y+w7ctxtv3paziQws9rp0w=; b=WMczh90EhnLPHFUZ9qMcrll9kwfq1fZ3H5DK8Dkj+br9jglGKUIAIoeSU1QCRPJxxD nQsJzaeWrsKwAWHYVazlDHDj98BGw4HoFFWKTOmsfL/rUTy23Y1k5f/FA4yHj5Q6oz8x nLFD/XMojK1glop5CeCSiacjRx+rGUxaT/+6QXGSDRxWVLMePyW1TfwLTzxZk0DlqpC4 NE7P+G4Xt6SGYjkiTRJK6b4V2b4XjgFF2zqr7azx9MzmIB6RjcTkw2RNQSnblCOvhew7 sitLKybiWaETahWR9oPzV14hFiNfhRvE3/wgQBb2qxpCBYDOxkn7ikt9PHc/MwxmX1oI Ed0w== X-Gm-Message-State: ALoCoQm1h3r7yirDLftsf/7Gqma0ft/J3O4yIxdXS4bDpreyR3zM4TW9S1+BKPU7opCrLh0d8H9x MIME-Version: 1.0 X-Received: by 10.60.74.34 with SMTP id q2mr4454651oev.68.1433534408717; Fri, 05 Jun 2015 13:00:08 -0700 (PDT) Received: by 10.182.113.129 with HTTP; Fri, 5 Jun 2015 13:00:08 -0700 (PDT) X-Originating-IP: [47.60.186.39] In-Reply-To: References: <20150528143055.GD10494@bamboo.electronicsoup> <1432843632.32451.20.camel@redhat.com> <20150603091334.GA28185@bamboo.electronicsoup> Date: Fri, 5 Jun 2015 22:00:08 +0200 Message-ID: Subject: Re: Interaction with ModemManager From: Aleksander Morgado To: Pieter Cardoen Content-Type: text/plain; charset=UTF-8 Cc: "networkmanager-list@gnome.org" X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 20:00:34 -0000 On Wed, Jun 3, 2015 at 11:29 AM, Pieter Cardoen wrote: > This should be possible. I already have some experience with Python and > NetworkManager-ModemManager. By now, there isn't a Python library available > for the ModemManager dbus interface but there is for the NetworkManager dbus > API. But you can use ModemManager in Python with libmm-glib via GObject Introspection very easily, you don't need a custom python library. See e.g.: http://cgit.freedesktop.org/ModemManager/ModemManager/tree/examples/modem-watcher-python/ModemWatcher.py Or even in JavaScript, if you're into that: http://cgit.freedesktop.org/ModemManager/ModemManager/tree/examples/modem-watcher-javascript/modemWatcher.js -- Aleksander https://aleksander.es From pieter.cardoen@hotmail.com Sat Jun 6 12:15:11 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 5FB0976A07 for ; Sat, 6 Jun 2015 12:15:11 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIW6ac3VKDUi for ; Sat, 6 Jun 2015 12:15:01 +0000 (UTC) X-Greylist: delayed 361 seconds by postgrey-1.34 at restaurant.gnome.org; Sat, 06 Jun 2015 12:15:00 UTC Received: from DUB004-OMC2S18.hotmail.com (dub004-omc2s18.hotmail.com [157.55.1.157]) by restaurant.gnome.org (Postfix) with ESMTP id E6C5C76AA8 for ; Sat, 6 Jun 2015 12:14:44 +0000 (UTC) Received: from DUB120-W2 ([157.55.1.137]) by DUB004-OMC2S18.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sat, 6 Jun 2015 05:08:40 -0700 X-TMN: [EXJIFWgrKAfqHCAxjeZ5eMfP4vZi8IHLDwMaYGB0bAc=] X-Originating-Email: [pieter.cardoen@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_54c6516b-04fc-457d-8e1e-c89204c64b56_" From: Pieter Cardoen To: Aleksander Morgado Subject: RE: Interaction with ModemManager Date: Sat, 6 Jun 2015 14:08:40 +0200 Importance: Normal In-Reply-To: References: <20150528143055.GD10494@bamboo.electronicsoup>, <1432843632.32451.20.camel@redhat.com>, <20150603091334.GA28185@bamboo.electronicsoup>, , MIME-Version: 1.0 X-OriginalArrivalTime: 06 Jun 2015 12:08:40.0989 (UTC) FILETIME=[86E7FCD0:01D0A051] Cc: "networkmanager-list@gnome.org" X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 12:15:11 -0000 --_54c6516b-04fc-457d-8e1e-c89204c64b56_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Indeed. Python supports dBus very well via the GObject Introspection. The = custom python library relies on this and makes it more easy for me to inter= face with the NetworkManager. > Date: Fri=2C 5 Jun 2015 22:00:08 +0200 > Subject: Re: Interaction with ModemManager > From: aleksander@aleksander.es > To: pieter.cardoen@hotmail.com > CC: arigead@gmail.com=3B dcbw@redhat.com=3B networkmanager-list@gnome.org >=20 > On Wed=2C Jun 3=2C 2015 at 11:29 AM=2C Pieter Cardoen > wrote: > > This should be possible. I already have some experience with Python and > > NetworkManager-ModemManager. By now=2C there isn't a Python library ava= ilable > > for the ModemManager dbus interface but there is for the NetworkManager= dbus > > API. >=20 > But you can use ModemManager in Python with libmm-glib via GObject > Introspection very easily=2C you don't need a custom python library. See > e.g.: > http://cgit.freedesktop.org/ModemManager/ModemManager/tree/examples/modem= -watcher-python/ModemWatcher.py >=20 > Or even in JavaScript=2C if you're into that: > http://cgit.freedesktop.org/ModemManager/ModemManager/tree/examples/modem= -watcher-javascript/modemWatcher.js >=20 > --=20 > Aleksander > https://aleksander.es = --_54c6516b-04fc-457d-8e1e-c89204c64b56_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Indeed. Python supports dBus ver= y well via the GObject =3B Introspection. The custom python library rel= ies on this and makes it more easy for me to interface with the NetworkMana= ger.

>=3B Date: Fri=2C 5 Jun 2015 22:00:08 +0200
>= =3B Subject: Re: Interaction with ModemManager
>=3B From: aleksander@a= leksander.es
>=3B To: pieter.cardoen@hotmail.com
>=3B CC: arigead= @gmail.com=3B dcbw@redhat.com=3B networkmanager-list@gnome.org
>=3B >=3B On Wed=2C Jun 3=2C 2015 at 11:29 AM=2C Pieter Cardoen
>=3B &l= t=3Bpieter.cardoen@hotmail.com>=3B wrote:
>=3B >=3B This should be= possible. I already have some experience with Python and
>=3B >=3B = NetworkManager-ModemManager. By now=2C there isn't a Python library availab= le
>=3B >=3B for the ModemManager dbus interface but there is for th= e NetworkManager dbus
>=3B >=3B API.
>=3B
>=3B But you ca= n use ModemManager in Python with libmm-glib via GObject
>=3B Introspe= ction very easily=2C you don't need a custom python library. See
>=3B = e.g.:
>=3B http://cgit.freedesktop.org/ModemManager/ModemManager/tree/= examples/modem-watcher-python/ModemWatcher.py
>=3B
>=3B Or even = in JavaScript=2C if you're into that:
>=3B http://cgit.freedesktop.org= /ModemManager/ModemManager/tree/examples/modem-watcher-javascript/modemWatc= her.js
>=3B
>=3B --
>=3B Aleksander
>=3B https://alek= sander.es

= --_54c6516b-04fc-457d-8e1e-c89204c64b56_-- From thaller@redhat.com Mon Jun 8 12:50:08 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id B3B357693C for ; Mon, 8 Jun 2015 12:50:08 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSnWViUBeZ6w for ; Mon, 8 Jun 2015 12:50:08 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by restaurant.gnome.org (Postfix) with ESMTP id 2BB34765C7 for ; Mon, 8 Jun 2015 12:49:57 +0000 (UTC) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 443A319F24F; Mon, 8 Jun 2015 12:49:56 +0000 (UTC) Received: from x250 (dhcp-24-135.brq.redhat.com [10.34.24.135]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t58CnsJg011859 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2015 08:49:55 -0400 Message-ID: <1433767787.815.3.camel@redhat.com> Subject: Re: Out of memory warnings from network manager From: Thomas Haller To: Alok Shankar Date: Mon, 08 Jun 2015 14:49:47 +0200 In-Reply-To: References: Organization: Red Hat Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-q6Lmq7OEyk3Wn1d074Ws" Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: networkmanager-list@gnome.org X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 12:50:08 -0000 --=-q6Lmq7OEyk3Wn1d074Ws Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mi, 2015-06-03 at 12:36 -0700, Alok Shankar wrote: > Hi, >=20 > I am running Network manager version 0.9.4.0 on Ubuntu, and I see=20 > that my syslog is flooded with the messages shown below: >=20 >=20 > 2015-05-31T13:54:02.922826-07:00 ctrl-112 NetworkManager[893]:=20 > WARNING error monitoring device for netlink events: No buffer=20 > space available > 2015-05-31T13:56:02.986451-07:00 ctrl-112 NetworkManager[893]:=20 > WARNING error monitoring device for netlink events: No buffer=20 > space available > 2015-05-31T13:58:02.922670-07:00 ctrl-112 NetworkManager[893]:=20 > WARNING error monitoring device for netlink events: error=20 > processing netlink message: Out of memory > 2015-05-31T14:00:02.986715-07:00 ctrl-112 NetworkManager[893]:=20 > WARNING error monitoring device for netlink events: No buffer=20 > space available >=20 >=20 > admin@ctrl-112:~$ free -m > total used free shared buffers =20 > cached > Mem: 56369 7021 49348 0 252 =20 > 1005 > -/+ buffers/cache: 5763 50606 > Swap: 1901 0 1901 >=20 > What can be the possible cause of these messages? What is the best=20 > approach to debug this? Any suggestions will be appreciated. Hi Alok, I don't know, looks like NetworkManager runs out of memory. Does the process use a lot of memory? What gives `ps aux` as RSS? Do you have any problems beside warnings in the logfile? Sorry to say this, but 0.9.4 is quite old and no longer actively supported upstream. So not sure what help you will find here. Thomas --=-q6Lmq7OEyk3Wn1d074Ws Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJVdY9rAAoJECnCNm5N/FcoOtcP/iTeJVEzOWDVchSBVteKLHZ2 oe9nxItfdfnAXX+Hh/A67jb6kln2sagSo9/8JzDi7I+gHPGlT4gr2b9akRoAZS8V i8XcENSlLPqtJMd3bcM1TWH+URx/rzx6LeUlhN51msxjtBCzVKWBVewK8D4+RIK2 AiDY1fUBH4kxOJ4kuWjOyn32RwRL6BBrz0GfFvUOpF87e35HAEUWFFbJbg/kK4h+ 5PS2+xUtqLvYxCprkRI+Fy9uohWimwhzW5N3+WL9RUPrQrhx0fCD6Am6jGL7vuZR BCWJ+zzOTF3lm/fbLARNBmrc/DeOxgPJMIoLg5S4s8tJjWhpMbse3Kk4NszwQomv bVRvlmV15rNaCm8Wa0v5qA2qC5i/lA4GX4csAipSP1gG/1EwiY7arASuKyTfbv0y qAvls/BIV9ypsn9hJhBi2bSgC8D7kzSbM/6BM89VO85d3FY59pORVwN5kuXodhs2 N7evpEXmB2nAiYPKwtrc+1LLrMsXcFQVzi41SFSvoXA7JJG+6orerWd97uh5S+pv vA9Rwl7JeOtSHDsyAjFpMPQ9ZrZg3JU/dshJjhIWlkMVuEr2eMrIRm21y7L5kwbp IxqrZUOpHYExlHi3h4WBypU4n/jQuCC/00bAEYNZeIjF3qTpNDN2ICZ0FeAsz/rR 2yRCq5E4eYRpXWV3Q4VK =QQNX -----END PGP SIGNATURE----- --=-q6Lmq7OEyk3Wn1d074Ws-- From anothersname@googlemail.com Mon Jun 8 14:28:48 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id B3FE376078 for ; Mon, 8 Jun 2015 14:28:48 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJRWLg_dQdfx for ; Mon, 8 Jun 2015 14:28:44 +0000 (UTC) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by restaurant.gnome.org (Postfix) with ESMTP id 74441769B7 for ; Mon, 8 Jun 2015 14:28:28 +0000 (UTC) Received: by obbqz1 with SMTP id qz1so81449719obb.3 for ; Mon, 08 Jun 2015 07:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Iu8AYH78S89le7fUu3bH4nGv5JYMeE6iqDuVcRQWKNo=; b=hegBP2gkXqGI7JUFlZvdwUzcIDZbndGmvShqeoRNq4pLk7mRCfQp4xDIe6s48UsGug uHmwHrisGthyQudzq6QMrVBn0Tm9g7a2i6wK29APLzps6GyCNjJ8jsypFefDYyb9PDy+ RY40+n9q4dEno9wtndNrdndNfdDdzQiRm8OzW/Uw6YsADAQVNt4LH1t98hM4N+n58OG7 7lghY4Gd2E9IYLcJu6NAbMzlyLBOx2oeOp36pE3mH+wDAOfHNk5acJ3oCCgeNUI8RXdg gR96o8PZw8u6ZOvBf9oBXs282C33CUPxN6OLr4G4SlRVDzZu3ruVIQDPWG8P3HD16dtJ 6MIA== MIME-Version: 1.0 X-Received: by 10.202.74.73 with SMTP id x70mr11501411oia.93.1433773707371; Mon, 08 Jun 2015 07:28:27 -0700 (PDT) Received: by 10.60.3.33 with HTTP; Mon, 8 Jun 2015 07:28:27 -0700 (PDT) Date: Mon, 8 Jun 2015 15:28:27 +0100 Message-ID: Subject: nmcli - inconsistent response to query...... From: Another Sillyname To: networkmanager-list@gnome.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 14:28:48 -0000 Hi I have a monitoring script that I wrote back end of last year to monitor the status of a TUN as gnome was not reporting when the TUN failed. As the problem didn't get resolved last year I waited till Fedora 22 shipped with NM 1.x to revisit the problem. Withing the script there's a monitoring section that relies upon the output from >nmcli c show --active to give me the current status of the connections, however under F22 I am now occasionally seeing the error.... (process:YYYYYY: nmcli-CRITICAL **: Error: Could not create NMClient object: Permissions request failed: Authorization check failed: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus). Debug for error code on Mon08Jun2015 at 3.03pm Instead of the expected........ NAME UUID TYPE DEVICE tun0 UUID blanked out for obvious reasons generic tun0 AVPN-TCP80 UUID blanked out for obvious reasons vpn enp9s0 LAN UUID blanked out for obvious reasons 802-3-ethernet enp9s0 Debug for error code on Mon08Jun2015 at 3.03pm This unexpected error message is playing havoc with the parsing in my script and as it doesn't happen under Fed21 I wonder what's changed......is there any way nmcli could handle a timeout error a bit more eloquently? Tony From anothersname@googlemail.com Mon Jun 8 21:06:26 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id A76A276984 for ; Mon, 8 Jun 2015 21:06:26 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBQBV00whExD for ; Mon, 8 Jun 2015 21:06:25 +0000 (UTC) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by restaurant.gnome.org (Postfix) with ESMTP id 5A85E76078 for ; Mon, 8 Jun 2015 21:06:09 +0000 (UTC) Received: by obbir4 with SMTP id ir4so65579933obb.1 for ; Mon, 08 Jun 2015 14:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=09WxSmKAXPZ7gY0+h5I8qz1nPlH/uoTI3cEjrpM2WqA=; b=WwUiJAF7gTNZT6so16HVkCyBxHCN3tPhnQTmqIU01iDxSBxrIRXOl04DDemTnLSAcB gu0AYd0MtWN9ffWMjteC2/gSeHP3IAOiS531uuJwI3kFqmqvzRLxGQ3DlRyPxzcQLFF/ id2TT3fhylLX4QRY+YL5CRyVoobQwSK3iObbe6PlXji3LYCxRfU09Rbqg8+11DWkK8JV t2wMofnz6ALbY38gEztulF9bq1jTSpgp/Zf3Zt0j5N1HUA0dIzvYyqr7X7klIiwPSuhV j20kD1Lch9Pul44+wQLVdnN1JiAqmeSPTfdpMrSJCESaT7C4hPLLB2WuCyUHcqowxdbB oL0A== MIME-Version: 1.0 X-Received: by 10.182.87.36 with SMTP id u4mr16210867obz.50.1433797568169; Mon, 08 Jun 2015 14:06:08 -0700 (PDT) Received: by 10.60.3.33 with HTTP; Mon, 8 Jun 2015 14:06:08 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Jun 2015 22:06:08 +0100 Message-ID: Subject: Re: nmcli - inconsistent response to query...... From: Another Sillyname To: networkmanager-list@gnome.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 21:06:26 -0000 Ignore my previous, I had a brain f*rt!! I just added a "$?" = 1 query immediately after the nmcli command to ensure it hadn't output an error status....problem solved. On 8 June 2015 at 15:28, Another Sillyname wrote: > Hi > > I have a monitoring script that I wrote back end of last year to > monitor the status of a TUN as gnome was not reporting when the TUN > failed. > > As the problem didn't get resolved last year I waited till Fedora 22 > shipped with NM 1.x to revisit the problem. > > Withing the script there's a monitoring section that relies upon the output from > >>nmcli c show --active > > to give me the current status of the connections, however under F22 I > am now occasionally seeing the error.... > > (process:YYYYYY: nmcli-CRITICAL **: Error: Could not create NMClient > object: Permissions request failed: Authorization check failed: > GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not > receive a reply (timeout by message bus). > Debug for error code > on > Mon08Jun2015 at 3.03pm > > Instead of the expected........ > > NAME UUID > TYPE DEVICE > tun0 UUID blanked out for obvious reasons generic > tun0 > AVPN-TCP80 UUID blanked out for obvious reasons vpn > enp9s0 > LAN UUID blanked out for obvious reasons > 802-3-ethernet enp9s0 > Debug for error code > on > Mon08Jun2015 at 3.03pm > > This unexpected error message is playing havoc with the parsing in my > script and as it doesn't happen under Fed21 I wonder what's > changed......is there any way nmcli could handle a timeout error a bit > more eloquently? > > Tony From dcbw@redhat.com Fri Jun 12 20:49:06 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 3FD1E768C0 for ; Fri, 12 Jun 2015 20:49:06 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJiH71w3Aeyo for ; Fri, 12 Jun 2015 20:49:05 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by restaurant.gnome.org (Postfix) with ESMTP id 44B5C76262 for ; Fri, 12 Jun 2015 20:48:48 +0000 (UTC) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id DC34F362AEC; Fri, 12 Jun 2015 20:48:47 +0000 (UTC) Received: from vpn-230-250.phx2.redhat.com (vpn-230-250.phx2.redhat.com [10.3.230.250]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5CKml7T003908; Fri, 12 Jun 2015 16:48:47 -0400 Message-ID: <1434142127.4018.76.camel@redhat.com> Subject: Re: NetworkManager: network selection From: Dan Williams To: Pieter Cardoen Date: Fri, 12 Jun 2015 15:48:47 -0500 In-Reply-To: References: ,, <1433273801.20042.10.camel@redhat.com> , ,<1433343958.25620.8.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: "networkmanager-list@gnome.org" X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 20:49:06 -0000 On Wed, 2015-06-03 at 22:16 +0200, Pieter Cardoen wrote: > This makes sense! Adapting the routing metric value shall allow me to use WiFi over the mobile connection. I've seen that WiFi connection has a higher metric value than the mobile connection so adapting it may make it work as I want it to. I'll try it tomorrow! Just checking back in, did this work out for you? Dan > Thanks for the help! > Pieter > > > Subject: Re: NetworkManager: network selection > > From: dcbw@redhat.com > > To: pieter.cardoen@hotmail.com > > CC: thaller@redhat.com; networkmanager-list@gnome.org > > Date: Wed, 3 Jun 2015 10:05:58 -0500 > > > > On Wed, 2015-06-03 at 08:25 +0200, Pieter Cardoen wrote: > > > Thomas > > > Thanks for the reply. It made some things clear. It is for my application not acceptable that the NetworkManager just prefers the most recently used network but due to the priority feature, it is possible to prefer the WiFi network over a mobile network. However, debian stable doesn't come with NetworkManager 1.0. I will try to install this version on Debian Jessie. > > > > There are really two kinds of "priority" in NM and they are mostly > > independent of each other: > > > > 1) connection autoconnect when the device is disconnected, which as > > Thomas said can be modified by the 'connection.autoconnect-priority' > > property. This is specific to the device, and all autoconnect decisions > > are made independently for that device. > > > > 2) which device gets the default route and DNS, which can be modified by > > the ip4.route-metric and ip6.route-metric properties. This allows you > > to prefer a specific device for outgoing traffic; so if you want the > > WiFi to be preferred when WiFi is connected, then you could set each > > WiFi connection's ip4.route-metric property lower (which means "more > > preferred") than the WWAN connection's ip4.route-metric property. > > > > Does that make sense? > > > > Dan > > > > > ThanksPieter > > > > > > > Subject: Re: NetworkManager: network selection > > > > From: thaller@redhat.com > > > > To: pieter.cardoen@hotmail.com > > > > CC: networkmanager-list@gnome.org > > > > Date: Tue, 2 Jun 2015 21:36:41 +0200 > > > > > > > > On Di, 2015-06-02 at 20:56 +0200, Pieter Cardoen wrote: > > > > > > > > > > I have some questions about how networkmanager selects a network. > > > > > > > > > > How does the NetworkManager deamon decide which network to use if > > > > > multiple network connections are available? > > > > > > > > Hi > > > > > > > > when a device is currently not connected, at various instances > > > > autoconnect hits. For example when you plug-in your cable and carrier > > > > -detect indicates a link. Or when Wi-Fi scanning indicates new visible > > > > networks. > > > > > > > > So, in that case, NM will search through the non-connected connections > > > > and choose a candidate to autoconnect. > > > > > > > > If there are multiple candidates, the one that was used most recently > > > > will be used. > > > > > > > > > Is it possible to configure preferred networks? > > > > > > > > Yes. Such a candidate must have the "connection.autoconnect" property > > > > set to "yes". This is the default. In nm-applet this is called > > > > "Automatically connect to this network when it is available". > > > > > > > > > Is it possible to configure the NetworkManager to only connect to one > > > > > WiFi network and ignore all other free networks? > > > > > > > > Yes, set all connection.autoconnect properties of the other connections > > > > to "no". > > > > > > > > > > > > Since 1.0, there is also a new property "connection.autoconnect > > > > -priority". You can assign there a number, see > > > > nmcli connection show CON-NAME > > > > nmcli connection modify CON-NAME connection.autoconnect-priority 1 > > > > man nm-settings > > > > If there are multiple autoconnect candidates, those with higher numbers > > > > will be preferred. > > > > So, you could set the priority of the connection you prefer to "1", > > > > leaving all others to their default at 0. > > > > > > > > > > > > > > > > Thomas > > > > > > _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list > > > > > From dcbw@redhat.com Fri Jun 12 21:17:03 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 9C1EA76849 for ; Fri, 12 Jun 2015 21:17:03 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Krg9EZZQeZx9 for ; Fri, 12 Jun 2015 21:17:02 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by restaurant.gnome.org (Postfix) with ESMTP id 4107B762A7 for ; Fri, 12 Jun 2015 21:16:51 +0000 (UTC) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 645F3CC062; Fri, 12 Jun 2015 21:16:50 +0000 (UTC) Received: from vpn-230-250.phx2.redhat.com (vpn-230-250.phx2.redhat.com [10.3.230.250]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5CLGn4P006934; Fri, 12 Jun 2015 17:16:50 -0400 Message-ID: <1434143809.4018.93.camel@redhat.com> Subject: Re: NM/ofono FlightMode problem From: Dan Williams To: Tony Espy Date: Fri, 12 Jun 2015 16:16:49 -0500 In-Reply-To: <556F9E76.4000107@canonical.com> References: <556F9E76.4000107@canonical.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Cc: networkmanager-list@gnome.org X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 21:17:03 -0000 On Wed, 2015-06-03 at 20:40 -0400, Tony Espy wrote: > Dan -- > > I'd like to hear your opinion about the following problem I'm trying to > solve, and your take on an idea I have of how to fix it. > > This occurs with the current version of NetworkManager we're using for > Ubuntu on phones, 0.9.10.0-4ubuntu15.1.1 ( see [1] for bzr packaging > branch ). > > One of the patches ( ignore_rfkill_if_urfkill_is_present.patch ) we're > carrying allows NM to integrate with urfkill, a daemon that we use for > implementing FlightMode, and managing the desired state across reboots > of FlightMode and any other system radio killswitches. There's a long > story about why this daemon needed to be used, but I'll keep that out of > the discussion for now. > > Please note, I'm pretty sure the following description is correct, > however it's possible that I missed something... > > When the urfkill Killswitch DBus signal is received that indicates that > a radio killswitch for WWAN has been is disabled ( ie. setting the modem > online ), a callback in NM_MANAGER gets invoked. This callback then > invokes nm_manager_update_radio_enabled, which in turn iterates over all > the MANAGER's devices looking for a matching rf_type, and when found > calls nm_device_set_enabled for the device. > > This eventually bubbles down to our NM_MODEM_OFONO subclass, which > actually doesn't do anything other than log the set_enabled call ( note, > urfkill is responsible for onlining/offlining the modem via ofono ). > > As part of this chain of calls, NM_MODEM sets the modem_state to > ENABLING, which in turn triggers NM_DEVICE_MODEM to set the device_state > to DISCONNECTED, as the device has now become *available* ( thanks to > NM_DEVICE_MODEM->set_enabled setting the rf_enabled flag to TRUE ). > > The problem is, this last device state change, triggers NM_DEVICE to > refresh the available connections, however doing so calls back into the > NM_MODEM_OFONO sub-class to check that connections are compatible. When > this happens, there's a chance that the ofono hasn't finished initizing > the modem after being set online by urfkill. If this happens, our modem > connection is effectively stalled, as nothing other than another > FlightMode toggle, or a reboot will re-kick the device to refresh it's > available connections again. Per our IRC conversation, you're using the "SimManager" interface appearing, then grabbing the SubscriberIdentity as the indicator of initialization. So let's assume your NMOfonoModem subclass of NMModem starts in the INITIALIZING state when the modem object is detected from Ofono. Your NMModem subclass would never advance beyond the INITIALIZING state until all of these conditions are met: 1) NM has called your set_mm_enabled() hook with true (you'd have to cache that value internally) 2) The SimManager interface has appeared 3) SimManager.SubscriberIdentity has a valid value at all 3 points where these things may change you can have a helper function called maybe "check_modem_initialized()" that basically does this: if (rf_enabled && sim_manager && subscriber_identity) { NMModemState new_state = NM_MODEM_STATE_ENABLED; if (SimManager.PinRequired) new_state = NM_MODEM_STATE_LOCKED; nm_modem_set_state (NM_MODEM (self), new_state, ); } else if (nm_modem_get_state (NM_MODEM (self)) > INITIALIZING) { nm_modem_set_state (NM_MODEM (self), INITIALIZING, ); } so basically whenever ofono wasn't ready yet (modem in flight mode or still initializing) the NMModem would sit in INITIALIZING state. Whenever flight mode was activated the modem would jump back to INITIALIZING. This should prevent the modem from becoming 'available' before it can actually be used, and might also fix the issue of autoconnect retries becoming exhausted when flight mode is turned on (that we discussed on IRC). Hopefully this seems like it'll work to you, let me know if some things look dubious though and we can continue to iterate. Dan > I think the correct way to go about fixing this is to introduce the > usage of the modem states DISABLED and ENABLED, as currently NM_MODEM > only seems to use DISABLING and ENABLING. > > Doing this would allow NM_MODEM_OFONO and NM_MODEM_BROADBAND to only > signal the transition to DISABLED/ENABLED based on state and/or return > values from ofono and modem-manager respectively. > > Thoughts? > > Regards, > /tony > > [1] > https://code.launchpad.net/~phablet-team/network-manager/vivid-phone-overlay > _______________________________________________ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list From espy@canonical.com Sat Jun 13 23:42:36 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id DB63476849 for ; Sat, 13 Jun 2015 23:42:36 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xtUFQ64jBxJ for ; Sat, 13 Jun 2015 23:42:35 +0000 (UTC) Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by restaurant.gnome.org (Postfix) with ESMTP id 1F78B760B8 for ; Sat, 13 Jun 2015 23:42:24 +0000 (UTC) Received: from cpe-45-46-78-10.maine.res.rr.com ([45.46.78.10] helo=[172.30.1.18]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1Z3v4A-00084G-30; Sat, 13 Jun 2015 23:42:22 +0000 Message-ID: <557CBFDB.7040204@canonical.com> Date: Sat, 13 Jun 2015 19:42:19 -0400 From: Tony Espy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dan Williams Subject: Re: NM/ofono FlightMode problem References: <556F9E76.4000107@canonical.com> <1434143809.4018.93.camel@redhat.com> In-Reply-To: <1434143809.4018.93.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: networkmanager-list@gnome.org X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 23:42:36 -0000 On 06/12/2015 05:16 PM, Dan Williams wrote: > On Wed, 2015-06-03 at 20:40 -0400, Tony Espy wrote: >> Dan -- >> >> I'd like to hear your opinion about the following problem I'm trying to >> solve, and your take on an idea I have of how to fix it. >> >> This occurs with the current version of NetworkManager we're using for >> Ubuntu on phones, 0.9.10.0-4ubuntu15.1.1 ( see [1] for bzr packaging >> branch ). >> >> One of the patches ( ignore_rfkill_if_urfkill_is_present.patch ) we're >> carrying allows NM to integrate with urfkill, a daemon that we use for >> implementing FlightMode, and managing the desired state across reboots >> of FlightMode and any other system radio killswitches. There's a long >> story about why this daemon needed to be used, but I'll keep that out of >> the discussion for now. >> >> Please note, I'm pretty sure the following description is correct, >> however it's possible that I missed something... >> >> When the urfkill Killswitch DBus signal is received that indicates that >> a radio killswitch for WWAN has been is disabled ( ie. setting the modem >> online ), a callback in NM_MANAGER gets invoked. This callback then >> invokes nm_manager_update_radio_enabled, which in turn iterates over all >> the MANAGER's devices looking for a matching rf_type, and when found >> calls nm_device_set_enabled for the device. >> >> This eventually bubbles down to our NM_MODEM_OFONO subclass, which >> actually doesn't do anything other than log the set_enabled call ( note, >> urfkill is responsible for onlining/offlining the modem via ofono ). >> >> As part of this chain of calls, NM_MODEM sets the modem_state to >> ENABLING, which in turn triggers NM_DEVICE_MODEM to set the device_state >> to DISCONNECTED, as the device has now become *available* ( thanks to >> NM_DEVICE_MODEM->set_enabled setting the rf_enabled flag to TRUE ). >> >> The problem is, this last device state change, triggers NM_DEVICE to >> refresh the available connections, however doing so calls back into the >> NM_MODEM_OFONO sub-class to check that connections are compatible. When >> this happens, there's a chance that the ofono hasn't finished initizing >> the modem after being set online by urfkill. If this happens, our modem >> connection is effectively stalled, as nothing other than another >> FlightMode toggle, or a reboot will re-kick the device to refresh it's >> available connections again. > > Per our IRC conversation, you're using the "SimManager" interface > appearing, then grabbing the SubscriberIdentity as the indicator of > initialization. Not exactly... 'SubscriberIdentity' is needed by NMModemOfono's check_connection_compatible function. It's a long story, but at startup, our current ofono settings plugin reads all of ofono's gprs contexts directly from ofono's settings' files ( note, ofono's settings files are SIM-specific ). NMModemOfono uses the 'SubscriberIdentity' to filter the connections so that only those for the current SIM are considered. When we receive a URfkill Killswitch DBus signal indicating that the modem has been set online, NMDevice's set_enabled logic ends up triggering a call to nm_device_recheck_available_connections. If the modem hasn't fully finished coming back online, it's possible for NMModemOfono's check_connection_compatible function to get an empty value back the 'SubscriberIdentity' property, and thus none of the connections are flagged as compatible... > So let's assume your NMOfonoModem subclass of NMModem starts in the > INITIALIZING state when the modem object is detected from Ofono.Your > NMModem subclass would never advance beyond the INITIALIZING state until > all of these conditions are met: > > 1) NM has called your set_mm_enabled() hook with true (you'd have to > cache that value internally) > > 2) The SimManager interface has appeared > > 3) SimManager.SubscriberIdentity has a valid value > > at all 3 points where these things may change you can have a helper > function called maybe "check_modem_initialized()" that basically does > this: > > if (rf_enabled && sim_manager && subscriber_identity) { > NMModemState new_state = NM_MODEM_STATE_ENABLED; > > if (SimManager.PinRequired) > new_state = NM_MODEM_STATE_LOCKED; > > nm_modem_set_state (NM_MODEM (self), new_state, ); > } else if (nm_modem_get_state (NM_MODEM (self)) > INITIALIZING) { > nm_modem_set_state (NM_MODEM (self), INITIALIZING, ); > } > > so basically whenever ofono wasn't ready yet (modem in flight mode or > still initializing) the NMModem would sit in INITIALIZING state. > Whenever flight mode was activated the modem would jump back to > INITIALIZING. This should prevent the modem from becoming 'available' > before it can actually be used, Sure, I see that NMDeviceModem's is_available function checks for modem_state <= INITIALIZING. So if the modem_state was kept as INITIALIZING until 'SubscriberIdentity' became available, this would prevent the NMDevice recheck_available_connections logic from being triggered till the modem was ready. That said, I think I slightly misled you in the fact that the presence of 'SubscriberIdentity' indicates that the ofono modem is initialized. We monitor a separate property called 'Attached' on ofono's ConnectionManager interface which indicates whether or not the modem is attached to the GPRS network. Once this is 'true', the modem is considered initialized and ready for data calls to be established. Although the modem starts in INITIALIZING state, once the ConnectionManager interface appears, the modem_state moves between SEARCHING ( Attached=false ), REGISTERED ( Attached=true ), CONNECTED ( Attached=true, connection/context activated ), and DISCONNECTING. The set_enabled logic however seems to be the only case where NMModem directly sets modem_state. NMDeviceModem's set_enabled function calls nm_modem_set_mm_enabled, which calls the modem subclass' set_mm_enabled, then directly sets the modem_state to ENABLING or DISABLING. So this would override the NMModemOfono goal of keeping the modem in INITIALIZING state till the modem was ready. I think my suggestion below, was to introduce the usage of the ENABLED and DISABLED states, and then change NMDevice's is_available function to check for <= ENABLED. NMModemOfono and NMModemBroadband, could both then just signal when the modem was ready after a set_enabled by setting the modem_state to ENABLED. > and might also fix the issue of > autoconnect retries becoming exhausted when flight mode is turned on > (that we discussed on IRC). I think this case happens because when flight mode is turned on, ofono first signals that any active gprs contexts are disconnected before it indicates that the modem is offline ( by toggling it's top-level Manager 'Online' property ). So, the policy code sees the device DISCONNECTED and immediately schedules a new activation via g_idle_add. So the retries happen in a tight-loop, then NM see's 'Online' go to false. Introducing a slight delay in scheduling these activation requests makes this problem go away. > Hopefully this seems like it'll work to you, let me know if some things > look dubious though and we can continue to iterate. I think I have enough to get going. I'll let you know how I make out. Thanks again for your help! Regards, /tony From tore@fud.no Sun Jun 14 08:26:32 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id BC17376952 for ; Sun, 14 Jun 2015 08:26:32 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=2 tests=[BAYES_00=-1.9] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTSpfoEQ-sjN for ; Sun, 14 Jun 2015 08:26:31 +0000 (UTC) X-Greylist: delayed 928 seconds by postgrey-1.34 at restaurant.gnome.org; Sun, 14 Jun 2015 08:26:31 UTC Received: from greed.fud.no (nat64-247-osl2.n.bitbit.net [87.238.61.247]) by restaurant.gnome.org (Postfix) with ESMTP id 6EBC1768F4 for ; Sun, 14 Jun 2015 08:26:20 +0000 (UTC) Received: from [2a02:2121:88:9dcb:0:27:21a2:5a01] (port=40989 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Z430C-000364-Vi; Sun, 14 Jun 2015 10:10:49 +0200 Date: Sun, 14 Jun 2015 10:10:48 +0200 From: Tore Anderson To: networkmanager-list@gnome.org Subject: Why is NM preferring wwan over wifi? Message-ID: <20150614101048.2742aa9b@envy.fud.no> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 08:26:32 -0000 I've noticed that a default route on a wifi network is assigned a default metric of 600, while a default route on a wwan connection gets a default metric of 450. The effect of this is that the host will prefer to use wwan over wifi when both are enabled. That's the exact opposite of what I'd expect (based on precedent set by pretty much every smart-phone in the world). While I can easily set different route-metrics on the connections in question, I'm just wondering whether or not this order of preference is really intentional? Curiously enough, when both wifi and wwan are connected, the nm-applet's systray will display the wifi icon (not the wwan one with the little antenna), tricking me into believing that the wifi is indeed the "active" connection. Tore From hadess@hadess.net Sun Jun 14 13:23:01 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 433A876936 for ; Sun, 14 Jun 2015 13:23:01 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBw9WitGGOFN for ; Sun, 14 Jun 2015 13:22:59 +0000 (UTC) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by restaurant.gnome.org (Postfix) with ESMTP id 2C1457684A for ; Sun, 14 Jun 2015 13:22:48 +0000 (UTC) Received: from mfilter9-d.gandi.net (mfilter9-d.gandi.net [217.70.178.138]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 8E412A80C0; Sun, 14 Jun 2015 15:22:46 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter9-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter9-d.gandi.net (mfilter9-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id b8HaAa-0z7Df; Sun, 14 Jun 2015 15:22:45 +0200 (CEST) X-Originating-IP: 83.155.44.161 Received: from nuvo (mon69-7-83-155-44-161.fbx.proxad.net [83.155.44.161]) (Authenticated sender: hadess@hadess.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id DA52FA80B6; Sun, 14 Jun 2015 15:22:44 +0200 (CEST) Message-ID: <1434288158.11440.1.camel@hadess.net> Subject: Re: Why is NM preferring wwan over wifi? From: Bastien Nocera To: Tore Anderson , networkmanager-list@gnome.org Date: Sun, 14 Jun 2015 15:22:38 +0200 In-Reply-To: <20150614101048.2742aa9b@envy.fud.no> References: <20150614101048.2742aa9b@envy.fud.no> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.3 (3.16.3-2.fc22) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 13:23:01 -0000 On Sun, 2015-06-14 at 10:10 +0200, Tore Anderson wrote: > I've noticed that a default route on a wifi network is assigned a > default metric of 600, while a default route on a wwan connection > gets > a default metric of 450. > > The effect of this is that the host will prefer to use wwan over wifi > when both are enabled. That's the exact opposite of what I'd expect > (based on precedent set by pretty much every smart-phone in the > world). > > While I can easily set different route-metrics on the connections in > question, I'm just wondering whether or not this order of preference > is > really intentional? > > Curiously enough, when both wifi and wwan are connected, the > nm-applet's systray will display the wifi icon (not the wwan one with > the little antenna), tricking me into believing that the wifi is > indeed > the "active" connection. Completely agree with you, which is why I filed that as a bug: https://bugzilla.gnome.org/show_bug.cgi?id=744754 From thaller@redhat.com Sun Jun 14 13:29:35 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 2DB4E76936 for ; Sun, 14 Jun 2015 13:29:35 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -7.33 X-Spam-Level: X-Spam-Status: No, score=-7.33 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.428, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwTS4Xr4DwQ4 for ; Sun, 14 Jun 2015 13:29:34 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by restaurant.gnome.org (Postfix) with ESMTP id A6B257684A for ; Sun, 14 Jun 2015 13:29:24 +0000 (UTC) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id E21FE19F96F; Sun, 14 Jun 2015 13:29:22 +0000 (UTC) Received: from x250 (ovpn-204-24.brq.redhat.com [10.40.204.24]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5EDTKJC020678 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 14 Jun 2015 09:29:22 -0400 Message-ID: <1434288551.5666.6.camel@redhat.com> Subject: Re: Why is NM preferring wwan over wifi? From: Thomas Haller To: Tore Anderson , networkmanager-list@gnome.org Date: Sun, 14 Jun 2015 15:29:11 +0200 In-Reply-To: <20150614101048.2742aa9b@envy.fud.no> References: <20150614101048.2742aa9b@envy.fud.no> Organization: Red Hat Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-lIY5HhEegNJtCluxSZ46" Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 13:29:35 -0000 --=-lIY5HhEegNJtCluxSZ46 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On So, 2015-06-14 at 10:10 +0200, Tore Anderson wrote: > I've noticed that a default route on a wifi network is assigned a > default metric of 600, while a default route on a wwan connection=20 > gets > a default metric of 450. >=20 > The effect of this is that the host will prefer to use wwan over wifi > when both are enabled. That's the exact opposite of what I'd expect > (based on precedent set by pretty much every smart-phone in the=20 > world). >=20 > While I can easily set different route-metrics on the connections in > question, I'm just wondering whether or not this order of preference=20 > is > really intentional? IIRC, dcbw said, the idea is that you connected to wwan intentionally. wwan might be metered and you would only connect to it if you want to use it. Maybe that reasoning was better years ago then nowadays. It is unexpected for me too. On master you can also drop a configuration snippet: [connection.wwan-route-metric] match-device=3Dtype:wifi ipv4.route-metric=3D400 ipv6.route-metric=3D400 > Curiously enough, when both wifi and wwan are connected, the > nm-applet's systray will display the wifi icon (not the wwan one with > the little antenna), tricking me into believing that the wifi is=20 > indeed > the "active" connection that sounds like a bug to me that should be investigated. Thomas --=-lIY5HhEegNJtCluxSZ46 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJVfYGnAAoJECnCNm5N/FcojdYQAJrpn3mCj5eKfX9Q3fC3Wv99 DtN1jwtrIkgkcfyKxPK+GpD0M0IC74LKokdZilCT5Wx/b/pePPvsgqgD4GKTGcdF z5E6EylJzukf7WyZGfv/lV2vdlCw89uDBiryG7+tYQqfJam+f8a6LRFG2OGmpWCi TD7fHQdbEgILgRwXtm2XxcGIapa1izqEOOUDfmBefnV2wnsavcxMavoVw83nxzV/ s9ViXrmVAcr7mA6chJ/afphdi3Wy6soRKRWlXuZmFmmVZah4uJpR8AHrw4dwxMm9 bHgy/KvNKFdG1uKjjEsXI8kP9EaSeXgcFhDu9MjisCz0wnRZ+rxhPkXuA23FmEb7 LokaTr7A2ZJs7q+R0L35G5YhAyY0WBgQPYf06op2bo13jbzFMOdJcEA5hL0UXdE2 WuL5hFcV+CklBFliQD5DzBX76il8/gDfNqwIvIGqUNVlg+Ty66L8eM9Kr05I6C8E VuDmxo1ghd2GmzkbBwNI8HWKCtunHuDhUQgDnnPgVFDG6sq1KHE8vhkB93i1MWGe PUjFWG0gIuRQh3/5EDY0mwgpTxdEflFs3P4g9S74hqgwnhw/QAtESxRjTQp9N0Fc Fp97MAkhALYBSQTJidIMlrKHVE7fGsrFVlQPmIu/yv+JrFABBHryZv+PUnJF27VE 5huqDaq+2U1rL/a4f9H6 =0FOr -----END PGP SIGNATURE----- --=-lIY5HhEegNJtCluxSZ46-- From tore@fud.no Sun Jun 14 14:30:09 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id C511976A04 for ; Sun, 14 Jun 2015 14:30:09 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=2 tests=[BAYES_00=-1.9] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzasWEZvc1Vo for ; Sun, 14 Jun 2015 14:30:08 +0000 (UTC) Received: from greed.fud.no (nat64-247-osl2.n.bitbit.net [87.238.61.247]) by restaurant.gnome.org (Postfix) with ESMTP id 03DDC76936 for ; Sun, 14 Jun 2015 14:29:47 +0000 (UTC) Received: from [2a02:fe0:c412:1fe0::3] (port=40054 helo=envy.fud.no) by greed.fud.no with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1Z48uu-0004fA-Sg; Sun, 14 Jun 2015 16:29:44 +0200 Date: Sun, 14 Jun 2015 16:29:43 +0200 From: Tore Anderson To: Thomas Haller Subject: Re: Why is NM preferring wwan over wifi? Message-ID: <20150614162943.1d0d4f34@envy.fud.no> In-Reply-To: <1434288551.5666.6.camel@redhat.com> References: <20150614101048.2742aa9b@envy.fud.no> <1434288551.5666.6.camel@redhat.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: networkmanager-list@gnome.org X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 14:30:09 -0000 * Thomas Haller > IIRC, dcbw said, the idea is that you connected to wwan intentionally. > wwan might be metered and you would only connect to it if you want to > use it. That wwan is typically metered is precisely the reason why I'd expect it to have a lower preference than wifi. :-) But I want to remain connected to the internet even while outside of wifi coverage, so I use auto-connect for all available options: wired, wifi, wwan. I'd expect them to be used in that order of preference, too. > On master you can also drop a configuration snippet: > > [connection.wwan-route-metric] > match-device=type:wifi > ipv4.route-metric=400 > ipv6.route-metric=400 Cool, thanks! Tore From pieter.cardoen@hotmail.com Mon Jun 15 06:33:53 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 8898C765C6 for ; Mon, 15 Jun 2015 06:33:53 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.46, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7FueWFpikHL for ; Mon, 15 Jun 2015 06:33:51 +0000 (UTC) Received: from DUB004-OMC3S20.hotmail.com (dub004-omc3s20.hotmail.com [157.55.2.29]) by restaurant.gnome.org (Postfix) with ESMTP id F25457657A for ; Mon, 15 Jun 2015 06:33:40 +0000 (UTC) Received: from DUB120-W21 ([157.55.2.7]) by DUB004-OMC3S20.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Sun, 14 Jun 2015 23:33:38 -0700 X-TMN: [XYSuSsoEUb3QEaRv4ldbYtob1ytXwTHN] X-Originating-Email: [pieter.cardoen@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_ec35a39b-2904-4990-9571-0aa4e1591af7_" From: Pieter Cardoen To: Dan Williams Subject: RE: NetworkManager: network selection Date: Mon, 15 Jun 2015 08:33:38 +0200 Importance: Normal In-Reply-To: <1434142127.4018.76.camel@redhat.com> References: ,,, <1433273801.20042.10.camel@redhat.com>, , , , <1433343958.25620.8.camel@redhat.com>, , <1434142127.4018.76.camel@redhat.com> MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jun 2015 06:33:38.0901 (UTC) FILETIME=[36D88850:01D0A735] Cc: "networkmanager-list@gnome.org" X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2015 06:33:53 -0000 --_ec35a39b-2904-4990-9571-0aa4e1591af7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This works perfect for me. Our application can select the network by adapti= ng the route metric but mostly we just work with a higher priority WiFi con= nection and metrics appied as appropriate! ThanksPieter > Subject: Re: NetworkManager: network selection > From: dcbw@redhat.com > To: pieter.cardoen@hotmail.com > CC: thaller@redhat.com=3B networkmanager-list@gnome.org > Date: Fri=2C 12 Jun 2015 15:48:47 -0500 >=20 > On Wed=2C 2015-06-03 at 22:16 +0200=2C Pieter Cardoen wrote: > > This makes sense! Adapting the routing metric value shall allow me to u= se WiFi over the mobile connection. I've seen that WiFi connection has a hi= gher metric value than the mobile connection so adapting it may make it wor= k as I want it to. I'll try it tomorrow! >=20 > Just checking back in=2C did this work out for you? >=20 > Dan >=20 > > Thanks for the help! > > Pieter > >=20 > > > Subject: Re: NetworkManager: network selection > > > From: dcbw@redhat.com > > > To: pieter.cardoen@hotmail.com > > > CC: thaller@redhat.com=3B networkmanager-list@gnome.org > > > Date: Wed=2C 3 Jun 2015 10:05:58 -0500 > > >=20 > > > On Wed=2C 2015-06-03 at 08:25 +0200=2C Pieter Cardoen wrote: > > > > Thomas > > > > Thanks for the reply. It made some things clear. It is for my appli= cation not acceptable that the NetworkManager just prefers the most recentl= y used network but due to the priority feature=2C it is possible to prefer = the WiFi network over a mobile network. However=2C debian stable doesn't co= me with NetworkManager 1.0. I will try to install this version on Debian Je= ssie. > > >=20 > > > There are really two kinds of "priority" in NM and they are mostly > > > independent of each other: > > >=20 > > > 1) connection autoconnect when the device is disconnected=2C which as > > > Thomas said can be modified by the 'connection.autoconnect-priority' > > > property. This is specific to the device=2C and all autoconnect deci= sions > > > are made independently for that device. > > >=20 > > > 2) which device gets the default route and DNS=2C which can be modifi= ed by > > > the ip4.route-metric and ip6.route-metric properties. This allows yo= u > > > to prefer a specific device for outgoing traffic=3B so if you want th= e > > > WiFi to be preferred when WiFi is connected=2C then you could set eac= h > > > WiFi connection's ip4.route-metric property lower (which means "more > > > preferred") than the WWAN connection's ip4.route-metric property. > > >=20 > > > Does that make sense? > > >=20 > > > Dan > > >=20 > > > > ThanksPieter > > > >=20 > > > > > Subject: Re: NetworkManager: network selection > > > > > From: thaller@redhat.com > > > > > To: pieter.cardoen@hotmail.com > > > > > CC: networkmanager-list@gnome.org > > > > > Date: Tue=2C 2 Jun 2015 21:36:41 +0200 > > > > >=20 > > > > > On Di=2C 2015-06-02 at 20:56 +0200=2C Pieter Cardoen wrote: > > > > > >=20 > > > > > > I have some questions about how networkmanager selects a networ= k. > > > > > >=20 > > > > > > How does the NetworkManager deamon decide which network to use = if=20 > > > > > > multiple network connections are available? > > > > >=20 > > > > > Hi > > > > >=20 > > > > > when a device is currently not connected=2C at various instances > > > > > autoconnect hits. For example when you plug-in your cable and car= rier > > > > > -detect indicates a link. Or when Wi-Fi scanning indicates new vi= sible > > > > > networks. > > > > >=20 > > > > > So=2C in that case=2C NM will search through the non-connected co= nnections > > > > > and choose a candidate to autoconnect. > > > > >=20 > > > > > If there are multiple candidates=2C the one that was used most re= cently > > > > > will be used. > > > > >=20 > > > > > > Is it possible to configure preferred networks? > > > > >=20 > > > > > Yes. Such a candidate must have the "connection.autoconnect" prop= erty > > > > > set to "yes". This is the default. In nm-applet this is called > > > > > "Automatically connect to this network when it is available". > > > > >=20 > > > > > > Is it possible to configure the NetworkManager to only connect = to one=20 > > > > > > WiFi network and ignore all other free networks? > > > > >=20 > > > > > Yes=2C set all connection.autoconnect properties of the other con= nections > > > > > to "no". > > > > >=20 > > > > >=20 > > > > > Since 1.0=2C there is also a new property "connection.autoconnect > > > > > -priority". You can assign there a number=2C see > > > > > nmcli connection show CON-NAME > > > > > nmcli connection modify CON-NAME connection.autoconnect-priorit= y 1 > > > > > man nm-settings > > > > > If there are multiple autoconnect candidates=2C those with higher= numbers > > > > > will be preferred. > > > > > So=2C you could set the priority of the connection you prefer to = "1"=2C > > > > > leaving all others to their default at 0. > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Thomas > > > > =20 > > > > _______________________________________________ networkmanager-list= mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/= listinfo/networkmanager-list > > >=20 > > >=20 > > =20 >=20 >=20 = --_ec35a39b-2904-4990-9571-0aa4e1591af7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This works perfect for me. Our a= pplication can select the network by adapting the route metric but mostly w= e just work with a higher priority WiFi connection and metrics appied as ap= propriate!

Thanks

Pieter

>=3B Su= bject: Re: NetworkManager: network selection
>=3B From: dcbw@redhat.co= m
>=3B To: pieter.cardoen@hotmail.com
>=3B CC: thaller@redhat.com= =3B networkmanager-list@gnome.org
>=3B Date: Fri=2C 12 Jun 2015 15:48:= 47 -0500
>=3B
>=3B On Wed=2C 2015-06-03 at 22:16 +0200=2C Pieter= Cardoen wrote:
>=3B >=3B This makes sense! Adapting the routing met= ric value shall allow me to use WiFi over the mobile connection. I've seen = that WiFi connection has a higher metric value than the mobile connection s= o adapting it may make it work as I want it to. I'll try it tomorrow!
&g= t=3B
>=3B Just checking back in=2C did this work out for you?
>= =3B
>=3B Dan
>=3B
>=3B >=3B Thanks for the help!
>= =3B >=3B Pieter
>=3B >=3B
>=3B >=3B >=3B Subject: Re: Ne= tworkManager: network selection
>=3B >=3B >=3B From: dcbw@redhat.c= om
>=3B >=3B >=3B To: pieter.cardoen@hotmail.com
>=3B >=3B = >=3B CC: thaller@redhat.com=3B networkmanager-list@gnome.org
>=3B &g= t=3B >=3B Date: Wed=2C 3 Jun 2015 10:05:58 -0500
>=3B >=3B >=3B =
>=3B >=3B >=3B On Wed=2C 2015-06-03 at 08:25 +0200=2C Pieter Card= oen wrote:
>=3B >=3B >=3B >=3B Thomas
>=3B >=3B >=3B &g= t=3B Thanks for the reply. It made some things clear. It is for my applicat= ion not acceptable that the NetworkManager just prefers the most recently u= sed network but due to the priority feature=2C it is possible to prefer the= WiFi network over a mobile network. However=2C debian stable doesn't come = with NetworkManager 1.0. I will try to install this version on Debian Jessi= e.
>=3B >=3B >=3B
>=3B >=3B >=3B There are really two ki= nds of "priority" in NM and they are mostly
>=3B >=3B >=3B indepen= dent of each other:
>=3B >=3B >=3B
>=3B >=3B >=3B 1) con= nection autoconnect when the device is disconnected=2C which as
>=3B &= gt=3B >=3B Thomas said can be modified by the 'connection.autoconnect-pri= ority'
>=3B >=3B >=3B property. This is specific to the device=2C= and all autoconnect decisions
>=3B >=3B >=3B are made independent= ly for that device.
>=3B >=3B >=3B
>=3B >=3B >=3B 2) whi= ch device gets the default route and DNS=2C which can be modified by
>= =3B >=3B >=3B the ip4.route-metric and ip6.route-metric properties. Th= is allows you
>=3B >=3B >=3B to prefer a specific device for outgo= ing traffic=3B so if you want the
>=3B >=3B >=3B WiFi to be prefer= red when WiFi is connected=2C then you could set each
>=3B >=3B >= =3B WiFi connection's ip4.route-metric property lower (which means "more>=3B >=3B >=3B preferred") than the WWAN connection's ip4.route-metr= ic property.
>=3B >=3B >=3B
>=3B >=3B >=3B Does that mak= e sense?
>=3B >=3B >=3B
>=3B >=3B >=3B Dan
>=3B >= =3B >=3B
>=3B >=3B >=3B >=3B ThanksPieter
>=3B >=3B &g= t=3B >=3B
>=3B >=3B >=3B >=3B >=3B Subject: Re: NetworkMana= ger: network selection
>=3B >=3B >=3B >=3B >=3B From: thaller@= redhat.com
>=3B >=3B >=3B >=3B >=3B To: pieter.cardoen@hotmail= .com
>=3B >=3B >=3B >=3B >=3B CC: networkmanager-list@gnome.or= g
>=3B >=3B >=3B >=3B >=3B Date: Tue=2C 2 Jun 2015 21:36:41 +0= 200
>=3B >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B &= gt=3B On Di=2C 2015-06-02 at 20:56 +0200=2C Pieter Cardoen wrote:
>=3B= >=3B >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B = >=3B I have some questions about how networkmanager selects a network.>=3B >=3B >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B = >=3B >=3B How does the NetworkManager deamon decide which network to us= e if
>=3B >=3B >=3B >=3B >=3B >=3B multiple network connect= ions are available?
>=3B >=3B >=3B >=3B >=3B
>=3B >=3B= >=3B >=3B >=3B Hi
>=3B >=3B >=3B >=3B >=3B
>=3B &= gt=3B >=3B >=3B >=3B when a device is currently not connected=2C at v= arious instances
>=3B >=3B >=3B >=3B >=3B autoconnect hits. Fo= r example when you plug-in your cable and carrier
>=3B >=3B >=3B &= gt=3B >=3B -detect indicates a link. Or when Wi-Fi scanning indicates new= visible
>=3B >=3B >=3B >=3B >=3B networks.
>=3B >=3B &= gt=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B So=2C in that ca= se=2C NM will search through the non-connected connections
>=3B >=3B= >=3B >=3B >=3B and choose a candidate to autoconnect.
>=3B >= =3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B If there ar= e multiple candidates=2C the one that was used most recently
>=3B >= =3B >=3B >=3B >=3B will be used.
>=3B >=3B >=3B >=3B >= =3B
>=3B >=3B >=3B >=3B >=3B >=3B Is it possible to configu= re preferred networks?
>=3B >=3B >=3B >=3B >=3B
>=3B >= =3B >=3B >=3B >=3B Yes. Such a candidate must have the "connection.au= toconnect" property
>=3B >=3B >=3B >=3B >=3B set to "yes". Thi= s is the default. In nm-applet this is called
>=3B >=3B >=3B >= =3B >=3B "Automatically connect to this network when it is available".>=3B >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B = >=3B Is it possible to configure the NetworkManager to only connect to on= e
>=3B >=3B >=3B >=3B >=3B >=3B WiFi network and ignore all= other free networks?
>=3B >=3B >=3B >=3B >=3B
>=3B >= =3B >=3B >=3B >=3B Yes=2C set all connection.autoconnect properties o= f the other connections
>=3B >=3B >=3B >=3B >=3B to "no".
&= gt=3B >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B >=3B >=3B >=3B >=3B >=3B Since 1.0=2C there is also a new prope= rty "connection.autoconnect
>=3B >=3B >=3B >=3B >=3B -priority= ". You can assign there a number=2C see
>=3B >=3B >=3B >=3B >= =3B nmcli connection show CON-NAME
>=3B >=3B >=3B >=3B >=3B = nmcli connection modify CON-NAME connection.autoconnect-priority 1
>= =3B >=3B >=3B >=3B >=3B man nm-settings
>=3B >=3B >=3B &= gt=3B >=3B If there are multiple autoconnect candidates=2C those with hig= her numbers
>=3B >=3B >=3B >=3B >=3B will be preferred.
>= =3B >=3B >=3B >=3B >=3B So=2C you could set the priority of the con= nection you prefer to "1"=2C
>=3B >=3B >=3B >=3B >=3B leaving = all others to their default at 0.
>=3B >=3B >=3B >=3B >=3B >=3B >=3B >=3B >=3B >=3B
>=3B >=3B >=3B >=3B >=3B =
>=3B >=3B >=3B >=3B >=3B Thomas
>=3B >=3B >=3B >= =3B
>=3B >=3B >=3B >=3B ___________________________= ____________________ networkmanager-list mailing list networkmanager-list@g= nome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
>= =3B >=3B >=3B
>=3B >=3B >=3B
>=3B >=3B >=3B
>=3B

= --_ec35a39b-2904-4990-9571-0aa4e1591af7_-- From petr.vorel@gmail.com Tue Jun 16 12:10:39 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 19D1976976 for ; Tue, 16 Jun 2015 12:10:39 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSn4iqkYqUOx for ; Tue, 16 Jun 2015 12:10:32 +0000 (UTC) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by restaurant.gnome.org (Postfix) with ESMTP id 94E8A7676C for ; Tue, 16 Jun 2015 12:10:21 +0000 (UTC) Received: by wicnd19 with SMTP id nd19so51173112wic.1 for ; Tue, 16 Jun 2015 05:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:reply-to:mime-version:content-type :content-disposition:user-agent; bh=c4yTczyKloLAznXUyNhnRilAZsyGVWuJdodlwBKL2q8=; b=baPTvvC/3q44kq2M+93JBs5Ai89rlUAjiuV7hQAxBuzeAcXKqQLo10JZCdRWiZLwt6 do1OYlfhGgZT3yalcI3sxhoMcB4LK+2HZAXKrAsIYnp3ZUIQX+gfSh24pmqCBhVZWgzd jvtzthSbEc1b1aLlrd8lN797MnAG796Z1vdmIQ4Jq/kxA27BhAtMiqiLZiNHyfhcAWbc X/+u7YypaO5jbh1VkoQTSYdYR52bzP1vWulNY75Et9joSGMJbC5UOQq1HxCJG7F+La3e Jp2g36rmjkpsPwHfIG5LI5/IDoilblj7r5Xp/+SNSlByYjbrVZv44lvJc5cvc3cIf1Ur 7tUQ== X-Received: by 10.180.188.97 with SMTP id fz1mr20756618wic.29.1434456620252; Tue, 16 Jun 2015 05:10:20 -0700 (PDT) Received: from vorel-pc ([77.104.250.125]) by mx.google.com with ESMTPSA id qq1sm1353924wjc.0.2015.06.16.05.10.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jun 2015 05:10:19 -0700 (PDT) Date: Tue, 16 Jun 2015 14:10:17 +0200 From: Petr Vorel To: networkmanager-list@gnome.org Subject: Cherry-pick 'fix build with Linux 3.2.0 headers' also to branch nm-1-0 Message-ID: <20150616121016.GB5915@vorel-pc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Petr Vorel List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 12:10:39 -0000 Hi there, could you please cherry-pick commit 22b99e3b 'fix build with Linux 3.2.0 headers' also to branch nm-1-0? It'd be nice to have it in 1.0.4 (not sure if it 1.0.4 is going to be made from master or from nm-1-0). Thanks a lot. Kind regards, Petr From thaller@redhat.com Tue Jun 16 13:56:11 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 9E33F76A09 for ; Tue, 16 Jun 2015 13:56:11 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -7.549 X-Spam-Level: X-Spam-Status: No, score=-7.549 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.648, SPF_HELO_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1WJ5amKE6vO for ; Tue, 16 Jun 2015 13:56:10 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by restaurant.gnome.org (Postfix) with ESMTP id 6A72276A05 for ; Tue, 16 Jun 2015 13:56:10 +0000 (UTC) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 5621A3589F1; Tue, 16 Jun 2015 13:56:09 +0000 (UTC) Received: from x250 (dhcp-24-135.brq.redhat.com [10.34.24.135]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5GDu7Ir023054 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2015 09:56:08 -0400 Message-ID: <1434462960.23773.1.camel@redhat.com> Subject: Re: Cherry-pick 'fix build with Linux 3.2.0 headers' also to branch nm-1-0 From: Thomas Haller To: Petr Vorel , networkmanager-list@gnome.org Date: Tue, 16 Jun 2015 15:56:00 +0200 In-Reply-To: <20150616121016.GB5915@vorel-pc> References: <20150616121016.GB5915@vorel-pc> Organization: Red Hat Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-+p4dxOMYqtbbi+1ndFxT" Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 13:56:11 -0000 --=-+p4dxOMYqtbbi+1ndFxT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2015-06-16 at 14:10 +0200, Petr Vorel wrote: > Hi there, >=20 > could you please cherry-pick commit 22b99e3b 'fix build with Linux=20 > 3.2.0 headers' also to > branch nm-1-0? It'd be nice to have it in 1.0.4 (not sure if it 1.0.4=20 > is going to be made > from master or from nm-1-0). >=20 done: http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=3Db573= 3c1916c77ec7002fa1a5a1a4588058ff336a Thomas --=-+p4dxOMYqtbbi+1ndFxT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJVgCrwAAoJECnCNm5N/FcoZAAQALfz4SSgmzpPRfXNujr3bpxY YhRZQogrnD3YaRyFx2PMnrIkrRKdNA77ls8Hkh9GJDmYfCXc2Od1VWOSw7rZ/U1S 3gHIifFThX0Wo999iOsPJLHz3ir1QKZJzkOpnuJjmLRizLr0NKJCJ5el4uduLQgv 79XeOfG/yZA5H+Fa43Xgl6OckPjiZTMlGTL0B4ERBQeiyZXk3ATrXgiowvc1jJKx 2+GPEqgMGIgeKp23ftx9a0L2IkSxpLcvF9Dya1n09wCfqfjoIROZWSM656zd2Ytn pw+bATTM5YSWgoAFZ6WrY6vh6vYLqBlbQ049m0oXTPI+H8fScA1QmfP0Wh8TZ2bt 9WLkBNjwthPpPw9s2XlPJe0Oy5dLnIDaCB1BZBEwlmFkT7oepVakau7w+iOB6sER Wme0JNUFzWpBWVdzrwQbPOcYWyvG6KoqTmkwG2Na5a9+ZenXMtQkI1ON5Oz0SoF2 BzC9/J7BZiebtUNXpzteweB21TJ89Ju3P7DKs62vredr3/dBAtk+0oJOvetgtIbc fFnjZ8qGCD4TPLvw2G7zPQZk+GpmNsACNBc+Sd0VL23Xw7rq37ju7OdrM/dxrvPa 2orOTfKw4YrnHc3Q5DZ7fIDlPALYvm3WQw1boJJPSuzN6lqu9T+X0vH4lO1xnc8M veRva9R5kFjyvHTavOHE =GqrN -----END PGP SIGNATURE----- --=-+p4dxOMYqtbbi+1ndFxT-- From lrintel@redhat.com Tue Jun 16 14:26:21 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id DD60476A09 for ; Tue, 16 Jun 2015 14:26:21 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -7.549 X-Spam-Level: X-Spam-Status: No, score=-7.549 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.648, SPF_HELO_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU6D-vlstayW for ; Tue, 16 Jun 2015 14:26:20 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by restaurant.gnome.org (Postfix) with ESMTP id E5DD776A05 for ; Tue, 16 Jun 2015 14:26:10 +0000 (UTC) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 32CA3C99D6; Tue, 16 Jun 2015 14:26:09 +0000 (UTC) Received: from dhcp-0-213.brq.redhat.com (dhcp-0-213.brq.redhat.com [10.34.0.213]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5GEQ6Y2002538 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 16 Jun 2015 10:26:08 -0400 Message-ID: <1434464766.21508.46.camel@redhat.com> Subject: Re: Cherry-pick 'fix build with Linux 3.2.0 headers' also to branch nm-1-0 From: Lubomir Rintel To: Petr Vorel Date: Tue, 16 Jun 2015 16:26:06 +0200 In-Reply-To: <20150616121016.GB5915@vorel-pc> References: <20150616121016.GB5915@vorel-pc> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: networkmanager-list@gnome.org X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 14:26:21 -0000 On Tue, 2015-06-16 at 14:10 +0200, Petr Vorel wrote: > Hi there, > > could you please cherry-pick commit 22b99e3b 'fix build with Linux > 3.2.0 headers' also to > branch nm-1-0? It'd be nice to have it in 1.0.4 (not sure if it 1.0.4 > is going to be made > from master or from nm-1-0). I'm wondering -- what is your use case here? The 3.2.0 is rather old and the internal DHCP client from systemd doesn't work with it. I guess a distribution shipping a kernel that is this old has some other components that are too old, such as glib2? > Thanks a lot. > > Kind regards, > Petr Regards, Lubo From debacle@debian.org Tue Jun 16 15:32:55 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id BA28B76A05 for ; Tue, 16 Jun 2015 15:32:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=2 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7W6Wxhb_fDk for ; Tue, 16 Jun 2015 15:32:55 +0000 (UTC) X-Greylist: delayed 673 seconds by postgrey-1.34 at restaurant.gnome.org; Tue, 16 Jun 2015 15:32:54 UTC Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by restaurant.gnome.org (Postfix) with ESMTP id A16BD7657B for ; Tue, 16 Jun 2015 15:32:43 +0000 (UTC) X-Envelope-From: debacle@debian.org X-Envelope-To: Received: from localhost (yak.in-berlin.de [192.109.42.109]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-4) with ESMTP id t5GFLSbc026886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 16 Jun 2015 17:21:28 +0200 Received: from mail2.ammonit.com (mail2.ammonit.com [80.152.199.135]) by webmail.in-berlin.de (Horde Framework) with HTTP; Tue, 16 Jun 2015 17:21:28 +0200 Date: Tue, 16 Jun 2015 17:21:28 +0200 Message-ID: <20150616172128.Horde.1WeOgwblMnBkz7-UlXTtSA1@webmail.in-berlin.de> From: "W. Martin Borgert" To: networkmanager-list@gnome.org Subject: Switch off wifi-handling? User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 15:32:55 -0000 Hi, on an embedded device, I'm using wifi with hostapd exclusively and do not want any NM interference. How can I tell NM to ignore any wifi stuff? Note: - the MAC is unknown, because different wifi pens are used - this is still NM 0.8.6 :~( Many thanks in advance for any help! Cheers From dcbw@redhat.com Tue Jun 16 16:35:09 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id D988676A11 for ; Tue, 16 Jun 2015 16:35:09 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -7.549 X-Spam-Level: X-Spam-Status: No, score=-7.549 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.648, SPF_HELO_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CKhFHk_r7xH for ; Tue, 16 Jun 2015 16:35:09 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by restaurant.gnome.org (Postfix) with ESMTP id 693187657B for ; Tue, 16 Jun 2015 16:34:59 +0000 (UTC) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id E716D8E75A; Tue, 16 Jun 2015 16:34:57 +0000 (UTC) Received: from vpn-231-96.phx2.redhat.com (vpn-231-96.phx2.redhat.com [10.3.231.96]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5GGYvI7002854; Tue, 16 Jun 2015 12:34:57 -0400 Message-ID: <1434472497.4149.1.camel@redhat.com> Subject: Re: Switch off wifi-handling? From: Dan Williams To: "W. Martin Borgert" Date: Tue, 16 Jun 2015 11:34:57 -0500 In-Reply-To: <20150616172128.Horde.1WeOgwblMnBkz7-UlXTtSA1@webmail.in-berlin.de> References: <20150616172128.Horde.1WeOgwblMnBkz7-UlXTtSA1@webmail.in-berlin.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Cc: networkmanager-list@gnome.org X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 16:35:10 -0000 On Tue, 2015-06-16 at 17:21 +0200, W. Martin Borgert wrote: > Hi, > > on an embedded device, I'm using wifi with hostapd exclusively > and do not want any NM interference. > > How can I tell NM to ignore any wifi stuff? > > Note: > > - the MAC is unknown, because different wifi pens are used > - this is still NM 0.8.6 :~( NM 0.9.10 and later added the ability to ignore an interface by interface name. NM 0.9.10 and later also split WiFi out to a plugin, which could be removed and then the wifi interface just looks like an unmanaged generic device. But since you're using a very old version, none of those work for you :( Could you try removing wpa_supplicant? Then NM will leave the device in 'unavailable' state and shouldn't touch it after initial NM startup. Dan From debacle@debian.org Tue Jun 16 18:44:42 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 9E9E876848 for ; Tue, 16 Jun 2015 18:44:42 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC8QkFulEJPR for ; Tue, 16 Jun 2015 18:44:40 +0000 (UTC) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by restaurant.gnome.org (Postfix) with ESMTP id 6E41A7657B for ; Tue, 16 Jun 2015 18:44:29 +0000 (UTC) X-Envelope-From: debacle@debian.org Received: from localhost (yak.in-berlin.de [192.109.42.109]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-4) with ESMTP id t5GIiRNv011565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Jun 2015 20:44:27 +0200 Received: from mail2.ammonit.com (mail2.ammonit.com [80.152.199.135]) by webmail.in-berlin.de (Horde Framework) with HTTP; Tue, 16 Jun 2015 20:44:27 +0200 Date: Tue, 16 Jun 2015 20:44:27 +0200 Message-ID: <20150616204427.Horde.dUWrbUxe24ujJSi_fNGu6A1@webmail.in-berlin.de> From: "W. Martin Borgert" To: Dan Williams Subject: Re: Switch off wifi-handling? References: <20150616172128.Horde.1WeOgwblMnBkz7-UlXTtSA1@webmail.in-berlin.de> <1434472497.4149.1.camel@redhat.com> In-Reply-To: <1434472497.4149.1.camel@redhat.com> User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Cc: networkmanager-list@gnome.org X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 18:44:42 -0000 Dan, thanks for the quick response! Quoting Dan Williams : > NM 0.9.10 and later added the ability to ignore an interface by > interface name. NM 0.9.10 and later also split WiFi out to a plugin, > which could be removed and then the wifi interface just looks like an > unmanaged generic device. I hope, that I can upgrade to > 1 some day! > But since you're using a very old version, none of those work for you :( > Could you try removing wpa_supplicant? Then NM will leave the device in > 'unavailable' state and shouldn't touch it after initial NM startup. I removed wpasupplicant and get wlan0 as "unmanaged", not "unavailable": $ nmcli dev DEVICE TYPE STATE eth0 802-3-ethernet connected usb0 802-3-ethernet unavailable wlan0 802-11-wireless unmanaged Is this the expected result? From dcbw@redhat.com Tue Jun 16 21:25:23 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 5019576848 for ; Tue, 16 Jun 2015 21:25:23 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -7.549 X-Spam-Level: X-Spam-Status: No, score=-7.549 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.648, SPF_HELO_PASS=-0.001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uh6-KhdjfDu8 for ; Tue, 16 Jun 2015 21:25:22 +0000 (UTC) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by restaurant.gnome.org (Postfix) with ESMTP id CCFB97657B for ; Tue, 16 Jun 2015 21:25:12 +0000 (UTC) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 26EBFC0155; Tue, 16 Jun 2015 21:25:11 +0000 (UTC) Received: from vpn-231-96.phx2.redhat.com (vpn-231-96.phx2.redhat.com [10.3.231.96]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t5GLPA88001519; Tue, 16 Jun 2015 17:25:10 -0400 Message-ID: <1434489910.26431.6.camel@redhat.com> Subject: Re: Switch off wifi-handling? From: Dan Williams To: "W. Martin Borgert" Date: Tue, 16 Jun 2015 16:25:10 -0500 In-Reply-To: <20150616204427.Horde.dUWrbUxe24ujJSi_fNGu6A1@webmail.in-berlin.de> References: <20150616172128.Horde.1WeOgwblMnBkz7-UlXTtSA1@webmail.in-berlin.de> <1434472497.4149.1.camel@redhat.com> <20150616204427.Horde.dUWrbUxe24ujJSi_fNGu6A1@webmail.in-berlin.de> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Cc: networkmanager-list@gnome.org X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 21:25:23 -0000 On Tue, 2015-06-16 at 20:44 +0200, W. Martin Borgert wrote: > Dan, thanks for the quick response! > > Quoting Dan Williams : > > NM 0.9.10 and later added the ability to ignore an interface by > > interface name. NM 0.9.10 and later also split WiFi out to a plugin, > > which could be removed and then the wifi interface just looks like an > > unmanaged generic device. > > I hope, that I can upgrade to > 1 some day! > > > But since you're using a very old version, none of those work for you :( > > Could you try removing wpa_supplicant? Then NM will leave the device in > > 'unavailable' state and shouldn't touch it after initial NM startup. > > I removed wpasupplicant and get wlan0 as "unmanaged", not "unavailable": > > $ nmcli dev > DEVICE TYPE STATE > eth0 802-3-ethernet connected > usb0 802-3-ethernet unavailable > wlan0 802-11-wireless unmanaged > > Is this the expected result? Even better. "unmanaged" should produce the correct result for you. Let us know how it goes... Dan From sailer@sailer.dynip.lugs.ch Wed Jun 17 00:48:08 2015 Return-Path: X-Original-To: networkmanager-list@gnome.org Delivered-To: networkmanager-list@gnome.org Received: from localhost (localhost.localdomain [127.0.0.1]) by restaurant.gnome.org (Postfix) with ESMTP id 1AC6E768C0 for ; Wed, 17 Jun 2015 00:48:08 +0000 (UTC) X-Virus-Scanned: by amavisd-new at gnome.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=2 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from restaurant.gnome.org ([127.0.0.1]) by localhost (restaurant.gnome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KF0hLAzI-Y46 for ; Wed, 17 Jun 2015 00:48:06 +0000 (UTC) Received: from fep14.mx.upcmail.net (fep14.mx.upcmail.net [62.179.121.34]) by restaurant.gnome.org (Postfix) with ESMTP id 7554D76848 for ; Wed, 17 Jun 2015 00:47:54 +0000 (UTC) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep14-int.chello.at (InterMail vM.8.01.05.13 201-2260-151-135-20130320) with ESMTP id <20150617004751.XGYG24248.viefep14-int.chello.at@edge01.upcmail.net> for ; Wed, 17 Jun 2015 02:47:51 +0200 Received: from xbox.localdomain ([84.73.36.41]) by edge01.upcmail.net with edge id hCnq1q00Q0tFaRQ01Cnq1f; Wed, 17 Jun 2015 02:47:50 +0200 X-SourceIP: 84.73.36.41 X-Authenticated-Sender: tsailer@hispeed.ch Received: from localhost.localdomain (holmes.vpn.sailer.dynip.lugs.ch [10.1.0.18]) (authenticated bits=0) by xbox.localdomain (8.15.1/8.14.9) with ESMTPSA id t5H0llnx019497 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 17 Jun 2015 02:47:47 +0200 Message-ID: <5580C3B3.5030603@sailer.dynip.lugs.ch> Date: Wed, 17 Jun 2015 02:47:47 +0200 From: Thomas Sailer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: networkmanager-list@gnome.org Subject: ModemManager and Thuraya XT Content-Type: multipart/mixed; boundary="------------060203070303080503000703" X-BeenThere: networkmanager-list@gnome.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NetworkManager discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 00:48:08 -0000 This is a multi-part message in MIME format. --------------060203070303080503000703 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I had another go at getting the Thuraya XT Satphone to work with Modem/NetworkManager. Firstly, I had to add another CREG regex (see the attached diff against 1.4.6) due to the modem's response: +CREG: 2, "0426", "F0,0F" Secondly, the XT doesn't particularly like AT+COPS=0. If one sends that, it drops the already acquired satellite signal and then tries to reacquire the signal, which doesn't seem to finish within the timeout period. Now I seem to be able to connect using: mmcli -m 0 --simple-connect apn="get" I cannot however get an IP interface set up. Can anyone give me a hint about what's wrong here? Thanks, Thomas Jun 17 01:38:52 localhost.localdomain NetworkManager[8923]: (ttyACM0): modem state changed, 'searching' --> 'connecting' (reason: user-requested) Jun 17 01:38:52 localhost.localdomain NetworkManager[8923]: (ttyACM0): modem state changed, 'connecting' --> 'connected' (reason: user-requested) Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]: (ttyACM0): Activation: starting connection 'Thuraya2' Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]: (ttyACM0): Activation: Stage 1 of 5 (Device Prepare) scheduled... Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]: (ttyACM0): Activation: Stage 1 of 5 (Device Prepare) started... Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]: (ttyACM0): device state change: disconnected -> prepare (reason 'none') [30 40 0] Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]: (ttyACM0): Failed to connect 'Thuraya2': Connection requested IPv4 but IPv4 is unsuported by the modem. Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]: (ttyACM0): device state change: prepare -> failed (reason 'modem-init-failed') [40 120 28] Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]: (ttyACM0): Activation: failed for connection 'Thuraya2' Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]: (ttyACM0): Activation: Stage 1 of 5 (Device Prepare) complete. Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]: (ttyACM0): device state change: failed -> disconnected (reason 'none') [120 30 0] Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]: (ttyACM0): deactivating device (reason 'none') [0] Jun 17 01:40:00 localhost.localdomain NetworkManager[8923]: (ttyACM0): modem state changed, 'connected' --> 'disconnecting' (reason: user-requested) Jun 17 01:40:02 localhost.localdomain NetworkManager[8923]: (ttyACM0): modem state changed, 'disconnecting' --> 'searching' (reason: user-requested) Jun 17 01:40:38 localhost.localdomain NetworkManager[8923]: (ttyACM0): device state change: disconnected -> unmanaged (reason 'removed') [30 10 36] Jun 17 01:40:38 localhost.localdomain NetworkManager[8923]: (ttyACM0): deactivating device (reason 'removed') [36] --------------060203070303080503000703 Content-Type: text/x-patch; name="mmthuraya.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="mmthuraya.patch" diff -urN ModemManager-1.4.6/src/mm-iface-modem-3gpp.c ModemManager-1.4.6-x/src/mm-iface-modem-3gpp.c --- ModemManager-1.4.6/src/mm-iface-modem-3gpp.c 2015-03-23 11:10:27.000000000 +0100 +++ ModemManager-1.4.6-x/src/mm-iface-modem-3gpp.c 2015-06-17 01:08:02.249519695 +0200 @@ -383,8 +383,8 @@ else { /* If the modem is already registered and the last time it was asked * automatic registration, we're done */ - if (current_operator_code && - !registration_state_context->manual_registration) { + if (1 || (current_operator_code && + !registration_state_context->manual_registration)) { mm_dbg ("Already registered in network '%s'," " automatic registration not launched...", current_operator_code); diff -urN ModemManager-1.4.6/src/mm-modem-helpers.c ModemManager-1.4.6-x/src/mm-modem-helpers.c --- ModemManager-1.4.6/src/mm-modem-helpers.c 2015-02-07 20:28:58.000000000 +0100 +++ ModemManager-1.4.6-x/src/mm-modem-helpers.c 2015-06-17 00:24:38.233365251 +0200 @@ -331,6 +331,8 @@ /* +CREG: ,, (GSM 07.07 CREG=2 unsolicited) */ #define CREG3 "\\+(CREG|CGREG|CEREG):\\s*0*([0-9]),\\s*([^,\\s]*)\\s*,\\s*([^,\\s]*)" +#define CREG11 "\\+(CREG|CGREG|CEREG):\\s*0*([0-9]),\\s*(\"[^\"\\s]*\")\\s*,\\s*(\"[^\"\\s]*\")" + /* +CREG: ,,, (GSM 07.07 solicited and some CREG=2 unsolicited) */ #define CREG4 "\\+(CREG|CGREG|CEREG):\\s*([0-9]),\\s*([0-9])\\s*,\\s*([^,]*)\\s*,\\s*([^,\\s]*)" @@ -350,6 +352,7 @@ /* +CREG: ,,,, (ETSI 27.007 v9.20 CREG=2 unsolicited with RAC) */ #define CREG10 "\\+(CREG|CGREG):\\s*0*([0-9])\\s*,\\s*([^,\\s]*)\\s*,\\s*([^,\\s]*)\\s*,\\s*0*([0-9])\\s*,\\s*([^,\\s]*)" + /* +CEREG: ,,