Re: Programmatically manage no-auto-default.state file?

[Andrei Borzenkov via networkmanager-list]

On 10.08.2022 13:09, Thomas Haller wrote:
> On Wed, 2022-08-10 at 09:01 +0300, Andrei Borzenkov via networkmanager-
> list wrote:
>> When automatic connection is deleted/modified, interface is added to
>> /var/lib/NetworkManager/no-auto-default.state. Is there any device
>> property to show "no-auto-default" state? Is there any command/D-Bus
>> API
>> to remove interface from this list?
> 
> 
> there is no such API.
> 
> I guess you can delete the file, or modify it with "sed". That gets
> complicated, because NetworkManager only loads the file ones and writes
> it anew at unpredictable times. To get it right, you'd have to stop NM,
> modify the file, start NM.
> 
> Btw, `sudo NetworkManager --print-config` prints the content of the no-
> auto-default.state flag. Note that as NetworkManager loads the file
> only once and remembers it, the running NetworkManager may not have
> cached what --print-config shows.
> 

OK, thanks. I overlooked this option.

> 
> Why do you want that?
> 

Mostly to reset NetworkManager state to clean default. Usually it is
frowned upon direct editing of internal state files and this file is
certainly internal state.

If you say that editing it is OK it is fine for me.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Programmatically manage no-auto-default.state file?

[Andrei Borzenkov via networkmanager-list]

When automatic connection is deleted/modified, interface is added to
/var/lib/NetworkManager/no-auto-default.state. Is there any device
property to show "no-auto-default" state? Is there any command/D-Bus API
to remove interface from this list?

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: connection to disable an interface

[Andrei Borzenkov via networkmanager-list]

On 14.05.2022 22:24, Thomas Haller wrote:
> Hi,
> 
> 
> On Sat, 2022-05-14 at 07:38 +0300, Andrei Borzenkov via networkmanager-
> list wrote:
>>>
>>>
>>> The background is a security requirement. Unused interfaces must
>>> ideally remain disabled at the physical layer when a cable is
>>> plugged
>>> in. Ideally, the LEDs would also remain dark.
>>>
>>
>> It sounds like
>>
>> no-auto-default=*
>>
>> mostly does what you want.
> 
> 
> that option merely disables that NetworkManager will automatically
> generate a profile for ethernet devices, that don't have a profile yet.
> Such profiles are called "Wired connection 1", which is how you can
> recognize it.
> 
> This does very little magic, you can manually create a profile to the
> same effect. In any case, NetworkManager would have already set the
> interface IFF_UP at this point -- regardless of "(no-)auto-default".
> 

Sure, but usual question is - what are the expected threats? Simply
having interface up does not hurt anyone (except may be audit company).
But having automatic profile on interface allows someone to connect PC
with DHCP server and so get known IP address to (attempt to) access the
server. This is prevented by no-auto-default.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: connection to disable an interface

[Andrei Borzenkov via networkmanager-list]

On 14.05.2022 00:23, Adrian Freihofer via networkmanager-list wrote:
> Hi
> 
> Is it somehow possible to disable an interface via NetworkManager?
> 
> I am thinking of something like:
> 
> nmcli connection modify con-eth0 802-3-ethernet.phy disabled
> nmcli connection up con-eth0
> 
> which would basically have the same effect as:
> 
> ip link set eth0 down
> 
> 
> nmcli connection modify con-eth0 802-3-ethernet.phy enabled
> nmcli connection up con-eth0
> 
> which would basically have the same effect as:
> 
> ip link set eth0 up
> 
> 
> The background is a security requirement. Unused interfaces must
> ideally remain disabled at the physical layer when a cable is plugged
> in. Ideally, the LEDs would also remain dark.
> 

It sounds like

no-auto-default=*

mostly does what you want.


> If this function does not exist yet, would it be interesting for
> NetworkManager?
> Could the functionality be implemented with reasonable effort or would
> it be difficult to implement?
> 
> Thank you and regards,
> Adrian
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Enable virtual interface in pre.d script

[Andrei Borzenkov via networkmanager-list]

On 20.11.2021 16:15, Eric wrote:
> On 19.11.2021 16:36, Eric wrote:
> I have a chicken/egg problem.  
> 
> I want to have wlan1 as an interface.  I have created a connection to use it. 
>  But it doesn?t exist on reboot so I?d like to have a script in pre.d/ that 
> will add the interface but NM refuses to start the connection because the 
> interface does not exist.  Is there a way to get the script to execute 
> earlier so that it can create the virtual interface prior to the connection 
> check if its present?
> 
> On 19.11. 2021 17:32, Andrei wrote:
> You need to explain in more details what wlan1 interface is and how it is 
> added.
> 
> wlan0 is instantiated automatically when the driver is loaded.  I use it as 
> an AP interface.  I want to have AP/STA so I need to create wlan1 for the 
> client interface.  I do this with:
> 
> iw dev wlan0 interface add wlan1 type managed
> 
> but this interface does persist across power cycle so I need to create it 
> every time.  I would like to have the interface created when networkmanager 
> tries to bring up the connection, but the script with the above command (in 
> the pre.d directory) does not get called before networkmanager tells me there 
> is no interface for the connection.
> 

I do not think it is possible. Just create startup script to add second 
interface.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Enable virtual interface in pre.d script

[Andrei Borzenkov via networkmanager-list]

On 19.11.2021 16:36, Eric wrote:
> I have a chicken/egg problem.  
> 
> I want to have wlan1 as an interface.  I have created a connection to use it. 
>  But it doesn’t exist on reboot so I’d like to have a script in pre.d/ that 
> will add the interface but NM refuses to start the connection because the 
> interface does not exist.  Is there a way to get the script to execute 
> earlier so that it can create the virtual interface prior to the connection 
> check if its present?
> 

You need to explain in more details what wlan1 interface is and how it is added.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Chrony IPv6 sources offline after resume - dispatcher script runs before IPv6 is up

[Andrei Borzenkov via networkmanager-list]

Chrony comes with sample NetworkManager dispatcher script that offlines
NTP sources when interface goes down and onlines them when interface
comes up. Technically it runs "chronyc onoffline" which tries to
determine whether each source can be reached. This script is actually
installed by distributions (openSUSE and Ubuntu for sure).

When system goes to suspend NetworkManager offlines interfaces that
causes chrony to offline its sources. On resume chrony is expected to
online them again.

This works well for IPv4 sources but IPv6 sources remain offline. Like

$ chronyc -n sources
210 Number of sources = 8
MS Name/IP address Stratum Poll Reach LastRx Last sample

===
^? 2001:67c:1560:8003::c80   6 0 - +0ns[   +0ns] +/-
   0ns
^? 2001:67c:1560:8003::c70   6 0 - +0ns[   +0ns] +/-
   0ns
^- 91.189.89.199 2   8   377   108  -2030us[-2209us] +/-
  53ms
^- 91.189.94.4   2   8   37749  -2878us[-3067us] +/-
  60ms
^+ 79.111.152.5  1   8   37751  -2960us[-3149us] +/-
  18ms
^* 188.225.9.167 2   8   37749  -1819us[-2008us] +/-
  15ms
^+ 85.21.78.91   2   8   377   116  -3053us[-3230us] +/-
  19ms
^+ 185.209.85.2222   8   37750  +6182us[+5993us] +/-
  23ms
$

The reason is - when ifup dispatcher script runs, IPv6 is not yet
configured. Here are route entries

