Re: NetworkManager autoconnect
On 04.06.2015 13:46, Tony Espy wrote: On 06/04/2015 03:38 AM, poma wrote: On 04.06.2015 02:37, Tony Espy wrote: On 06/03/2015 04:24 PM, Pieter Cardoen wrote: I've tested it with WiFi but I also need to know the behaviour of the wwan case. WiFi scanning interval was set to 10 seconds. I'll try it again tomorrow and verify the scan interval in advance. The WPA_supplicant application has the possibility to set the autoscan argument to periodic or to exponential. Could it possibly be that the exponential setting is enabled which causes to the reconnect period to rise to a large time? In case of the wwan connection, you spoke about 'a couple minutes'. Is it possible to adapt this time or to know wat happens more exactly? I've actually been working with the code (NM_POLICY) that causes this timer to be set for wwan connections, so if you don't mind, I'll add what I've learned recently. I'm currently working with patched version of NM 0.9.10.0 ( see [1] for details ) as part of Ubuntu 14.10 base images we run on Ubuntu phones. We have a new set of patches that implement ofono support for NetworkManager, which to date has only been tested with the rilmodem ofono drivers used on Ubuntu phones. How is the AccessPoint (AP) infrastructure mode implemented on Ubuntu phones? If you're asking how WiFi AccessPoints are configured for Ubuntu phones, it's via a new Qt-based replacement for nm-applet called indicator-network. Regards, /tony I was referring to the backend, but OK. So it's done with the NM, not with the hostapd, therefore no MAC filtering there, right? ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP renewal changes routing table
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, 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? 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=d38c3851f803c4e2f6faa1f88dfe55f952148891#n558 Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP renewal changes routing table
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 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Out of memory warnings from network manager
Hi, I am running Network manager version 0.9.4.0 on Ubuntu, and I see that my syslog is flooded with the messages shown below: 2015-05-31T13:54:02.922826-07:00 ctrl-112 NetworkManager[893]: WARNING warn error monitoring device for netlink events: No buffer space available 2015-05-31T13:56:02.986451-07:00 ctrl-112 NetworkManager[893]: WARNING warn error monitoring device for netlink events: No buffer space available 2015-05-31T13:58:02.922670-07:00 ctrl-112 NetworkManager[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 monitoring device for netlink events: No buffer space available admin@ctrl-112:~$ free -m total used free sharedbuffers cached Mem: 56369 7021 49348 0252 1005 -/+ buffers/cache: 5763 50606 Swap: 1901 0 1901 What can be the possible cause of these messages? What is the best approach to debug this? Any suggestions will be appreciated. Cheers, Alok ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Interaction with ModemManager
On Wed, Jun 3, 2015 at 11:29 AM, Pieter Cardoen pieter.card...@hotmail.com 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 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
