Re: Loss of Network Adress is DHCP Server failed for some hours

On Mon, Oct 02, Andrei Borzenkov wrote: > 02.10.2017 18:22, Olaf Hering пишет: > > On Mon, Oct 02, Francesco Giudici wrote: > > > >> With that anyway you miss the option of having different connections > >> that could fallback if the "primary" one wi

Re: Loss of Network Adress is DHCP Server failed for some hours

On Mon, Oct 02, Francesco Giudici wrote: > With that anyway you miss the option of having different connections > that could fallback if the "primary" one with dhcp fails. How is it a failure if the DHCP server disappears, perhaps right after it provided a lease? Well, there is likely some blurb

Re: Loss of Network Adress is DHCP Server failed for some hours

On Sun, Oct 1, Oliver Freyermuth wrote: > Is this a bug, or a feature? This is a bug. I'm sure no standard requires the DHCP server to come back within 3 minutes. NetworkManager must keep retrying, forever. Reported here:

regression: NM 1.8 does not provide nameserver

My scripts expect IP4_NAMESERVERS and/or IP6_NAMESERVERS in the environment, even with dns=none in NetworkManager.conf. This worked fine until 1.8. Now the environment has all addresses in an 'up' event, but the DNS info is missing. What must be done to pass this info to the scripts? According to

Re: verbose ipv6 routing messages

On Thu, Aug 18, Thomas Haller wrote: > On Wed, 2016-08-17 at 20:22 +0200, Olaf Hering wrote: > > With NM 1.0.12 lines like this get logged every 30 minutes: > > Aug 17 17:29:17 probook NetworkManager[1458]:   Policy set > > 'bridge' (br0) as default for IPv6 routing and DNS

verbose ipv6 routing messages

With NM 1.0.12 lines like this get logged every 30 minutes: Aug 17 17:29:17 probook NetworkManager[1458]: Policy set 'bridge' (br0) as default for IPv6 routing and DNS. Aug 17 17:59:17 probook NetworkManager[1458]: Policy set 'bridge' (br0) as default for IPv6 routing and DNS. Aug 17

Re: NM ignores knobs regarding ipv6

On Fri, Feb 05, Dan Williams wrote: > Can you grab some NM log output? the NetworkManager openvpn plugin > does have support for IPv6, but we need to figure out if: > > 1) NM or NM-openvpn is somehow ignoring your request to have them > ignore IPv6 configuration In nm-connection-editor I had

Re: NM ignores knobs regarding ipv6

On Fri, Feb 05, Thomas Haller wrote: > On Fri, 2016-02-05 at 09:01 +0100, Olaf Hering wrote: > > The openvpn connection I have been using for months just gained > > support for ipv6. A few months ago I already set ipv6 to "Disabled" > > in the IPv6 tab of nm-co

NM ignores knobs regarding ipv6

The openvpn connection I have been using for months just gained support for ipv6. A few months ago I already set ipv6 to "Disabled" in the IPv6 tab of nm-connection-editor 1.0.8. But when the tunnel is established NM applies the settings received from the peer anyway. I also tried to apply just

Re: Approaching NetworkManager 1.2

On Fri, Nov 13, Dan Williams wrote: > Again, if you can get dispatcher debugging that would be great. Slaves > should never have IP information *unless it's been added externally to > NM* by something, since they are slaves. I think the VPN route error happend with gsm. This week the reconnect

Re: Approaching NetworkManager 1.2

On Tue, Nov 03, poma wrote: > Please bring the bridges back to network-manager-applet! Thanks for finding this... The current way of how things are broken is that even if a bridge is active the GNOME GUI still wants to manage a "cabled connection". But instead of actually doing that it tries to

Re: Approaching NetworkManager 1.2

On Mon, Nov 02, Lubomir Rintel wrote: > If anyone believes anything important is missing it's a good time to > speak up now. The interface for scripts in /etc/NetworkManager/dispatcher.d/ is in a poor state. IMO there are likle two ways how third party apps interact with NM: either they receive

Re: failure with bridge devices

Am 29.09.2015 um 13:25 schrieb Jirka Klimes: > On Mon, 28 Sep 2015 19:18:12 +0200 > Olaf Hering <o...@aepfle.de> wrote: > >> Am 28.09.2015 um 09:05 schrieb Olaf Hering: >>> connection.autoconnect-slaves: -1 (default) >> >> Did I miss that knob

Re: failure with bridge devices

Am 29.09.2015 um 13:21 schrieb Jirka Klimes: > On Mon, 28 Sep 2015 09:05:02 +0200 > Olaf Hering <o...@aepfle.de> wrote: >> So my questions: >> Are there known bugs in the cooperation between NM and GNOME? > I don't think there is a known serious issue. At least GNOME 3.

Re: failure with bridge devices

On Wed, Sep 30, Dan Williams wrote: > Backwards compatibility, an intention to replicate the behavior of > various legacy network initscripts that had the same behavior (where eg > 'ifup br0' after boot didn't bring up slaves), and because it's not > always the case that you want every single

Re: vpn password stored in plain text

Am 28.09.2015 um 18:09 schrieb Dan Williams: > Yes, that is correct. Although best practices suggest full-disk > encryption on anything that can walk away, plus two-factor "something > you know and something you have" for VPNs. But yes, setting the flags > in the file and removing the password

Re: failure with bridge devices

Am 28.09.2015 um 09:05 schrieb Olaf Hering: > connection.autoconnect-slaves: -1 (default) Did I miss that knob in the GUI? Setting it to 1 with "nmcli connection edit bridge" seems to fix the "up" command. Olaf ___ netw

Re: vpn password stored in plain text

Am 28.09.2015 um 17:00 schrieb Dan Williams: > On Mon, 2015-09-28 at 09:32 +0200, Olaf Hering wrote: >> Why is the VPN password stored in plain text in >> /etc/NetworkManager/system-connections? Is there a way to let the GUI >> ask for it every time? > > Note that th

vpn password stored in plain text

Why is the VPN password stored in plain text in /etc/NetworkManager/system-connections? Is there a way to let the GUI ask for it every time? Olaf ___ networkmanager-list mailing list networkmanager-list@gnome.org

API for dispatcher scripts

After upgrading from openSUSE 11.4 with NM 0.9.something to openSUSE Tumbleweed with NM 1.0.2 I was under the impression that the interface/API for the scripts in /etc/NetworkManager/dispatcher.d is much more reliable, and much more informative. But just now I got a different interface for the up

Re: Extending the mobile-broadband-provider-info database

On Tue, Jul 19, Oleg Zhurakivskyy wrote: I am working on GRPS provisioning plugin for oFono open source telephony stack. This plugin should make it possible for oFono to automatically configure GPRS contexts based on information from the provider database. There's an idea to use the

Honor autoconnect user setting for VPN connections

The script below starts a configured VPN connection once the network is up. It works for me on openSuSE 11.4 with NetworkManager 0.8.2 with a gsm connection, ethernet may work as well. The script should be stored in /etc/NetworkManager/dispatcher.d/vpn-auto.py I send it here for review and