default via 192.168.1.1 dev wlan0 proto dhcp metric 20600
169.254.0.0/16 dev wlan0 scope link metric 1000
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.6 metric 600
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev wlan0 proto kernel metric 600 pref medium

So IPv4 is up and has default route but IPv6 still only link-local
address. Couple of seconds later

::1 dev lo proto kernel metric 256 pref medium
2a00:::::/64 dev wlan0 proto ra metric 600 pref medium
fe80::/64 dev wlan0 proto kernel metric 600 pref medium
default via fe80::1 dev wlan0 proto ra metric 20600 pref medium

Is it possible to run dispatcher script after both IPv4 and IPv6 are
configured on interface? Or only IPv6 for that matter - it does not
matter if "chronyc onoffline" runs multiple times.

Both IPv4 and IPv6 are set to auto.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Make NetworkManager connection profiles without changing the current network configuration

[Andrei Borzenkov via networkmanager-list]

On 03.08.2021 17:38, Thomas Haller via networkmanager-list wrote:
> 
> Also, if you modify profiles via D-Bus API (which is what nmcli does),
> then the configuration only take effect when activating the profile the
> next time. I mean, the profile changes immediately, but the current
> network configuration does not. That means, even if a profile is
> currently activated, you might be able to modify it, without changing
> the runtime configuration of the interface yet.

Is it possible to see profile properties currently active on a
interface? Because nmcli displays configured properties even if they
changed and device was activated with older profile definition.

> - if you modify a profile that is currently active, then the properties
> "connection.metered" and "connection.zone" take effect immediately,
> unless you specify "no-reapply" flag for Update2 ([1]).
> 

Is it possible to do it with nmcli?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Question on using NM to connect to wifi AP

[Andrei Borzenkov via networkmanager-list]

On 28.07.2021 19:29, Michael Uman wrote:
> Hello,
> This is my 1st post to the list so please be forgiving if I am not asking
> the question correctly. I am trying to use NM to connect to a wifi SSID and
> I have the SSID and password, but I cannot figure out which interfaces and
> which objects need to be accessed.
> 
> My application is using Qt QtDbus to access NM, and I am already using it
> to detect whether we are connected to the net, and am listening to the
> state change signal. So I understand how to interface with the Dbus
> component. But I have not found a clear example of how to connect to an AP
> using the interface. I am currently forced to manually set the wifi on our
> target device using the nmcli command (which is using NM to do the
> connection anyway).
> 
> Any suggestions on where to find some example of how to do this? If no
> example then maybe a clear explanation of the steps needed to be taken to
> support this. I need this to allow the device to connect to the network. I
> appreciate any and all comments.
> 


You need to implement org.freedesktop.NetworkManager.SecretAgent
interface and register your provider using
org.freedesktop.NetworkManager.AgentManager interface. NetworkManager
will call you back and request secrets when it needs it.

Example can be found e.g. in ./src/core/tests/test-secret-agent.py in NM
sources. Or nmcli of course (src/nmcli/agent.c).
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: org.freedesktop.NetworkManager.Settings.PropertiesChanged deprecated

[Andrei Borzenkov via networkmanager-list]

On Thu, Jul 15, 2021 at 11:27 AM  wrote:
>
> On Donnerstag, 15. Juli 2021 06:45:06 CEST Andrei Borzenkov via
> networkmanager-list wrote:
> [...]
> > > #!/usr/bin/perl -w
> > >
> > > use strict;
> > >
> > > use Data::Dumper;
> > > $Data::Dumper::Sortkeys = 1;
> > > $Data::Dumper::Indent = 1;
> > > use Net::DBus;
> > > use Net::DBus::Dumper;
> > > use Net::DBus::Reactor;
> > >
> > > my $oBUS = Net::DBus->system || die $!;
> > > my $nm = "org.freedesktop.NetworkManager";
> > > my $oNM = $oBUS->get_service( $nm ) || die $!;
> > > my $nmobjpath = "/org/freedesktop/NetworkManager";
> > > my $nmif = "org.freedesktop.NetworkManager";

my $nmif = "org.freedesktop.DBus.Properties";

> > > my $oNMIF = $oNM->get_object( $nmobjpath, $nmif ) || die $!;
> > >
> > > $nmobjpath = "/org/freedesktop/NetworkManager/Settings";
> > > $nmif = "org.freedesktop.NetworkManager.Settings";

my $nmif = "org.freedesktop.DBus.Properties";

> > > my $oNMIFS = $oNM->get_object( $nmobjpath, $nmif ) || die $!;
> > >
> > > $oNMIF->connect_to_signal(
> > >
> > >   "PropertiesChanged", sub {
> > >
> > > &{ \_onNMPropertiesChanged }( $oNM, $oNMIF, $oNMIFS, @_ );
> > >
> > >   }
> > >
> > > );
> > > my $reactor = Net::DBus::Reactor->main() || die $!;
> > > $reactor->run() || die $!;
> > >
> > > sub dbnm_onNMPropertiesChanged {
> > >
> > >   my( $oNM, $oNMIF, $oNMIFS, $props ) = @_;

my( $oNM, $oNMIF, $oNMIFS, $interface, $props, $invalidated_props ) = @_;

> > >   print "\n- props -\n", Dumper( $props ), "\n--\n";
> > >
> > > }
> >
> > NM PropertiesChanged and D-Bus
> > org.freedesktop.DBus.Properties.PropertiesChanged have different
> > signatures. You are dumping interface name, not properties dictionary.
>
> I am not sure, I understand this:
> The example above is the one for NetworkManager's PropertiesChanged signal.
> It worked perfectly as long as this signal existed.
>


If you replace NM signal with DBus signal you also need to change
handler to look for different parameter

> Besides that, what does "signature" mean in this context? Different
> parameters?
>

Yes.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: org.freedesktop.NetworkManager.Settings.PropertiesChanged deprecated

[Andrei Borzenkov via networkmanager-list]

On Wed, Jul 14, 2021 at 5:52 PM Thomas Haller via networkmanager-list
 wrote:
>
> So, yes, there should be not much to do except replace the interface
> name "org.freedesktop.NetworkManager*" with
> "org.freedesktop.DBus.Properties".
>

It is probably oversimplified. Signatures are different, so any code
that handles these signals has to be modified to account for it. Also
NM signal unambiguously identifies a specific interface, while D-Bus
signal can come from any interface object implements, so additional
verification that we are dealing with the expected interface is needed
before properties can be interpreted.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: org.freedesktop.NetworkManager.Settings.PropertiesChanged deprecated

[Andrei Borzenkov via networkmanager-list]

