Re: Programmatically manage no-auto-default.state file?
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?
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
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
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
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
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
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
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
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
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 { > > > > > > &{ \&dbnm_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
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
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 { > &{ \&dbnm_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
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
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 { > &{ \&onPropertiesChanged }( @_ ) > } || 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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)
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
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
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
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
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
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?
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: IPv6 with DHCP -- how is default route set?
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: How to configure a DHCP + (2nd) Static address (eg on eth0+eth0:0)?
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
В Mon, 15 Dec 2014 14:20:45 -0600 Dan Williams пишет: > On Mon, 2014-12-15 at 20:40 +0300, Andrei Borzenkov wrote: > > В Mon, 15 Dec 2014 11:34:17 -0600 > > Dan Williams пишет: > > > > > > > > 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
В Mon, 15 Dec 2014 11:34:17 -0600 Dan Williams пишет: > > 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
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