On 14.07.2021 19:30, m...@mike.franken.de wrote:
> Hi,
> 
> On Mittwoch, 14. Juli 2021 16:52:15 CEST Thomas Haller wrote:
> [...]
>>> so how can I use org.freedesktop.DBus.Properties.PropertiesChanged
>>> then?
>>> What would be the correct way instead?
>>> Using
>>>   my $busobjpath = "/org/freedesktop/NetworkManager/Settings";
>>> as before?
>>> This doesn't work either, though.
>>>
>>> Probably there is a fundamental misunderstanding regaring the concept
>>> on my
>>> side.
>>
>> Hi,
>>
>> I am not familiar with this Perl's Net::DBus, but in general:
>>
>>
>> On D-Bus, you have the well-known name
>> ("org.freedesktop.NetworkManager") where you find NetworkManager's D-
>> Bus API.
>>
>>
>> There, you find many D-Bus objects, at paths that start with
>> "/org/freedesktop/NetworkManager". You see them with `busctl tree
>> org.freedesktop.NetworkManager`.
>>
>> All of these objects also implement the standard D-Bus interface
>> "org.freedesktop.DBus.Properties" -- as documented at
>> https://dbus.freedesktop.org/doc/dbus-specification.html
>> That interface, has (among) others a signal "PropertiesChanged".
>>
>>
>> This "org.freedesktop.DBus.Properties.PropertiesChanged" signal works
>> very similar to the earlier "PropertiesChanged" signals from the NM
>> specific interfaces ( "org.freedesktop.NetworkManager*").
>>
>> So, yes, there should be not much to do except replace the interface
>> name "org.freedesktop.NetworkManager*" with
>> "org.freedesktop.DBus.Properties".
>>
>>
>> you mention specifically
>>
>>   my $busobjpath = "/org/freedesktop/NetworkManager/Settings";
>>
>> In `d-feet` you'll see that this object only has three properties. So
>> you'll see few PropertiesChanged signals on that object...
> 
> Yeah, my fault, I meant
> my $busobjpath = "/org/freedesktop/NetworkManager";
> 
> 8-(
> 
>>
>>
>> Does that help? Otherwise, please share a working, minimal example.
> 
> Ok.
> This is the working example I used before - btw. it stems from a suggestion 
> you made back in 2016/2017 :)
> 
> #!/usr/bin/perl -w
> 
> use strict;
> 
> use Data::Dumper;
> $Data::Dumper::Sortkeys = 1;
> $Data::Dumper::Indent = 1;
> use Net::DBus;
> use Net::DBus::Dumper;
> use Net::DBus::Reactor;
> 
> my $oBUS = Net::DBus->system || die $!;
> my $nm = "org.freedesktop.NetworkManager";
> my $oNM = $oBUS->get_service( $nm ) || die $!;
> my $nmobjpath = "/org/freedesktop/NetworkManager";
> my $nmif = "org.freedesktop.NetworkManager";
> my $oNMIF = $oNM->get_object( $nmobjpath, $nmif ) || die $!;
> 
> $nmobjpath = "/org/freedesktop/NetworkManager/Settings";
> $nmif = "org.freedesktop.NetworkManager.Settings";
> my $oNMIFS = $oNM->get_object( $nmobjpath, $nmif ) || die $!;
> 
> $oNMIF->connect_to_signal(
>   "PropertiesChanged", sub {
> &{ \_onNMPropertiesChanged }( $oNM, $oNMIF, $oNMIFS, @_ );
>   }
> );
> my $reactor = Net::DBus::Reactor->main() || die $!;
> $reactor->run() || die $!;
> 
> sub dbnm_onNMPropertiesChanged {
>   my( $oNM, $oNMIF, $oNMIFS, $props ) = @_;
>   print "\n- props -\n", Dumper( $props ), "\n--\n";
> }
> 


NM PropertiesChanged and D-Bus
org.freedesktop.DBus.Properties.PropertiesChanged have different
signatures. You are dumping interface name, not properties dictionary.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: org.freedesktop.NetworkManager.Settings.PropertiesChanged deprecated

[Andrei Borzenkov via networkmanager-list]

On 14.07.2021 21:57, m...@mike.franken.de wrote:
> RuntimeError: To make asynchronous calls, receive signals or export objects, 
> D-Bus connections must be attached to a main loop by passing mainloop=... to 
> the constructor or calling dbus.set_default_main_loop(...)
> 
> 

Here is full


import dbus, sys, uuid
from dbus.mainloop.glib import DBusGMainLoop
from gi.repository import GLib

DBusGMainLoop(set_as_default=True)

loop = GLib.MainLoop()

def properties_changed(interface_name, changed_properties,
invalidated_properties):
print (interface_name, changed_properties, invalidated_properties)


bus = dbus.SystemBus()
obj = bus.get_object("org.freedesktop.NetworkManager",
"/org/freedesktop/NetworkManager")
iface = dbus.Interface(obj, "org.freedesktop.DBus.Properties")
iface.connect_to_signal("PropertiesChanged", properties_changed)

loop.run()
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: org.freedesktop.NetworkManager.Settings.PropertiesChanged deprecated

[Andrei Borzenkov via networkmanager-list]

On 14.07.2021 19:58, m...@mike.franken.de wrote:
> Hi,
> 
> On Mittwoch, 14. Juli 2021 16:52:53 CEST Andrei Borzenkov via networkmanager-
> list wrote:
> [...]
>>>
>>> Probably there is a fundamental misunderstanding regaring the concept on
>>> my
>>> side.
>>
>> You have object which has properties. When properties change, you get
>> signal *from this object*. If you want to monitor for connectivity
>> changes, you need to monitor active connection.
>>
>> The examples/python/dbus/create-bond.py in NM source tree does precisely
>> that - it monitors for connectivity changes on current connection.
>>
> 
> yes, but because I also need to monitor VPN changes, I have to monitor /o/f/
> NM.
> 

In your original mail you only said "monitor connectivity" so anything
is just guesswork.

>> If you want to monitor overall connectivity, you need to monitor main
>> /o/f/NM object.
> 
> This is, what I did before NetworkManager's PropertiesChanged signal got 
> deprecated.
> My problem is to understand, what path and what interface I have to use in 
> this part of my code, after the PropertiesChanged signal moved from 
> NetworkManager to DBus:
> 
> my $busobjpath = "org.freedesktop.NetworkManager";
> my $busif = "org.freedesktop.DBus.Properties";
> my $oBUSIF = $oBUSSVC->get_object( $busobjpath, $busif ) || die $!;
> $oBUSIF->connect_to_signal(
>   "PropertiesChanged", sub {
> &{ \ }( @_ )
>   } || die $!;
> }
> 

I do not see any reference to object here so I have no idea what this
code does. The following certainly works

def properties_changed(interface_name, changed_properties,
invalidated_properties):
print (interface_name, changed_properties, invalidated_properties)


bus = dbus.SystemBus()
obj = bus.get_object("org.freedesktop.NetworkManager",
"/org/freedesktop/NetworkManager")
iface = dbus.Interface(obj, "org.freedesktop.DBus.Properties")
iface.connect_to_signal("PropertiesChanged", properties_changed)


> The original code now tells me
> 
> no signal PropertiesChanged in interface org.freedesktop.NetworkManager at /
> usr/lib/perl5/vendor_perl/5.32.1/x86_64-linux-thread-multi/Net/DBus/Binding/
> Introspector.pm line 420.
> 
> which seemed clear to me, because it got deprecated.
> 
> 
> Thx and bye.
> Michael.
> 
> 
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
> 

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: org.freedesktop.NetworkManager.Settings.PropertiesChanged deprecated

[Andrei Borzenkov via networkmanager-list]

On 14.07.2021 14:32, m...@mike.franken.de wrote:
> Hi,
> 
> thx for your answer.
> 
> On Mittwoch, 14. Juli 2021 13:19:44 CEST Thomas Haller wrote:
> [...]
>>> I use the perl module Net::DBus for this job.
>>> The following snippet shows how far I got up to date:
>>>
>>>   my $busobjpath = "/org/freedesktop/DBus/Properties";
>>
>> Such an object path does not exist on NetworkManager's D-Bus API.
>>
>> Object paths start with "/org/freedesktop/NetworkManager".
>>
>> See all object with `d-feet` or `busctl tree
>> org.freedesktop.NetworkManager`.
> 
> so how can I use org.freedesktop.DBus.Properties.PropertiesChanged then?
> What would be the correct way instead?
> Using
>   my $busobjpath = "/org/freedesktop/NetworkManager/Settings";
> as before?

You need to use the object whose properties you want to monitor.

> This doesn't work either, though.
> 
> Probably there is a fundamental misunderstanding regaring the concept on my 
> side.
> 

You have object which has properties. When properties change, you get
signal *from this object*. If you want to monitor for connectivity
changes, you need to monitor active connection.

The examples/python/dbus/create-bond.py in NM source tree does precisely
that - it monitors for connectivity changes on current connection.

If you want to monitor overall connectivity, you need to monitor main
/o/f/NM object.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: VPN connection disappeared from networkmanager

[Andrei Borzenkov via networkmanager-list]

On 11.07.2021 19:30, David H Durgee via networkmanager-list wrote:
> As you can see froman earlier post I am working to add a VPN connection
> to secure my connection when out of the office.  I don't know how or
> why, but my VPN connection no longer shows in the connections list!
> Given this of course it is impossible to activate it.
> 
> Looking at /etc/NetworkManager/system-connections shows the
> configuration file still present, so something has happened at a higher
> level.
> 

Does

nmcli connection

show it?

> What do I need to do to correct this? What other files need to be fixed?
> If I go into network settings and hit the "+" I see IPSec/IKEv2
> (strongswan) as an option, but selecting it wants to define a new entry
> not revive a lost one.
> 
> Help!
> 
> This is with nmcli version 1.22.10 on linux mint 20.1 x64 cinnamon release.
> 
> Dave
> 
> 
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
> 

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Understanding IPv6-PD over PPPoE

[Andrei Borzenkov via networkmanager-list]

On Wed, Jun 16, 2021 at 12:28 PM Steve Hill  wrote:
>
> On 16/06/2021 10:07, Andrei Borzenkov wrote:
>
> > The default and standard method to assign IPv6 address is SLAAC.
> > DHCPv6 is optional. You need to investigate why SLAAC address was not
> > assigned.
>
> As I said, I'm not 100% sure that the ISP is behaving correctly,
> although Bjørn indicated that what they are doing is fairly common.
>
> That said, I'm not sure I've ever seen an ISP use SLAAC over PPP, so is
> this *really* in any way standard?
>

SLAAC is used by your own system, not ISP. ISP sends RA. Your system
uses SLAAC to build address using these RA. You yourself said they are
present (you mentioned M an O flags).

Do you mean these RAs do not contain any valid prefix?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Understanding IPv6-PD over PPPoE

[Andrei Borzenkov via networkmanager-list]

On Wed, Jun 16, 2021 at 12:13 PM Beniamino Galvani  wrote:
>
> On Wed, Jun 16, 2021 at 11:43:36AM +0300, Andrei Borzenkov wrote:
>
> > It is explicitly prohibited to assign any IA_PD prefix to the same
> > interface via which this was obtained.
> >
> >   the requesting router MUST
> >NOT assign any delegated prefixes or subnets from the delegated
> >prefix(es) to the link through which it received the DHCP message
> >from the delegating router.
>
> You are right, RFC 3633 forbids it. However, if I understand correctly
> this approach is the one mentioned in [1], which refers to an expired
> IETF draft [2] saying:
>
>As stated in [RFC 3633], "the requesting router MUST NOT assign any
>delegated prefixes or subnets from the delegated prefix(es) to the
>link through which is received the DHCP message from the delegating
>router", however the approach described in this document may still
>be useful in other DHCPv6 scenarios or non-DHCPv6 scenarios.
>Moreover, [RFC 3769] has no explicit requirement that avoids the
>approach described in this document.  Furthermore, this has been
>tested in DHCPv6-PD implementations and worked well, so we must say
>that it may be implementation-dependent.
>
> From [1], it seems that some ISPs are using this method. It would be
> interesting to research what e.g OpenWRT or other OSes do.
>
> Beniamino
>
> [1] 
> https://www.ripe.net/publications/docs/ripe-690#4-1-4---64-prefix-out-of-the-ipv6-prefix-assigned-to-the-end-user
> [2] https://datatracker.ietf.org/doc/html/draft-palet-v6ops-point2point-01
>
>

Well, there is RFC6603. You still need to have some reasonable
fallback in case prefix exclusion is not supported by the upstream
router. And even *with* prefix exclusion the actual assignment of
prefix to link goes via RA and actual address assignment via SLAAC,
not via DHCP (at least, not mandatory). Prefix exclusion just informs
which part of delegated prefixes cannot be assigned downstream.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Understanding IPv6-PD over PPPoE

[Andrei Borzenkov via networkmanager-list]

On Wed, Jun 16, 2021 at 12:03 PM Steve Hill  wrote:
>
> On 16/06/2021 09:43, Andrei Borzenkov wrote:
>
> > It is explicitly prohibited to assign any IA_PD prefix to the same
> > interface via which this was obtained.
> >
> >the requesting router MUST
> > NOT assign any delegated prefixes or subnets from the delegated
> > prefix(es) to the link through which it received the DHCP message
> > from the delegating router.
>
> [...Which is from RFC 3633]
>
> That's a pain.  It basically makes it impossible for a single-NIC
> machine to connect to an ISP that is only responding to IA_PD.  (Well,
> you can obviously set up a dummy NIC, which can be assigned a prefix,
> but that's a kludge).
>
> I can see why you wouldn't want a whole /64 to be assigned to an
> ethernet interface that received the DHCPv6 Advertise, but it does feel
> reasonable to be able to *optionally* assign a /128 to the
> point-to-point link that received the DHCPv6 Advertise, if there is no
> other way to assign a global address to it.
>


The default and standard method to assign IPv6 address is SLAAC.
DHCPv6 is optional. You need to investigate why SLAAC address was not
assigned.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Understanding IPv6-PD over PPPoE

[Andrei Borzenkov via networkmanager-list]

On Wed, Jun 16, 2021 at 11:39 AM Beniamino Galvani via
networkmanager-list  wrote:
> >
> > It feels as though NetworkManager should always be making both IA_NA and
> > IA_PD requests and, if it didn't receive an IA_NA response from the ISP, it
> > should assign an address from the delegated prefix to the PPP interface.
> > This would prevent the situation where a machine with no
> > "ipv6.method=shared" NICs ends up with no public v6 address at all.
> >
> >
> > Any insight would be appreciated - many thanks. :)
>
> Hi,
>
> as you have seen, currently NM only requests a prefix delegation when
> there is an other interface in IPv6 shared mode. The IPv6 address on
> the PPP interface itself can only be obtained via SLAAC or
> DHCPv6(IA_NA), not via DHCPv6(IA_PD).
>
> I'm not sure how the latter is common; to support it, NM would need to
> always request a prefix delegation (even without another interface in
> shared mode) or, better, to have a new option to make this behavior
> configurable (for example, "ipv6.dhcp-request-pd=yes|no|auto").
>

It is explicitly prohibited to assign any IA_PD prefix to the same
interface via which this was obtained.

  the requesting router MUST
   NOT assign any delegated prefixes or subnets from the delegated
   prefix(es) to the link through which it received the DHCP message
   from the delegating router.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to configure NM using dhclient-script file

[Andrei Borzenkov via networkmanager-list]

That's rather concise answers.

28.11.2020 06:00, Mars via networkmanager-list пишет:
> Hi Thomas,
> 
> 
> Much thanks for your reply,  my problem is that NM cannot deal with the 
> DHCPv6 message with IA_PD option,

It is unclear what you mean here. NM supports IA_PD for connection
sharing, it will use prefixes provided by IA_PD on upstream interface to
configure downstream interface. Downstream interface (or more precisely
- connection active on downstream interface) has to be configured with
ipv6.method=shared.

You need to describe what you have configured, what results did you
expect and what results you observe before any useful comment can be made.


> the default IA_NA option with NM cannot  generate the right prefixlen, just 
> configuring 128 .
> 

Is it separate issue or somehow connected to the previous one?

DHCPv6 does not provide address prefix length at all. Every address
returned by "IA Address" DHCPv6 option has prefix 128.

Again you need to explain what you observe and what exactly does not
work or works incorrectly and why you think it is related to address
prefix length.

> 
> Best Regards
> --
> Mars
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> At 2020-11-27 17:54:26, "Thomas Haller"  wrote:
>> On Fri, 2020-11-27 at 09:48 +0800, Mars via networkmanager-list wrote:
>>> hi,
>>> NM uses nm-dhcp-helper as network configuration script for dhclient
>>> as follows , how to confiure dhclient-script file within NM ?
>>>
>>> /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper -pf
>>> /var/run/dhclient-eth0.pid -lf /var/lib/NetworkManager/dhclient-
>>> 5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03-eth0.lease -cf
>>> /var/lib/NetworkManager/dhclient-eth0.conf eth0
>>> Thank you very much for any help you can provide.
>>
>>
>> Hi,
>>
>>
>> You cannot (*). When NetworkManager runs dhclient, then this is mostly
>> an implementation detail for doing DHCP. Sure, it honors dhclient's
>> config files in /etc/dhcp and it also dispatches the dhclient hooks.
>> That is very powerful (since it's just arbitrary scripts that get
>> executed), but it's also undesirable because the funcitonality is not
>> available with dhcp=internal plugin and not available via
>> NetworkManager API and NetworkManager mostly doens't know what is
>> happening there. But in general, this is not supposed to give the user
>> direct access to dhclient.
>>
>> (*) well, of course you can do all kind of hacky solutions, like
>> replacing /usr/libexec/nm-dhcp-helper with a wrapper script.
>>
>> It might be better to explain what you ultimately want to do. Instead
>> of asking how to do something that you think might be a solution for
>> you (without explainging what your actual problem is).
>>
>>
>> best,
>> Thomas
>>
>> ___
>> networkmanager-list mailing list
>> networkmanager-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/networkmanager-list

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Putting interface always up with NetworkManager

[Andrei Borzenkov via networkmanager-list]

16.10.2020 13:19, Andrei Petru Mura пишет:
> Hi Andrei,
> 
> What value should I set to ignore-carrier?
> Is it ok if I proceed like this:
> 
> in /etc/NetworkManager/conf.d/general.conf
> 
> I'll put this:
> [device]
> match-device=interface-name:enp5s0f1
> ignore-carrier=yes
> 
> ?
> 

Works for me.

> Thanks,
> Mura Andrei
> 
> On Fri, Oct 16, 2020 at 10:56 AM Andrei Borzenkov 
> wrote:
> 
>> On Fri, Oct 16, 2020 at 10:15 AM Andrei Petru Mura via
>> networkmanager-list  wrote:
>>>
>>> Hi,
>>>
>>> In my CentOS 8, I want to make my network card to be configured at boot
>> time. The networking is managed by NetworkManager. I configured the
>> connection with nmcli as such:
>>>
>>> nmcli con add type ethernet ifname enp5s0f1 con-name enp5s0f1
>> autoconnect yes save yes ipv4.addresses 192.168.1.10/25 ipv4.method manual
>>>
>>> The problem is that when I reboot the machine, the interface is down. In
>> order to have it available, I have to always up it first:
>>>
>>> nmcli con up enp5s0f1
>>>
>>> Is there a way to force it via NetworkManager to be always up?
>>
>> You can set ignore-carrier device property in NetworkManager.conf.
>>
> 

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Putting interface always up with NetworkManager

[Andrei Borzenkov via networkmanager-list]

On Fri, Oct 16, 2020 at 10:15 AM Andrei Petru Mura via
networkmanager-list  wrote:
>
> Hi,
>
> In my CentOS 8, I want to make my network card to be configured at boot time. 
> The networking is managed by NetworkManager. I configured the connection with 
> nmcli as such:
>
> nmcli con add type ethernet ifname enp5s0f1 con-name enp5s0f1 autoconnect yes 
> save yes ipv4.addresses 192.168.1.10/25 ipv4.method manual
>
> The problem is that when I reboot the machine, the interface is down. In 
> order to have it available, I have to always up it first:
>
> nmcli con up enp5s0f1
>
> Is there a way to force it via NetworkManager to be always up?

You can set ignore-carrier device property in NetworkManager.conf.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to send DHCPv6 request with IA-PD option within NM

[Andrei Borzenkov via networkmanager-list]

On Fri, Aug 28, 2020 at 12:45 PM Mars via networkmanager-list
 wrote:
>
> hi all,
>
> For CentOS 8, NetworkManager is default to manage and configure network 
> devices,  I want to obtain IPv6 address via dhcpv6, found NM always send 
> dhcpv6 packet with ia-na option, I tried internal dhcp client and dhclient 
> tool, but it didn't work.  I also changed the ipv6.method, the result is same.
>   anyone has any idea? any is appreciated.
>


NM requests prefix delegation if you configure connection sharing:

https://fedoramagazine.org/internet-connection-sharing-networkmanager/
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NetworkManager removes *STATIC* IP address from interface when link down

[Andrei Borzenkov via networkmanager-list]

07.07.2020 04:51, Graham пишет:
> Thomas, I'm still struggling with this one.
> 
> I read the man page and have created a new file in
> /etc/NetworkManager/conf.d
> 
> I also note that the "main" option that you suggested is deprecated in
> favour of per-device options, but I have been unable to get either
> version to work.
> 
> The man page gives no examples of usage, so I tried a few things. Listed
> below is what I tried.
> 
> 
> Any suggestions?
> 
> 
> 
> [main]
> 
> main.ignore-carrier
> 
> (this would stop NetworkManager from running)
> 
> [main]
> 
> main.ignore-carrier=1
> 
> (no change, link down would cause IP address deconfigure)
> 
> [main]
> 
> main.ignore-carrier=enp6s0
> 
> (no change, link down would cause IP address deconfigure)
> 

This should have been

[main]
ignore-carrier=enp6s0

> [enp6s0]
> 
> ignore-carrier
> 
> (this would stop NetworkManager from running)
> 
> [enp6s0]
> 
> ignore-carrier=1
> 
> (no change, link down would cause IP address deconfigure)
> 
> [enp6s0]
> 
> ignore-carrier=true
> 
> (no change, link down would cause IP address deconfigure)
> 
> [enp6s0]
> 
> match-device=interface-name:enp6s0
> 
> ignore-carrier=1
> 
> (no change, link down would cause IP address deconfigure)
> 

None of these will work.

[device]
ignore-carrier=true

will ignore carrier for all devices

[device-ignore-carrier]
match-device=enp0s0
ignore-carrier=true

Will apply ignore-carrier according to match list.

And yes, NM manuals are hard to understand without also looking at the
sources.

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Need help porting ifcfg-ppp0 config to NetworkManager

[Andrei Borzenkov via networkmanager-list]

28.03.2020 00:30, Beniamino Galvani via networkmanager-list пишет:
> On Thu, Mar 26, 2020 at 09:09:36AM +, David Howells via 
> networkmanager-list wrote:
>> Hi,
>>
>> I need some help porting an ifcfg-ppp0 config from my old internet gateway
>> which was running to Fedora 16 to my new internet gateway which is running
>> F31.  Running "ifup ppp0" gives a message saying that this is deprecated and 
>> I
>> should switch to NM.
>>
>> Unfortunately, I can't work out how to configure NM to do this.  I can see
>> options for connections of ppp, (a)dsl and pppoe type, but I seem to need 
>> some
>> combination of these and that does not appear to be possible to configure 
>> with
>> nmcli, plus some pppd options (such as "ipv6" and "holdoff") that aren't
>> listed in the documentation.
>>
>> My (redacted) config is below.
>>
>> Thanks,
>> David
>> ---
>> [root@gatekeeper ~]# cat /etc/sysconfig/network-scripts/ifcfg-ppp0 
>> BOOTPROTO=dialup
>> DEFROUTE=yes
>> DEMAND=no
>> FIREWALL=NONE
>> ONBOOT=yes
>> PEERDNS=yes
>> PERSIST=yes
>> PIDFILE=/var/run/pppoe-adsl.pid
>> PING=.
>> SYNCHRONOUS=no
>> TYPE=xDSL
>> USERCTL=yes
>>
>> CONNECT_POLL=6
>> CONNECT_TIMEOUT=3600
>> DEVICE=ppp0
>> ETH=enp4s0
>> IPV6INIT=yes
>> LCP_FAILURE=120
>> LCP_INTERVAL=1
>> LINUX_PLUGIN=rp-pppoe.so
>> MRU=1492
>> MTU=1492
>> PPPOE_TIMEOUT=80
>>
>> PPPD_EXTRA="ipv6 , holdoff 1"
>> IPADDR=
>> USER=
> 
> Hi,
> 
> this should create a connection mostly equivalent to your
> configuration:
> 
>  nmcli connection add \
>type pppoe ifname ppp0 pppoe.parent enp4s0 \
>pppoe.user $myuser pppoe.password $mypw \
>ppp.mru 1492 ppp.mtu 1492 \
>ppp.lcp-echo-interval 1 ppp.lcp-echo-failure 120 \
>ipv4.address $myip
> 
> 'man nm-settings' shows all the properties supported by NM. I don't
> think "holdoff 1" is needed as NM always waits some seconds before
> reinitiating the connection. Also, I'm not sure IPv6 is supported. You
> could try adding 'ipv6.method manual ipv6.addresses $myip6' but it
> doesn't seem possible to specify a peer address.
> 

The same effect can probably be achieved by setting /128 local address
and adding /128 route to peer address.

> Note that the connection has 'autoconnect yes' by default and so it is
> started automatically at boot. If you want to activate it manually,
> you should also set 'autoconnect no', and then control it with:
> 
>  nmcli connection {up|down} pppoe-ppp0
> 
> Beniamino
> 
> 
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
> 




signature.asc
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Set permanent route to IPv6 subnet on interface

[Andrei Borzenkov via networkmanager-list]

26.03.2020 11:15, Jeremy Ardley пишет:
> What is the best NetworkManager method to add a permanent route to an
> ipv6 subnet on an interface?
> 
> I can add a temporary route outside of NetworkManager thus:
> 
> ip -6 route add 2001:db8:c111:b000::/56 dev eth0
> 

Many aspects of IPv6 implicitly expect /64 network prefix. If this is
what your router advertises, it likely explains why autoconfiguration
does not work in you case.

> Where should this be done in NetworkManager and what is the correct syntax?
> 

Works for me if I define static route with :: (empty) gateway. :: is
shorthand for all zeroes. Where to define static route depends on used
frontend, but normally you should have IPv6 tab which also Routes button.

bor@tw:~> nmcli -g ipv6.routes con show Wired\ connection\ 2
fd01\:2345\:6789\:ab00\:\:/56 0
bor@tw:~> ip -6 r
::1 dev lo proto kernel metric 256 pref medium
fd01:2345:6789:ab00::/56 dev enp0s5 proto static metric 1024 pref medium
...


> (in this instance the interface eth0 also has an assigned ipv6 /128
> address in the subnet range)
> 
> 
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
> 

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPV6 auto method not working

[Andrei Borzenkov via networkmanager-list]

26.03.2020 02:48, Jeremy Ardley пишет:
> I have a debian stretch system acting as a client.
> 
> I have another system acting as ipv6 router and dhcpv6 server . I am
> using isc-dhcp-server and radvd router advertisements.
> 
> My issue is that the client instance of NetworkManager is not behaving
> as expected
> 
> This stanza does not attempt to get an ipv6 address
> 
> [ipv6]
> addr-gen-mode=eui64
> dns-search=
> ip6-privacy=2
> may-fail=false
> method=auto
> 
> This stanza gets an ipv6 address but does not get a default route
> (expected to not pick up default route)
> 
> [ipv6]
> addr-gen-mode=eui64
> dns-search=
> ip6-privacy=2
> may-fail=false
> method=dhcp
> 

I tentatively say it is your environment mis-configuration. DHCPv6 does
not have default gateway option at all. Default gateway is supplied by
RA from router. If "auto" fails to obtain address, it sounds like your
router does not send RA at all.

> I also have ipv4 enabled in the connection and it works correctly
> 
> I have run wireshark on the client and see no dhcp6 related traffic when
> method=auto.
> 

Client should be using DHCPv6 only if RA contains M or O bit; do you see
any RA at all? What is their content?

> version: network-manager-gnome/oldstable,now 1.4.4-1+deb9u1 amd64
> [installed]
> 
> 
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
> 

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Listing currently registered secret agents?

[Andrei Borzenkov via networkmanager-list]

Is there any way to see which secret agents are currently registered
with NM? basically to see where user connection secrets may be stored?

Thank you!
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Using both VPN and non-VPN (default route non-VPN)

[Andrei Borzenkov via networkmanager-list]

10.12.2018 21:02, Alexandre Garreau via networkmanager-list пишет:
> On 2018-12-10 at 18:16, Thomas Haller wrote:
>> you need to have the routes configured properly, which depends on your
>> environment.
> 
> Maybe should I ask on debian mailing-lists (not that much active, not
> sure I can get more relevant help than here)?
> 
>> Well, NM should get it right automatically. If it doesn't,
>> then you should look at the routes to understand what's wrong.
>>
>> What gives:
>>
>>   ip route
> 
> Currently I’m not at the needed local network, so doing it at home, with
> normally configured network, I get:
> 
> galex-713@portable:~/doc/comp/src/pharo/opensmalltalk-vm$ ip route
> default dev tun0 proto static scope link metric 50 
> default via 192.168.1.254 dev enp0s25 proto static metric 100 
> 89.234.186.64/27 dev tun0 proto kernel scope link src 89.234.186.82 metric 50 
> 169.254.0.0/16 dev enp0s25 scope link metric 1000 
> 192.168.1.0/24 dev enp0s25 proto kernel scope link src 192.168.1.38 metric 
> 100 
> 
> When enabling “VPN config > IPv4 Settings > Routes… > Use this
> connection only for resources on its network” checkbox, I get this:
> 
> galex-713@portable:~/doc/comp/src/pharo/opensmalltalk-vm$ ip route
> default via 192.168.1.254 dev enp0s25 proto static metric 100 
> 89.234.186.64/27 dev tun0 proto kernel scope link src 89.234.186.82 metric 50 
> 89.234.186.190 via 192.168.1.254 dev enp0s25 proto static metric 100 
> 169.254.0.0/16 dev enp0s25 scope link metric 1000 
> 192.168.1.0/24 dev enp0s25 proto kernel scope link src 192.168.1.38 metric 
> 100 
> 192.168.1.254 dev enp0s25 proto static scope link metric 100 
> 
> I’m under Debian GNU/Linux stable, x86 (32bits).
> 
> Btw ifconfig:
> galex-713@portable:~/doc/comp/src/pharo/opensmalltalk-vm$ /sbin/ifconfig
> enp0s25: flags=4163  mtu 1500
> inet 192.168.1.38  netmask 255.255.255.0  broadcast 192.168.1.255
> inet6 2a01:e0a:54:cb90:dd93:58f3:5591:dc39  prefixlen 64  scopeid 
> 0x0
> inet6 fe80::6a50:6fa8:1bc9:b6d1  prefixlen 64  scopeid 0x20
> ether 00:1f:16:14:45:a9  txqueuelen 1000  (Ethernet)
> RX packets 425383  bytes 300655547 (286.7 MiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 94334  bytes 15010937 (14.3 MiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> device interrupt 20  memory 0xf270-f272  
> 
> lo: flags=73  mtu 65536
> inet 127.0.0.1  netmask 255.0.0.0
> inet6 ::1  prefixlen 128  scopeid 0x10
> loop  txqueuelen 1  (Boucle locale)
> RX packets 1544  bytes 185223 (180.8 KiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 1544  bytes 185223 (180.8 KiB)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> tun0: flags=4305  mtu 1500
> inet 89.234.186.82  netmask 255.255.255.224  destination 89.234.186.82
> inet6 fe80::918:d4aa:a0ae:2b1d  prefixlen 64  scopeid 0x20
> inet6 2a00:5884:8305::1  prefixlen 112  scopeid 0x0
> unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 
> 100  (UNSPEC)
> RX packets 12  bytes 1476 (1.4 KiB)
> RX errors 0  dropped 0  overruns 0  frame 0
> TX packets 12  bytes 808 (808.0 B)
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> 
> both interfaces are only present, but only tun0 works in the first case,
> and only enps25 works in the second.
> 


You need to explain what "works" means. According to your routing
tables, you should have access to local network 192.168.1.0/24 in both
cases. At least if I interpret your "need local network" correctly, that
is what you need. If this is not what you want, show what does not work
in each case.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Writing resolv.conf issues with broken symlink

[Andrei Borzenkov]

31.05.2018 22:02, Matthew Starr пишет:
> I am building NetworkManager 1.8.0 using buildroot with SysV init on an ARM 
> embedded device.  Buildroot has the /etc/resolv.conf file as a symlink that 
> points to /tmp/resolv.conf.  When I use NetworkManager with this resolv.conf 
> symlink configuration, DNS lookups do no work because NetworkManger is not 
> writing to the resolv.conf file or the file pointed to by the symlink.
> 
> I tried updating the NetworkManager.conf file to include "rc-manager=file" 
> since the man page states that NetworkManager will then follow the symlink 
> and write the contents of the resolv.conf there.  Unfortunately this does not 
> work when the destination file the symlink points to does not exist.  In this 
> situation the symlink points to a file in /tmp which is a tmpfs file system 
> (RAM based) and wiped clean on each boot to help support  a read-only root 
> file system or doing minimal writes to the root file system.
> 
> Is there a specific reason NetworkManager doesn't create the file the 
> /etc/resolv.conf symlink points to if it doesn't exist?  If there isn't a 
> reason, could NetworkManager be updated to create the file pointed to by the 
> /etc/resolv.conf symlink?
> 

Cannot you configure NM to manage /tmp/resolv.conf instead and leave
/etc/resolv.conf as permanent link to it?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Problem I've been having with dhclient dhcp in Fedora27

[Andrei Borzenkov]

04.01.2018 23:59, dpr...@deepplum.com пишет:
> I've been having problems with NetworkManager dhcp on my Fedora27 Workstation 
> (desktop, wired).. Note, because I'm using VMs on that workstation, the 
> interface is a bridge (br0 with slave eno1).
> 
> What seems to happen is this:
> 
> Workstation wakes up from sleeping, reactivates connection.
> 
> dhclient issues 4 DHCPDISCOVER tries, none of which get a response.
> 
> the interface state changes "unknown-->timeout->done", and the DHCPv4 
> transaction is cancelled.
> 
> A restart is scheduled for 120 seconds later.
> 
> The restart 120 seconds later succeeds with DHCPDISCOVER, DHCPREQUEST, 
> DHCPOFFER, DHCPACK.
> 

One possible reason is spanning tree on switch port, in which case there
is timeout before port goes in forwarding state.

> All the other machines served by my DHCP server have no problems at all, 
> however, they are MacBooks, various storage servers, and RaspberryPis.
> 
> It seems to be that NetworkManager somehow interferes with the DHCPDISCOVER 
> after the workstation wakes up.
> 
> The attached log file shows this sequence of events.
> 
> (I'm wondering if there is a timing issue because the first dhclient call is 
> issued when eno1 is in the "unavailable" state, and before it is captured as 
> a 
> slave to br0)
> 
> 
> 
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
> 

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

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

[Andrei Borzenkov]

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 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 in the RFCs about
> what must be done when the lease expired. 

RFC requires that when upon lease expiration client stop using address
(actually it literally says "stop any network activity") and return to
initial state of acquiring address.

> Defaulting to fail the
> interface from NM point of view is certainly undesired behaviour.
> 

That is what is required by RFC. You cannot continue to use address
allocated by DHCP server after lease has expired unless you succeeded in
extending (renewing) lease.

>> A change in the default NetworkManager.conf can switch it off for
>> default connections leaving the feature there if needed:
>> (https://bugzilla.redhat.com/show_bug.cgi?id=1350830#c7).
> 
> -EPERM
> 
> Olaf
> 
> 
> 
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
> 




signature.asc
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] dhcp/dhclient: Improve "interface" statement parsing

[Andrei Borzenkov]

On Thu, Jul 6, 2017 at 1:05 PM, Jonathan Kang  wrote:
> The previous email was on hold because of the unsubscribed mail account.
>
> -- Forwarded message -
> From: Jonathan Kang 
> Date: Thu, Jul 6, 2017 at 4:34 PM
> Subject: [PATCH] dhcp/dhclient: Improve "interface" statement parsing
> To: networkmanager-list@gnome.org 
>
>
> Hi
>
> This is a patch

Are you sure you did not forget to attach patch?

> improving "interface" statement parsing, which fixes
> https://bugzilla.opensuse.org/show_bug.cgi?id=1047004.
>
> dhcp/dhclient: Improve "interface" statement parsing
>
> In commit d405cfd9089f9552969e6a3e1a1c4550fc3c1695, parsing "interface"
> statement is introduced. But it leads to uncommplete parsing of the
> "request" entry, if one of the lines in "request" entry is prefixed with
> word "interface". For example, the default configuration of openSUSE
> distribution:
>
> request subnet-mask, broadcast-address, routers,
> rfc3442-classless-static-routes,
> interface-mtu, host-name, domain-name, domain-search,
> domain-name-servers, nis-domain, nis-servers,
> nds-context, nds-servers, nds-tree-name,
> netbios-name-servers, netbios-dd-server,
> netbios-node-type, netbios-scope, ntp-servers;
>
> Fixes commit d405cfd9089f9552969e6a3e1a1c4550fc3c1695.
>
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH 1/1] start after systemd-networkd

[Andrei Borzenkov]

25.11.2015 18:11, Thomas Haller пишет:
> On Wed, 2015-11-25 at 15:36 +0100, Christian Hesse wrote:
>> Thomas Haller  on Wed, 2015/11/25 15:11:
>>> On Wed, 2015-11-25 at 11:53 +0100, Christian Hess wrote:
 From: Christian Hesse 

 It is possible to use systemd-networkd for some general network
 setup
 (rename devices, ...) even for devices that are managed by
 NetworkManager later.
> 
> 
> (does networkd rename device? I'd think that is be done by udev).
> 

That's correct. Interfaces are renamed by udev, not by systemd-networkd.
They share configuration files (foo.link) but NamePolicy part is
interpreted by udev only.



signature.asc
Description: OpenPGP digital signature
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 with DHCP -- how is default route set?

[Andrei Borzenkov]

20.10.2015 19:37, Eloy Paris пишет:


I realize now that it is not that nothing happened but that things took
a long time (a couple of minutes) to happen -- first, there was a delay
to get an IPv6 address, and then there was a delay (after the interface
had a global IPv6 address) to see the default route installed.

Are these delays normal; do they depend on the frequency of router
advertisements? If so, can NM not elicit a router advertisements by
sending a router solicitation? If that is what is supposed to happen
then I don't understand the delays. In contrast, IPv4 configuration is
immediate.



  MaxRtrAdvInterval
 The maximum time allowed between sending
 unsolicited multicast Router Advertisements from
 the interface, in seconds.  MUST be no less than 4
 seconds and no greater than 1800 seconds.

 Default: 600 seconds

Routers are expected to send advertisements in random intervals between 
minimal and maximal interval, in the worst case you may have 30 minutes ...



___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IPv6 with DHCP -- how is default route set?

[Andrei Borzenkov]

20.10.2015 21:23, Eloy Paris пишет:


Do we not send router solicitation messages to avoid having to wait for
the next router advertisement message, which could happen who knows
when?



Yes. I do not know if NM does it.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How to configure a DHCP + (2nd) Static address (eg on eth0+eth0:0)?

[Andrei Borzenkov]

29.09.2015 20:54, Dan Williams пишет:



Basically I want to automate NM doing, effectively:

   ifconfig eth0:0 192.168.x.y


Don't do this with interface aliases; the kernel is perfectly capable of
using more than one address on the same interface.  Simply do:

ip addr add 192.168.x.y/24 dev eth0

and magically you'll have two.




This makes addresses invisible in ifconfig output and that may confuse 
legacy software (I know about at least one such case). Adding "label 
xxx" will emulate legacy aliases enough to make them appear as "normal" 
interface.

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

[Andrei Borzenkov]

В Mon, 15 Dec 2014 14:20:45 -0600
Dan Williams d...@redhat.com пишет:

 On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote:
  В Mon, 15 Dec 2014 11:34:17 -0600
  Dan Williams d...@redhat.com пишет:
  
   
   On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote:
On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 NetworkManager sets logind inhibitor lock to monitor for suspend
 events. So it implicitly requires logind to be present when NM
 starts.
   
   NM doesn't actually require that, it just wants to know about the
   signals that logind sends and have a chance to respond to them.  If
   logind isn't running, NM shouldn't really care.  But perhaps expectation
   is not matching reality in the code.
   
Any idea what it needs the inhibitor for?
   
   To be aware of suspend/resume events of course.  NM may want to
   disconnect the network cleanly before suspending, and on resume may need
   to clean up network connections and restart certain operations.
   
 logind is ordered after nss-user-lookup.target. If we have remote
   user
 database, it means that logind depends on network to be up and
   running.
 
 If network is provided by NetworkManager we have a loop.
 
 Due to the fact that NetworkManager service itself does not declare
 dependency on logind, it can be pretty hard to recognize.
 
 Any idea how it can be solved nicely? I can only think of delaying
 inhibitor logic in NM until logind is started. Not sure what side
 effects it may have.

Yeah, I figure if they want to be able to run in early parts of boot
they should watch logind's bus name and create their inhibitor only
after it appears.
   
   Does logind get D-Bus autolaunched?
  
  Yes.
  
  NM is just creating a bus proxy for
   the logind DBus service, and then attempting to call a D-Bus method on
   logind to take an inhibitor.  It doesn't actually care that much about
   the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to
   prohibit logind from launching.
   
   Perhaps NM is requesting logind to start through D-Bus autolaunch, but
   since the network isn't up yet logind then fails itself?
   
  
  systemd tries to launch logind service which now waits for services it
  is ordered After and eventually times out.
 
 NM patch filed for review by NM dev team:
 
 https://bugzilla.gnome.org/show_bug.cgi?id=741572
 

Yes it was reported to fix the problems during system startup. Thank
you!

I wonder if there is any way to delay suspend in race free way.

 Also, I don't think logind should fail if there is no network;

Logind was not even started - systemd waited for required services to
start it and timed out.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [systemd-devel] Cycle between logind and NetworkManager in case of remote user database

[Andrei Borzenkov]

В Mon, 15 Dec 2014 11:34:17 -0600
Dan Williams d...@redhat.com пишет:

 
 On Mon, 2014-12-15 at 16:11 +0100, Lennart Poettering wrote:
  On Sat, 13.12.14 10:09, Andrei Borzenkov (arvidj...@gmail.com) wrote:
  
   NetworkManager sets logind inhibitor lock to monitor for suspend
   events. So it implicitly requires logind to be present when NM
   starts.
 
 NM doesn't actually require that, it just wants to know about the
 signals that logind sends and have a chance to respond to them.  If
 logind isn't running, NM shouldn't really care.  But perhaps expectation
 is not matching reality in the code.
 
  Any idea what it needs the inhibitor for?
 
 To be aware of suspend/resume events of course.  NM may want to
 disconnect the network cleanly before suspending, and on resume may need
 to clean up network connections and restart certain operations.
 
   logind is ordered after nss-user-lookup.target. If we have remote
 user
   database, it means that logind depends on network to be up and
 running.
   
   If network is provided by NetworkManager we have a loop.
   
   Due to the fact that NetworkManager service itself does not declare
   dependency on logind, it can be pretty hard to recognize.
   
   Any idea how it can be solved nicely? I can only think of delaying
   inhibitor logic in NM until logind is started. Not sure what side
   effects it may have.
  
  Yeah, I figure if they want to be able to run in early parts of boot
  they should watch logind's bus name and create their inhibitor only
  after it appears.
 
 Does logind get D-Bus autolaunched?

Yes.

NM is just creating a bus proxy for
 the logind DBus service, and then attempting to call a D-Bus method on
 logind to take an inhibitor.  It doesn't actually care that much about
 the result, but NM doesn't pass G_DBUS_CALL_FLAGS_NO_AUTO_START to
 prohibit logind from launching.
 
 Perhaps NM is requesting logind to start through D-Bus autolaunch, but
 since the network isn't up yet logind then fails itself?
 

systemd tries to launch logind service which now waits for services it
is ordered After and eventually times out.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Cycle between logind and NetworkManager in case of remote user database

[Andrei Borzenkov]

NetworkManager sets logind inhibitor lock to monitor for suspend
events. So it implicitly requires logind to be present when NM starts.

logind is ordered after nss-user-lookup.target. If we have remote user
database, it means that logind depends on network to be up and running.

If network is provided by NetworkManager we have a loop.

Due to the fact that NetworkManager service itself does not declare
dependency on logind, it can be pretty hard to recognize.

Any idea how it can be solved nicely? I can only think of delaying
inhibitor logic in NM until logind is started. Not sure what side
effects it may have.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list