Re: IP interface name of PPP connection
On Mon, 2019-07-29 at 21:27 +0200, Joachim Selke wrote:
> Hello everyone,
>
> I have set up a PPP connection and would like to retrieve the name
> of
> its IP interface (typically it is ppp0, but not always).
>
> I have been able to get the name of the IP interface in dispatcher
> scripts using the variable DEVICE_IP_IFACE. However, I did not find
> a
> way to do this using nmcli ("nmcli -g con show ").
Hi,
This shows fields of the connection-profile... There is a difference
between the profile and the actual device.
Does `nmcli -f all device show $IFACE` help?
best,
Thomas
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] vpn-manager: respect NM_VPN_PLUGIN_DIR
On Thu, 2019-07-18 at 20:39 +0200, Jelle Licht wrote: > Thomas Haller writes: > > > [snip] > > if you have > > > > /gnu/store/123verylonghash-networkmanager-1.18.2/ > > /gnu/store/234verylonghash-networkmanager-1.20.0/ > > > > and > > > > /gnu/store/345verylonghash-networkmanager-openvpn-1.2.8/ > > > > then the plugin should work with both versions of NetworkManager. > > How > > would you solve that if you don't have a well known path where VPN > > plugins announce their existance (by putting their .name file > > there). > > We solve this by setting NM_VPN_PLUGIN_DIR to > `/gnu/store/345verylonghash-networkmanager-openvpn-1.2.8/' for both > service configurations. why put the VPN's .name files be in a directory named .../*networkmanager-openvpn*/ ? There can be any number of VPN plugins and other plugins shouldn't care about nm-openvpn. Shouldn't the path at least be /gnu/store/345verylonghash-NetworkMaager-1.20.0/ and the VPN plugins put their .name files there? > > Mind you, since `network-manager' is an input for each nm vpn plugin > we > have packaged, each distinct nm version leads to distinct build > artifacts for each nm vpn plugin. > > > > > > At that point, can you not patch NetworkManager source to look > > > > at > > > > the > > > > right place? Possibly we could add a configure option to make > > > > that > > > > easier. > > > > > > To summarize and directly address your point; there is indeed > > > *one* > > > location where we put all of our vpn plugins, but this location > > > is > > > only > > > known after building each of nm and the selected vpn plugins. > > > > When switching NetworkManager you have to rebuild all plugins? That > > seems unnecessary and diamentral. At most you need to run a script > > to > > put the .name files in the new location. > > > > Also, if you anyway rebuild everything, why do you need an > > environment > > variable? If you can set the environment variable, can you not set > > the > > build-option? > > > > > > I guess, if you switch between NetworkManager versions, you would > > change the environment variable. But that is not enough. The VPN > > plugins need to copy their name files to the new location. And at > > that > > point, what does the environment variable help? > > > > The plugin directory will change depending on which plugins are > included, so in order to avoid recompiling NM every time you change > the > set of plugins, you need to be able to pass the plugin directory to > the > daemon at runtime. > best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] vpn-manager: respect NM_VPN_PLUGIN_DIR
On Thu, 2019-07-18 at 13:27 +0200, Jelle Licht wrote: > Thomas Haller writes: > > > On Wed, 2019-07-17 at 11:46 +0200, Jelle Licht wrote: > > [snip] > > But the daemon runs as root, so setting NM_VPN_PLUGIN_DIR requires > > you > > to become root, to restart the daemon, and to set the environment > > variable (in the systemd service file). At that point, you could > > just > > as well copy the .name file to /usr/lib/NetworkManager/VPN. Why is > > that > > not sufficient? > > As you say, we do set NM_VPN_PLUGIN_DIR for our networkmanager > daemon. > I was trying to have networkmanager vpn plugins simply work for Guix > System, which does not follow FHS. As such, there is no `/usr/lib` to > speak of, or any of the other default locations networkmanager looks > in. > > Put another way, do you know of a way to pass vpn plugin locations to > NM > at runtime? Hi, Hm. /usr/lib/NetworkManager/VPN is relevant to all the VPN plugins in your system. So, even if you don't use /usr/lib, then all plugins still need to agree on one location where to place their .name files? Or how is this supposed to work on Guix? At that point, can you not patch NetworkManager source to look at the right place? Possibly we could add a configure option to make that easier. Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] vpn-manager: respect NM_VPN_PLUGIN_DIR
On Wed, 2019-07-17 at 11:46 +0200, Jelle Licht wrote:
> From: Tomáš Čech
Hi,
This was not done intentionally (so far).
Clients (nm-applet, nmcli) may load the client parts of the VPN plugins
(the libnm.plugin setting from the .name file).
That's useful to show the GTK configuration dialog or implement `nmcli
connection import`.
These applications run in the user's context, and it makes sense that a
user compiles a VPN plugin that he/she installs in a private patch
(setting NM_VPN_PLUGIN_DIR). It's their choice.
But the daemon runs as root, so setting NM_VPN_PLUGIN_DIR requires you
to become root, to restart the daemon, and to set the environment
variable (in the systemd service file). At that point, you could just
as well copy the .name file to /usr/lib/NetworkManager/VPN. Why is that
not sufficient?
> + file = g_file_new_for_path (conf_dir_user);
> + priv->monitor_etc = g_file_monitor_directory (file,
> G_FILE_MONITOR_NONE, NULL, NULL);
> + g_object_unref (file);
> + if (priv->monitor_etc) {
btw, you cannot overwrite the existing monitor_etc and monitor_id_etc
fields. It would require new ones...
best,
Thomas
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Allow use of TPM2-wrapped keyfiles
On Mon, 2019-07-08 at 18:46 +0200, Daniel Kobras wrote: > Hi all! > > Using either GnuTLS or one of the TPM2 engines for OpenSSL, it's > possible to use keyfiles that are encrypted with a wrapping key from > a > TPM2 device. Implementations have started to use special PEM headers > for > these files. If openconnect it can automatically invoke the necessary > magic to unwrap the key without any user interaction. A similar patch > for wpa_supplicant can be found at > http://lists.infradead.org/pipermail/hostap/2019-July/040318.html. > > Alas, these PEM files currently fail NM's header validation. The > attached patch just accepts these keys in NM, assuming further > support > is present in the backend tools. > Hi, The patch looks good to me. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Reconnecting GSM profile after a long period of no signal
On Tue, 2019-06-25 at 19:07 +, Matthew Starr wrote: > > -Original Message- > > From: Thomas Haller [mailto:thal...@redhat.com] > > Sent: Thursday, June 20, 2019 3:22 AM > > > > On Tue, 2019-06-18 at 22:58 +, Matthew Starr wrote: > > > I am running NetworkManager 1.12.0 on an embedded Linux device > > > that > > > has Ethernet, Wi-Fi, and cellular. I am seeing a connection > > > issue on > > > GSM profiles that are setup for autoconnect=true. If I am able > > > to > > > establish a connection on cellular, then lose signal (move out of > > > range) for 20-60 minutes, and then come back within range of the > > > cellular signal, NetworkManager will not attempt to reconnect to > > > these > > > networks. I can see that ModemManager (version 1.8.0) is fully > > > registered with the cellular network and that NetworkManager is > > > just > > > not requesting to connect a data session. > > > > > > I know NetworkManager has a 300 second autoconnect reset retry > > > timer. > > > I modified that timeout to be 60 seconds to make NetworkManager > > > more > > > aggressive on retry attempts. I have given NetworkManager over an > > > hour > > > and have seen no attempt to connect to the cellular network after > > > a > > > long period of no signal. A simple “nmcli con up ” > > > command > > > will instantly connect when run, but I want NetworkManager to > > > automatically connect without user intervention on the command > > > line. > > > > > > I believe I had someone explain before that this is based on the > > > logic > > > of a connection that is having issues with getting data is > > > eventually > > > assumed to be a bad connection after enough failed attempts and > > > that > > > knowledge is somehow stored somewhere so NetworkManager doesn’t > > try to > > > connect to that network again. In my case I have an embedded > > > device > > > that is attached to mobile assets so the cell and Wi-Fi signal > > > will > > > come and go, the whole time the device is never turned off. > > > > > > I have also seen this issue with Wi-Fi previously, but I am not > > > sure > > > if that is the same issue I am seeing now with cellular. > > > > > > Is there some way to force NetworkManager to always keep retrying > > > to > > > connect to networks defined in profiles that have autoconnect set > > > to > > > true until successfully connected, no matter how many times it > > > fails > > > to connect? > > > > Hi, > > > > when NetworkManager thinks that the connection failure happend due > > to a > > bad pin, then it might block autoconnect indefinitely. That is to > > prevent > > blocking the pin. > > > > Another reason why autoconnect be blocked is if NetworkManager > > thinks > > that the secret > > (Pin) was wrong, but there is no secret-agent around to provide a > > secret. > > > > But probably something is not right here. What does the level=TRACE > > log say > > about this? See [1] for infos about logging, in particular about > > rate-limiting. > > > > [1] > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/cont > > rib/fedora/rpm/NetworkManager.conf#n28 > > > > > > best, > > Thomas > > Thomas, > > I have had the condition where NM does not attempt to reestablish a > data connection a few times, but now that I am trying to reproduce > it, to get better logs, it isn't happening. I will keep trying. > > Where in the NM code is the logic blocking autoconnect indefinitely > when an autoconnect profile is repeatedly not able to connect? Hi, on master, $ git grep nm_settings_connection_autoconnect_ > In my use case of an embedded device, I always want to retry even if > it wasn't working previously. I am considering making my own > modifications to disable blocking autoconnect indefinitely. Maybe > this could lead to a configuration option to enable/disable this > logic. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Reconnecting GSM profile after a long period of no signal
On Tue, 2019-06-18 at 22:58 +, Matthew Starr wrote: > I am running NetworkManager 1.12.0 on an embedded Linux device that > has Ethernet, Wi-Fi, and cellular. I am seeing a connection issue on > GSM profiles that are setup for autoconnect=true. If I am able to > establish a connection on cellular, then lose signal (move out of > range) for 20-60 minutes, and then come back within range of the > cellular signal, NetworkManager will not attempt to reconnect to > these networks. I can see that ModemManager (version 1.8.0) is fully > registered with the cellular network and that NetworkManager is just > not requesting to connect a data session. > > I know NetworkManager has a 300 second autoconnect reset retry > timer. I modified that timeout to be 60 seconds to make > NetworkManager more aggressive on retry attempts. I have given > NetworkManager over an hour and have seen no attempt to connect to > the cellular network after a long period of no signal. A simple > “nmcli con up ” command will instantly connect when run, but > I want NetworkManager to automatically connect without user > intervention on the command line. > > I believe I had someone explain before that this is based on the > logic of a connection that is having issues with getting data is > eventually assumed to be a bad connection after enough failed > attempts and that knowledge is somehow stored somewhere so > NetworkManager doesn’t try to connect to that network again. In my > case I have an embedded device that is attached to mobile assets so > the cell and Wi-Fi signal will come and go, the whole time the device > is never turned off. > > I have also seen this issue with Wi-Fi previously, but I am not sure > if that is the same issue I am seeing now with cellular. > > Is there some way to force NetworkManager to always keep retrying to > connect to networks defined in profiles that have autoconnect set to > true until successfully connected, no matter how many times it fails > to connect? Hi, when NetworkManager thinks that the connection failure happend due to a bad pin, then it might block autoconnect indefinitely. That is to prevent blocking the pin. Another reason why autoconnect be blocked is if NetworkManager thinks that the secret (Pin) was wrong, but there is no secret-agent around to provide a secret. But probably something is not right here. What does the level=TRACE log say about this? See [1] for infos about logging, in particular about rate-limiting. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connection policies control
Hi,
On Sat, 2019-06-15 at 14:36 +0200, Daniel Vázquez via networkmanager-
list wrote:
> I'll want to setup a connect security policy like whitelist rules or
> similar, some like:
> - Users can connect only to any AP with security WPA2
As said, you cannot run you own script that hooks into the policy
decision. Yes, you can install your own policy-kit rules, but those
make decisions based on the system user and the predefined PolicyKit
action that is required for the task at hand.
Currently the only mechanism to influence the permissions of a profile
is setting "connection.profile" property. However, while you cannot
make decisions based on whether the profile is WPA2, you can set
"connection.profile" for all WPA2 profiles accordingly.
On Mon, 2019-06-17 at 12:47 +0200, Daniel Vázquez wrote:
> I have previously used
> org.freedesktop.NetworkManager.settings.modify.system to allow or
> deny authorization of wifi connections. This works in scenario where
> the policy is focused to allow/deny know connections or fully
> allow/deny actions or use NM by some users. As you said this is not
> enough flexible to describe more granulated policies. By other way
> custom scripting request to the current existing NM PolicyKit
> org.freedesktop.NetworkManager.* actions will don't provide any
> advantage for this granularity. Moreover, If asking for a new AP
> security schema requires launch a connection, at some early point NM
> should provide some hook or new request to this custom policykit
> action.
It's not clear what you would really gain from this granularity. To
better understand the use-case, it would be interesting why exactly you
want this (not merely what you want).
> I think that described policy is very usual and widely required and I
> thought there would be something more widely established already. How
> is it being solved, what tools are currently used to apply these
> policies in corporate environments?
I don't think it's that widely required.
I'd assume most machines are either servers (where you just grant all
permissions to the wheel/admin group) or a notebook/workstation (where
de-facto there is only one desktop user).
If you require a more complex setup, then it would be interesing to
understand how that exactly looks.
You can grant users permissions like
- org.freedesktop.NetworkManager.network-control
- org.freedesktop.NetworkManager.enable-disable-network
to enable/disable certain profiles, and you can grant permissions
- org.freedesktop.NetworkManager.settings.modify.system
- org.freedesktop.NetworkManager.settings.modify.own
to create and modify profiles.
If you allow a user to create/modify a profile, then this user already
has a lot of power (to connect to any network you wish). Since policy
decisions are not made based on the content of the profile.
If you alllow a user to activate/deactivate existing profiles, you give
the user less power, but possibly he/she can still do something useful.
In term of PolicyKit, what a user can do translates to PolicyKit
actions (like "org.freedesktop.NetworkManager.network-control").
PolicyKit is very flexible about granting/disallowing an action to a
certin system user (e.g. all users in the "wheel" group).
The "connection.permissions" property of the profile determines whether
the user requires one or the other action. E.g. whether the user
requires org.freedesktop.NetworkManager.settings.modify.system or
org.freedesktop.NetworkManager.settings.modify.own to modify the
profile.
"connections.permission" currently only supports the "user:$USERNAME"
setting. There is room for some more complex permissions, maybe
something like
connection.permissions=group:wheel
but it's not very clear to me how a scheme should look like or how it
would be useful.
best,
Thomas
>
> Thank you,
>
> El dom., 16 jun. 2019 a las 8:28, Thomas Haller (
> ) escribió:
> > On Sat, 2019-06-15 at 14:36 +0200, Daniel Vázquez via
> > networkmanager-
> > list wrote:
> > > Hi guys!!
> > >
> > > I'll want to setup a connect security policy like whitelist rules
> > or
> > > similar, some like:
> > > - Users can connect only to any AP with security WPA2
> > > - User can connect only to any AP in this list [{ssid:wnet01,
> > > mac:E8:AD:A6:BC:EF:F2}, {ssid:wnet02, mac:B0:BE:76:73:20:8E},
> > ...]
> > >
> > > First, I looking for any configuration option available on nm,
> > but I
> > > don't found any. Then, I write little script to test it running
> > on
> > > /etc/NetworkManager/dispatcher.d/pre-up.d/ that runs when AP
> > > connection is stablished. But, I can see that the script is
> > executed
> > > after connection is fully stablished and a valid ip obtained.
> > It's
> > > not desired, I want to test if AP are OK with our policies before
> > > stablish fully connection, at least before a fully stablished
> > > connection with IP obtained and other pre-shared data. We want to
> > > test the policies are ok running script on preparing connection
Re: Connection policies control
On Sat, 2019-06-15 at 14:36 +0200, Daniel Vázquez via networkmanager-
list wrote:
> Hi guys!!
>
> I'll want to setup a connect security policy like whitelist rules or
> similar, some like:
> - Users can connect only to any AP with security WPA2
> - User can connect only to any AP in this list [{ssid:wnet01,
> mac:E8:AD:A6:BC:EF:F2}, {ssid:wnet02, mac:B0:BE:76:73:20:8E}, ...]
>
> First, I looking for any configuration option available on nm, but I
> don't found any. Then, I write little script to test it running on
> /etc/NetworkManager/dispatcher.d/pre-up.d/ that runs when AP
> connection is stablished. But, I can see that the script is executed
> after connection is fully stablished and a valid ip obtained. It's
> not desired, I want to test if AP are OK with our policies before
> stablish fully connection, at least before a fully stablished
> connection with IP obtained and other pre-shared data. We want to
> test the policies are ok running script on preparing connection state
> or pre-authentication state or similar earlier stage.
>
> I monitorized nm connection process, and I can see nm manages next
> stages:
>
> wlo1: connecting (prepare)
> wlo1: using connection 'wnet02'
> wlo1: NetworkManager: is now in the 'connecting' state
> wlo1: connecting (need authentication)
> wlo1: connecting (prepare)
> wlo1: connecting (configuring)
> wlo1: connecting (getting IP configuration)
> wlo1: connecting (checking IP connectivity)
> wlo1: connecting (starting secondary connections)
> wlo1: conected
> ...
> ...
>
> How can we run script on first four stages?
> Exist any other way, aproach or recommendation to apply this security
> policies?
>
> Thank you guys!!a
Hi,
NetworkManager uses PolicyKit, see the available policy-kit actions:
$ nmcli general permissions
and their comment at
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/data/org.freedesktop.NetworkManager.policy.in.in?id=7d3a957c98edbc2874e8826e29c90e2fc39c4d70
Also, a profile can be either restricted to a user, by setting
nmcli connection modify x_dummy connection.permissions "$USERNAME"
or it is not.
Depending on whether a profile is restricted, the user requires different
permissions to be able to perform certain actions. For example,
org.freedesktop.NetworkManager.settings.modify.system
vs
org.freedesktop.NetworkManager.settings.modify.own
Another relevant permission to your question is
org.freedesktop.NetworkManager.network-control
Note that the root user (user-id 0) always gets a pass, regardless of what you
configure
in PolicyKit.
In PolicyKit you can write your own scripts to answer requests in any way you
want,
but only the existing permissions (PolicyKit actions) that NetworkManager knows
are
available there.
I am not sure the system is flexible enough to do exactly what you want. Maybe.
best,
Thomas
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] core/pppd-plugin: wait to recover port settings before notifying death
On Thu, 2019-06-13 at 18:23 +0200, Alfonso Sánchez-Beato via networkmanager-list wrote: > pppd restores the previous settings for the serial port it uses right > before exiting. It is especially important to do so because otherwise > ModemManager is not able to recover the port as it can receive a > hangup > event from the port due to CLOCAL not being restored. However, there > is > currently a race condition that produces this issue. This is because > when PHASE_DEAD is notified, pppd still has not restored the port > settings - it does that a bit later, in the die() function. > > This patch delays notifying PHASE_DEAD until when the exitnotify() > hook > is called by pppd: when this happens the port settings have already > been > restored. > > There were previously efforts to fix this in commit fe090c3, so > PHASE_DEAD was used instead of PHASE_DISCONNECT to notify MM that the > port was disconnected, but that still early to ensure that the port > settings are restored. > > The MM traces seen when the bug is triggered are: > > ModemManager[2158]: (ttyACM1): could not re-acquire serial > port lock: (5) Input/output error > ModemManager[2158]: Couldn't load Operator Code: 'Cannot run > sequence: 'Could not open serial device ttyACM1: it has been forced > close' > --- > src/ppp/nm-pppd-plugin.c | 21 ++--- > 1 file changed, 18 insertions(+), 3 deletions(-) > Hi, merged to master as https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=a251712a729f676c9c2d38e469e4f88e250229ba thanks for the patch!! Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Looking for advice how to start contributing in NetworkManager and implement Hotstpot 2.0 feature for WiFi
On Thu, 2019-06-13 at 14:17 +0600, work vlpl via networkmanager-list wrote: > Hello, > > I want to contribute to NetworkManger but don't know where to start, > so I am looking for advise how I can start it. Hi, thanks for reaching out. We would very welcome your help! > wpa_supplicant supports great feature Hotspot 2.0 and contains in its > distribution program - osu_client, that allow to do automatic wifi > configuration provision using protocols and conventions defined in > Hotspot 2.0 Specification. I want to implement support of this > feature > in NetworkManager. > > wpa_supplicant - query AP for information needed for for Hotspot 2.0, > and act as executor for commands that come from osu_client. > osu_client - communicate with Online Signup server (parsing response, > generate payload), enrolling user certificates for EAP-TLS, > downloading root certificates that will validate certificated > provided > by radius servers, saving wifi configuration in xml file and load it > in wpa_supplicant. > > I have superficially studied how NetworkManager mange wpa_supplicant. > If I am not wrong it does it using D-Bus. Correct > But main features that > provide Hotspot 2.0 experience located in osu_client program. It is > the standalone program that communicate with wpa_supplicant using > control interface /run/wpa_supplicant. I think that it is a viable > way > to implement in NetworkManager functionality from osu_client that > execute wpa_supplicant command, for example `interworking select`. > But > I doubt that it is a good idea to implement certificate enrolment in > NetworkManager. It sound to me like NetworkManager really would prefer to talk to some D-Bus API here. Possibly the functionality of osu_client could go into wpa-supplicant (and exposed on D-Bus), or osu_client could itself be a D-Bus service. Re-implmenting osu_client in NetworkManager does not sound preferable... (but maybe it is?? It seems large, but not extremely large). But talking to a command line tool is also not preferable... > So my questions are: > > What features should be implemented in NetworkManager code? Any features that you deem useful and are willing to contribute :) > If some functionality is better to keep in separate program, for > example osu_client, how organise communication between NetworkManager > and that program? osu_client does not support D-Bus. Theretically anything you can think of. Including spawning processes or any protocol via sockets (varlink?). But having a separate service and a D-Bus API sounds preferable to me. I think it would make it easier for everybody to talk to this API, so the effort spend there would not only benefit NetworkManager. wpa-supplicant itself is a D-Bus activatable service and not spawned by NetworkManager. That is very nice, because the service is properly managed (e.g. by systemd) and not by NetworkManager (which would do a less great job at that). > Both NetworkManager and osu_client can configure wifi connection, so > if osu_client will be kept, how to pass wifi configuration? From it, > or from NetworkManager? > I which NetworkManager source files I should put new code? That depends... probably most of it under "src/device/wifi" and some under "src/supplicant". You can also find us on IRC (freenode, #nm). See https://wiki.gnome.org/Projects/NetworkManager/Hacking (and if you have questions that are not answered there, maybe we could improve the wiki). best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fwd: Added configuration for TELEKOM.RO (Romanian provider)
On Mon, 2019-06-10 at 16:11 +0300, fo'rika endre wrote: > -- Forwarded message - > From: fo'rika endre > Date: Mon, Jun 10, 2019 at 4:10 PM > Subject: Added configuration for TELEKOM.RO (Romanian provider) > To: < > incoming+gnome-mobile-broadband-provider-info_-merge-requ...@gitlab.gnome.org > > > > > This patch adds TELEKOM.RO (old Cosmote RO) a romanian network > provider to the list available in the mobile network configuration > wizard. > > Thanks for the instruction for Dan Williams @RedHat Hi, thank you for the patch! But this patch does not apply. Could you resend it? Preferably, create a commit in git (including a suitable commit message and yourself as patch author, with the name and email that you prefer). Then generate the patch with `git format-patch -n1 HEAD`. That file can be applies with `git-am`, preserving your commit message and authorship. Alternatively, you could also open a merge request at https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info/merge_requests best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager licensing and all new contributions must be under LGPL-2.0+
Hi all, TL;DR: if you contribute to NetworkManager ([1]), then these contributions must be made under terms of LGPL-2.0+ license. The source code of NetworkManager [1] both contains the daemon and the client library (libnm). Traditionally, the daemon is GPL-2.0+ licensed, while the library is LGPL-2.0+ licensed. Mixing these two licenses within the same project is cumbersome, because we cannot freely copy code from source to the library. Long term, we might re-license the GPL-2.0+ code as LGPL-2.0+. That is of coure cumbersome, will take time and needs discussion. If you have opinions about that, please share them. Until that, all new/original contributions to NetworkManager shall be made under terms of LGPL-2.0+, even if the contributions extend existing GPL-2.0+ code. The reason for that is to make it easier to do the relicensing in the future so that we don't need to consider contributions made since today. Basically, from today on, if you contribute to GPL-2.0+ code of NetworkManager, you agree that we might change that to LGPL-2.0+ in the future. I also updated the CONTRIBUTING file to reflect that [2]. If you encounter documentation that contradicts what I just said, please point it out so that it can be fixed. [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager [2] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/a3e75f329446a93a61ca4c458a7657bd919f4fe6/CONTRIBUTING#L37 best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: spamming router with router solicitations
On Sat, 2019-06-01 at 07:00 -0400, Brian J. Murrell wrote: > On Thu, 2019-05-30 at 12:23 +0200, Thomas Haller via networkmanager- > list wrote: > > On Wed, 2019-05-29 at 12:23 -0400, Brian J. Murrell wrote: > > > On Wed, 2019-05-29 at 09:28 +0200, Thomas Haller via > > > networkmanager- > > > list wrote: > > > > If this is happening, when you kill NetworkManager with > > > > SIGKILL, > > > > it > > > > would not give NetworkManager to cleanup... > > > > > > > > sudo killall -SIGKILL NetworkManager > > > > > > > > (and veryify that NetworkManager is indeed not running. Maybe > > > > first > > > > `systemctl mask NetworkManager`, so that systemd won't restart > > > > it). > > > > > > Are you suggesting that I kill NM with SIGKILL as a debugging > > > step > > > to > > > see if the RSes still stop when stopping NM? > > > > Yes. > > > > > If so, that was an interesting experiment: > > > > > > # killall -SIGKILL NetworkManager > > > # ps -ef | grep Network > > > root 15001 1 0 12:02 ?00:00:00 > > > /usr/sbin/NetworkManager --no-daemon > > > > > > So clearly systemd restarted it, but it's not flooding RSes after > > > the > > > restart. > > > > Ah ok. That's what I meant with first masking NetworkManager. > > # systemctl mask NetworkManager > Created symlink from /etc/systemd/system/NetworkManager.service to > /dev/null. > # killall -SIGKILL NetworkManager > # systemctl status NetworkManager > ● NetworkManager.service >Loaded: masked (/dev/null; bad) >Active: failed (Result: signal) since Sat 2019-06-01 06:53:23 EDT; > 39s ago > Main PID: 4286 (code=killed, signal=KILL) > > May 31 22:04:18 server.example.com NetworkManager[4286]: > [1559354658.5223] manager: NetworkManager state is now > CONNECTED_SITE > May 31 22:04:18 server.example.com NetworkManager[4286]: > [1559354658.5274] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > May 31 22:04:18 server.example.com NetworkManager[4286]: > [1559354658.5670] device (enp2s0): Activation: successful, > device activated. > May 31 22:04:18 server.example.com NetworkManager[4286]: > [1559354658.5807] manager: NetworkManager state is now > CONNECTED_GLOBAL > May 31 22:04:18 server.example.com NetworkManager[4286]: > [1559354658.5934] manager: startup complete > May 31 22:04:33 server.example.com NetworkManager[4286]: > [1559354673.1941] policy: set 'enp2s0' (enp2s0) as default > for IPv4 routing and DNS > Jun 01 06:53:09 server.example.com systemd[1]: Current command > vanished from the unit file, execution of the command list won't be > resumed. > Jun 01 06:53:23 server.example.com systemd[1]: > NetworkManager.service: main process exited, code=killed, > status=9/KILL > Jun 01 06:53:23 server.example.com systemd[1]: Unit > NetworkManager.service entered failed state. > Jun 01 06:53:23 server.example.com systemd[1]: NetworkManager.service > failed. > > Before killing NM, it was flooding out RSes and after killing it it > stopped. Thanks, that's of course a string indication that NetworkManager is the culprit. But I don't see how. NetworkManager uses libndp for NDP. There is only one place where it sends RS, and thereby it also should log a debug message: [1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/8964dbe8bc9cbe7300a48bffe86faee6b149fbf2/src/ndisc/nm-ndisc.c#L555 I did not see these messages... Just to check, did you enable level=TRACE logging and made sure that a possible burst of logging messages is not rate limited by systemd-journald? See the comments at [2] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 about that. Then, in the logfile I presume you do not see the messages about "router solicitation". So, it's unclear how these messages get sent. Maybe the issue is in libndp, but that should also just send one message [3] https://github.com/jpirko/libndp/blob/98bdaa1cb94faff0ccf992abc40a352ea16640fa/libndp/libndp.c#L195 ... unless kernel wrongly fails with errno EINTR, which seems unlikely. It would be interesting to see if this goes away by setting "errno = 0;" right before sendto() in [3]. No ideas so far. How is the CPU usage of NetworkManager when this happens? best, Thomas > > > If you kill NetworkManager with SIGKILL (without letting > > NetworkManager > > restart), it would not give NetworkManager time to do anything. > > If that stops the flodding, then the messages were sent by
Re: spamming router with router solicitations
On Wed, 2019-05-29 at 12:23 -0400, Brian J. Murrell wrote: > On Wed, 2019-05-29 at 09:28 +0200, Thomas Haller via networkmanager- > list wrote: > > If this is happening, when you kill NetworkManager with SIGKILL, it > > would not give NetworkManager to cleanup... > > > > sudo killall -SIGKILL NetworkManager > > > > (and veryify that NetworkManager is indeed not running. Maybe first > > `systemctl mask NetworkManager`, so that systemd won't restart it). > > Are you suggesting that I kill NM with SIGKILL as a debugging step to > see if the RSes still stop when stopping NM? Yes. > If so, that was an interesting experiment: > > # killall -SIGKILL NetworkManager > # ps -ef | grep Network > root 15001 1 0 12:02 ?00:00:00 > /usr/sbin/NetworkManager --no-daemon > > So clearly systemd restarted it, but it's not flooding RSes after the > restart. Ah ok. That's what I meant with first masking NetworkManager. > I even waited 17 minutes and still no flooding. I want to > leave it like this in case there is anything you want me to > investigate > with it. After restart, NetworkManager will reset all kinds of sysctls and reconfigure the link. So, it's not clear why the flodding stopped. It would be interesting whether those RS were sent by NetworkManager itself (or somebody else, like kernel). If you kill NetworkManager with SIGKILL (without letting NetworkManager restart), it would not give NetworkManager time to do anything. If that stops the flodding, then the messages were sent by NetworkManager -- otherwise not. > Otherwise I will continue on with the second part of the experiment > where I mask the service in systemd and kill it with a KILL and see > what happens. > > > grep -R ^ /proc/sys/net/ipv6/conf/ Thanks. It would be most interesting to see them at the moment when the flodding happen.s > > Currently that's: > > /proc/sys/net/ipv6/conf/all/accept_dad:0 > /proc/sys/net/ipv6/conf/all/accept_ra:1 > /proc/sys/net/ipv6/conf/all/accept_ra_defrtr:1 > /proc/sys/net/ipv6/conf/all/accept_ra_pinfo:1 > /proc/sys/net/ipv6/conf/all/accept_ra_rt_info_max_plen:0 > /proc/sys/net/ipv6/conf/all/accept_ra_rtr_pref:1 > /proc/sys/net/ipv6/conf/all/accept_redirects:1 > /proc/sys/net/ipv6/conf/all/accept_source_route:0 > /proc/sys/net/ipv6/conf/all/autoconf:1 > /proc/sys/net/ipv6/conf/all/dad_transmits:1 > /proc/sys/net/ipv6/conf/all/disable_ipv6:0 > /proc/sys/net/ipv6/conf/all/enhanced_dad:1 > /proc/sys/net/ipv6/conf/all/force_mld_version:0 > /proc/sys/net/ipv6/conf/all/force_tllao:0 > /proc/sys/net/ipv6/conf/all/forwarding:0 > /proc/sys/net/ipv6/conf/all/hop_limit:64 > /proc/sys/net/ipv6/conf/all/keep_addr_on_down:0 > /proc/sys/net/ipv6/conf/all/max_addresses:16 > /proc/sys/net/ipv6/conf/all/max_desync_factor:600 > /proc/sys/net/ipv6/conf/all/mc_forwarding:0 > /proc/sys/net/ipv6/conf/all/mldv1_unsolicited_report_interval:1 > /proc/sys/net/ipv6/conf/all/mldv2_unsolicited_report_interval:1000 > /proc/sys/net/ipv6/conf/all/mtu:1280 > /proc/sys/net/ipv6/conf/all/ndisc_notify:0 > /proc/sys/net/ipv6/conf/all/optimistic_dad:0 > /proc/sys/net/ipv6/conf/all/proxy_ndp:0 > /proc/sys/net/ipv6/conf/all/regen_max_retry:3 > /proc/sys/net/ipv6/conf/all/router_probe_interval:60 > /proc/sys/net/ipv6/conf/all/router_solicitation_delay:1 > /proc/sys/net/ipv6/conf/all/router_solicitation_interval:4 > /proc/sys/net/ipv6/conf/all/router_solicitations:3 > grep: /proc/sys/net/ipv6/conf/all/stable_secret: Input/output error > /proc/sys/net/ipv6/conf/all/temp_prefered_lft:86400 > /proc/sys/net/ipv6/conf/all/temp_valid_lft:604800 > /proc/sys/net/ipv6/conf/all/use_optimistic:0 > /proc/sys/net/ipv6/conf/all/use_tempaddr:0 > /proc/sys/net/ipv6/conf/default/accept_dad:1 > /proc/sys/net/ipv6/conf/default/accept_ra:1 > /proc/sys/net/ipv6/conf/default/accept_ra_defrtr:1 > /proc/sys/net/ipv6/conf/default/accept_ra_pinfo:1 > /proc/sys/net/ipv6/conf/default/accept_ra_rt_info_max_plen:0 > /proc/sys/net/ipv6/conf/default/accept_ra_rtr_pref:1 > /proc/sys/net/ipv6/conf/default/accept_redirects:1 > /proc/sys/net/ipv6/conf/default/accept_source_route:0 > /proc/sys/net/ipv6/conf/default/autoconf:1 > /proc/sys/net/ipv6/conf/default/dad_transmits:1 > /proc/sys/net/ipv6/conf/default/disable_ipv6:0 > /proc/sys/net/ipv6/conf/default/enhanced_dad:1 > /proc/sys/net/ipv6/conf/default/force_mld_version:0 > /proc/sys/net/ipv6/conf/default/force_tllao:0 > /proc/sys/net/ipv6/conf/default/forwarding:0 > /proc/sys/net/ipv6/conf/default/hop_limit:64 > /proc/sys/net/ipv6/conf/default/keep_addr_on_down:0 > /proc/sys/net/ipv6/conf/default/max_addresses:16 > /proc/sys/net/ipv6/conf/default/max_desync_factor:600 > /proc/sys/net/ipv6/conf/default/mc_
Re: spamming router with router solicitations
On Mon, 2019-05-27 at 06:59 -0400, Brian J. Murrell wrote: > On Mon, 2019-05-27 at 10:16 +0200, Beniamino Galvani via > networkmanager-list wrote: > > Are you sure you don't have other daemons like systemd-networkd > > # repoquery -q systemd-networkd > systemd-networkd-0:219-62.el7_6.6.x86_64 > > # rpm -q systemd-networkd > package systemd-networkd is not installed > > > So, not even installed. > > > or > > something else active which are racing with NM? > > Fairly sure there is nothing else. If this is happening, when you kill NetworkManager with SIGKILL, it would not give NetworkManager to cleanup... sudo killall -SIGKILL NetworkManager (and veryify that NetworkManager is indeed not running. Maybe first `systemctl mask NetworkManager`, so that systemd won't restart it). If then the RS flood stops, we know it was sent by NetworkManager. Otherwise, it wasn't. For now, I would guess that kernel is sending these solicitations... if that's the case, the sysctl settings would be interesting: grep -R ^ /proc/sys/net/ipv6/conf/ best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] nm-hostname-manager.c: Use fqdn for persistent hostname on Slackware
On Sat, 2019-05-18 at 21:08 -0500, Robby Workman wrote: > The attached patch can be applied to master and 1.12 branches. > It's specific to the hostname handling on Slackware, so it > shouldn't affect anyone else. > Hi, Merged to upstream. Since the patch only affects Slackware, I assume you know what you want and handle compatiblity (preserve previous behavior) on upgrade as you see fit :) master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e1df17e0acd14418608c2057ea4f49c31208053e nm-1-18: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=065e810424372b5969bbf910cf39fb6fd5d0ce9e nm-1-16: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=6160888e61d525552c8bdd0b64bfe137570daa83 nm-1-14: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=fb8d30a3dd000edb8272e7a512181cb3998bee50 nm-1-12: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=17709225eca69ae06860c3543fff6a93c0d2daf6 [FYI] You only asked for "master" and "nm-1-12", but all patches on old-stable-branch "nm-1-$x" must also be present on "nm-1-$((x+2))"). In other words, an older branch must be a strict subset of the patches of the next-newer branch. That's why there is this chain of cherry- picks. Thanks!! best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add support of disabling IPv6.
On Sat, 2019-05-18 at 20:32 +0800, Gris Ge via networkmanager-list wrote: > **My first patch to NM, need some help for test cases** > > Use NM_SETTING_IP6_CONFIG_METHOD_DISABLED/"disabled" for disabling > IPv6 per profile. > > Signed-off-by: Gris Ge Hi Gris, great that you gave it a shot!! But unfortunately, Beniamino already was working on this (we understood that you would not find the time to implement this). It's here: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/129 Maybe you could review hi merge-request and compare it with what you did? Future contributions are very welcome :) best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.18.0 released
Hi, I am happy to announce the newest major release of NetworkManager. While NetworkManager 1.16.0 took 6 months after the previous release, 1.18.0 comes with just one month of development time. The reason for this shorter time is that we want to get some of the new features into RHEL 7.7, and they would be too large to backport to 1.16.*. For the notable changes see the NEWS file https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/cb739531832730e0585a740cd389c715d072cd72/NEWS and find the tarball at our usual location: https://download.gnome.org/sources/NetworkManager/ Please ignore "1.18.1" in the downloads, I made a mistake pushing that tarball. The right file is "NetworkManager-1.18.0.tar.xz". Note that 1.18.0 is very likely the last major release to include the deprecated libraries libnm-glib/libnm-util. These libraries are deprecated for more than 5 years and got replaced by libnm. 1.20.0 will come without them. Thanks to everybody who contributed to this release with patches and translations: A S Alam, Antonio Larrosa, Beniamino Galvani, Benjamin Berg, Francesco Giudici, Frédéric Danis, Jason A. Donenfeld, Kristjan SCHMIDT, Lubomir Rintel, Marco Trevisan (Treviño), Milo Casagrande, Piotr Drąg, Rafael Fontenelle, Rodrigo Lledó, Thomas Haller, Till Maas, Yupeng Chang. Thanks to Vladimír Beneš, Filip Pokryvka, and Vitezslav Humpa for testing NetworkManager. enjoy Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to deal with a new Wifi Adapter?
On Thu, 2019-04-11 at 10:16 -0400, Derek Atkins wrote: > Thanks, Thomas, > > Thomas Haller via networkmanager-list > writes: > > [snip] > > Any chance you could give a quick explanation of what these (two?) > sets > of commands are doing? Hi, UUIDS is a variable containing all the "connection.uuid"s for your Wi- Fi profiles. Then, the first "for" iterates over them, and for each connection profile it prints 5 fields (so you see what is configured in these profiles). The second, itereates over the same profiles, but clears the connection.interface-name and wifi.mac-address properties. These two properties (among others) tie a connection profile to a certain device, by clearing them, the profile is applicable for any device, regardless of the interface name and MAC address. See `man nm-settings` for the properties. And see `man nmcli` or just `nmcli help` for info about nmcli. Does this help? best, Thomas > > Thanks, > > -derek > > > Hi, > > > > I'd do: > > > > UUIDS="$(nmcli -g TYPE,UUID connection show | \ > > sed -n 's/802-11-wireless://p')" > > > > for UUID in $UUIDS; \ > > do \ > > nmcli \ > >-f connection.id,connection.uuid,802-11- > > wireless.ssid,connection.interface-name,802-11-wireless.mac-address > > \ > >-mode multiline \ > >connection show uuid "$UUID" ; \ > > echo ; \ > > done > > > > if you want to clear these values: > > > > for UUID in $UUIDS; \ > > do \ > > echo "$UUID ..." ; \ > > nmcli connection modify uuid "$UUID" \ > > connection.interface-name '' \ > > wifi.mac-address '' ; \ > > done > > > > > > > In a similar vein, is there a way to tell NM to disable to > > > embedded > > > wifi > > > adapter? > > > > put > > > > [device-unmanage-internal-wifi] > > match-device=mac:aa:bb:cc:dd:ee:ff > > managed=0 > > > > to /etc/NetworkManager/conf.d/99-unmanaged-internal-wifi.conf and > > restart. > > > > Or even blacklist the module from loading in /etc/modprobe.d. > > > > > > best, > > Thomas > > > > ___ > > networkmanager-list mailing list > > networkmanager-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/networkmanager-list > > signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to deal with a new Wifi Adapter?
On Wed, 2019-04-10 at 12:24 -0400, Derek Atkins wrote: > Hi, > I'm currently running Fedora 29 and my embedded wifi adapter is > failing. So I bought a USB Wifi adapter, which seems to be working > well.. Except for one problem: Network Manager does not know to > apply > all my existing wifi connection information to the new adapter. > > Short of going through each connection, changing it to the new > adapter, > then deleting the " 2" network that gets created --- is there > some > way to tell NM to apply all wifi networks to all wifi adapters? > Hi, I'd do: UUIDS="$(nmcli -g TYPE,UUID connection show | \ sed -n 's/802-11-wireless://p')" for UUID in $UUIDS; \ do \ nmcli \ -f connection.id,connection.uuid,802-11-wireless.ssid,connection.interface-name,802-11-wireless.mac-address \ -mode multiline \ connection show uuid "$UUID" ; \ echo ; \ done if you want to clear these values: for UUID in $UUIDS; \ do \ echo "$UUID ..." ; \ nmcli connection modify uuid "$UUID" \ connection.interface-name '' \ wifi.mac-address '' ; \ done > In a similar vein, is there a way to tell NM to disable to embedded > wifi > adapter? put [device-unmanage-internal-wifi] match-device=mac:aa:bb:cc:dd:ee:ff managed=0 to /etc/NetworkManager/conf.d/99-unmanaged-internal-wifi.conf and restart. Or even blacklist the module from loading in /etc/modprobe.d. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Adding basic OpenVPN PKCS#11 support
On Tue, 2019-03-26 at 08:41 +0100, Martin Forssen via networkmanager- list wrote: > Hello, > > I have the need to run OpenVPN with PKCS#11 hardware certificates on > Linux. This does currently not seem to be possible with > NetworkManager. > > I have looked around a bit and realize this is a can of worms. The > nice clean solution would require changes to OpenVPN, which so far > seems to be hard to get merged. > > So my plan right now is to take the simplest possible approach and > just add text fields where one can enter pkcs11-providers and pkcs11- > id (and of course support for importing these values). > > My question now is if I were to submit patches which does this, is > there any chance of them getting merged (assuming they follow coding > standard etc)? > Hi, work on this would be great. Lubomir was working on that, quite a while ago. Some work in progess is still at [1]. Note this also requires support from NetworkManager ([2]). [1] https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/commits/lr/p11-forward [2] https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=lr/p11-forward best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: openvpn: "Authenticate/Decrypt packet error: bad packet ID", link-mtu=1472 consequences
On Wed, 2019-03-27 at 18:56 +, avemilia via networkmanager-list wrote: > Sorry, I have assumed that the VPN tunnel is up with this link-mtu > setting, but > in reality it is not. Hi, Try: sudo nmcli general logging level TRACE domains ALL,VPN_PLUGIN:TRACE and reactivate the VPN connection. Then, look at the debug logs (journalctl?) Assertions are of course always a bug, and should be fixed. But that does not seem related to your issue here. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.16.0 released
Hi, today we released NetworkManager 1.16.0. See the NEWS file https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?id=1.16.0 and the overview written by Lubomir https://blogs.gnome.org/lkundrak/2019/03/15/networkmanager-1-16/ Find the tarball at our usual location: https://download.gnome.org/sources/NetworkManager/ Thanks to everybody who contributed to this release with patches: Aleksander Morgado, Andrei Dziahel, Andrew Zaborowski, AsciiWolf, Beniamino Galvani, Benjamin Berg, Corentin Noël, Damien Cassou, Dennis Brakhane, Evgeny Vereshchagin, Francesco Giudici, Frédéric Danis, Iñigo Martínez, Jan Alexander Steffens (heftig), Jason A. Donenfeld, Jonathan Kang, Kristjan SCHMIDT, Kyle Walker, Lennart Poettering, Li Song, Lubomir Rintel, Marco Trevisan (Treviño), Michael Biebl, Patrick Talbert, Piotr Drąg, Rafael Fontenelle, Sebastien Fabre, Soapux, Sven Schwermer, Taegil Bae, Thomas Haller, Yu Watanabe, Yuri Chornoivan, garywill, luz.paz, scootergrisen Thanks to Vladimír Beneš, Filip Pokryvka, and Vitezslav Humpa for testing NetworkManager. enjoy Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.15.91 (1.16-rc2) released
Hi, there is now a second release candidate for upcoming 1.16.0. While it was planned to release 1.16.0 shortly after 1.16-rc1 [1], there were some issue which warrant a delay and this second release- candidate. There are API and ABI changes compared to 1.16-rc1. Notable changes are: - adjusting/extending some libnm API related to WireGuard - implement `nmcli connection import type wireguard file "$CONF_FILE"` - various fixes for WireGuard - other bugfixes We hope 1.16-rc2 goes smoothly and the 1.16.0 release is planned by end of this week. best, Thomas NEWS: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/1.16-rc2/NEWS TARBALL: https://download.gnome.org/sources/NetworkManager/1.15/ [1] https://mail.gnome.org/archives/networkmanager-list/2019-February/msg00041.html signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] tests: Fix variant_from_dbus() for arrays of UInt32
On Wed, 2019-03-06 at 11:59 +0100, Frédéric Danis via networkmanager- list wrote: > Using test-networkmanager-servic.py, I get the following error when > trying to add manual config with a dns address: > Hi, looks good. Merged as https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=9a71d7d273e42a0d959240c6deb56cb0397eb6dd Are you using the stub service? I'm curious what exactly you are with it. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] [nmstate] Linux routing in nmstate
On Mon, 2019-03-04 at 22:11 +0800, Gris Ge wrote:
> Based on feedbacks, this is V2 scheme for review:
>
> ```
> {
> "routes": {
> "ipv4": [ # Sorted with 'table-id' then
> 'destination'
> {
> "status": "up",
> # up or absent(to be removed)
> # If not defined, use 'up'
> "table-name": "main",
> # Empty if no name attached,
> "table-id": 254,
> # If not defined, use 'main' route table id
> "protocol": "dhcp", # "static" or "dhcp"
> # If not defined, use 'static'
> "metric": 100,
> # If not defined, let NetworkManager to
> decided.
> "destination": "0.0.0.0/0",
> # Mandatory
> "next-hop-iface": "eth0",
> # Mandatory
> "next-hop-address": "192.0.2.1"
> # ^ Empty on point-to-point link
> },
> ],
> "ipv6": [# Sorted with 'table-id' then 'destination'
> {
> "status": "up",
> "table-name": "main",
> "table-id": 254,
> "protocol": "router-advertisement",
> # ^ "static" or "router-advertisement"
> "metric": 100,
> "destination": "::/0",
> "next-hop-iface": "eth0",
> "next-hop-address": "fe80::1"
> },
> ],
> }
> }
> ```
>
> Changes since V1:
>
> * Top tree is 'routes', and subtree is 'ipv4' and 'ipv6'.
>Even the IPv4 and IPv6 route entry are mostly identical, but we
> need
>schema to differentiate the 'destination' address type in a simple
>way.
Hi,
I don't think there is any fundamental difference between
{
ipv4-routes: { ... },
ipv6-routes: { ... },
}
and
{
routes: {
ipv4: { ... },
ipv6: { ... },
},
}
Instead, the more fundamntal question is whether IPv4 and IPv6 routes
should be merged together and expressed by the same "object"/"type",
and get a "addr-family" field to differenciate.
{
routes: {
[0] = {
addr-family: ipv4,
...
},
...
},
}
I think the answer is "yes". It seems better to me to treat routes the
same on a higher layer, and move the differenciation between address
families closer the places that care about the difference.
> * Add 'status: absent' to simplify the route deletion.
>
> * Add comments to show the default value if not defined.
"protocol" possibly should still be renamed to "source". Or "origin"?
best,
Thomas
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] [nmstate] Linux routing in nmstate
Hi, On Tue, 2019-02-26 at 14:56 +0800, Gris Ge via networkmanager-list > "protocol": "dhcp", # "static" or "dhcp" "protocol" sounds a bit like iproute2's "protocol" option (struct rtmsg's rtm_protocol). But I think it's not. I would call this "source". best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] [nmstate] Linux routing in nmstate
On Thu, 2019-02-28 at 22:40 +0200, Edward Haas via networkmanager-list
wrote:
> Thank you Gris.
> Comments in-line.
>
> On Tue, Feb 26, 2019 at 8:56 AM Gris Ge wrote:
> > Hi Guys,
> >
> > Could you review below schema for routing in nmstate before we
> > start
> > add routing support in nmstate?
> >
> > ```
>
> What is the root level key? `routing`?
>
> > {
> > "ipv4-routes": [# Sorted with 'table-id' then
> > 'destination'
>
>
> ipv4 and ipv6 look identical to me here.
> It makes sense then to have `route` as the subtree and a `family`
> entry inside.
> > {
> > "table-name": "main", # Empty if no name attached
> > "table-id": 254,
> > "protocol": "dhcp", # "static" or "dhcp"
> > "metric": 100,
> > "destination": "0.0.0.0/0",
> > "next-hop-iface": "eth0", # Mandatory
>
> This is not mandatory on `iproute2`, it is usually resolved based on
> the address next hop.
> I think it is mandatory for p2p links only.
I think it should be mandatory. Kernel or iproute2 may detect certain
next-hop-interfaces by looking at whether there is a direct route to
the next hop (on an interface). But that seems fragile to me, and
something you can do ad-hoc (at the moment when issuing the iproute2
command), but not so well in a description of the state (which, is
kinda timeless).
Also, it is mandatory *for a lot* of cases. It's effort to pin down
exactly when it's mandatory and when not.
Also, a mandatory paramter can later always be relaxed for bing not
mandatory. But making it mandatory later is an API break.
best,
Thomas
signature.asc
Description: This is a digitally signed message part
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 1.14.6 build error
On Tue, 2019-02-26 at 09:03 +0200, Cristian Crinteanu wrote: > .. > src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c: In function > ‘discover_mac_address’: > src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c:572:15: error: > storage size of ‘ifr’ isn’t known > struct ifreq ifr; >^~~ > src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c:590:32: error: > ‘IFNAMSIZ’ undeclared (first use in this function); did you mean > ‘NMP_IFNAMSIZ’? > strncpy(ifr.ifr_name, device, IFNAMSIZ-1); > ^~~~ > NMP_IFNAMSIZ > src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c:590:32: note: > each undeclared identifier is reported only once for each function it > appears in > src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c:572:15: warning: > unused variable ‘ifr’ [-Wunused-variable] > struct ifreq ifr; >^~~ > make[2]: *** [Makefile:15086: src/settings/plugins/ifcfg- > rh/libnms_ifcfg_rh_core_la-nms-ifcfg-rh-reader.lo] Error 1 > make[2]: Leaving directory '/home/yoda/rpmbuild/BUILD/NetworkManager- > 1.14.6' > make[2]: *** Waiting for unfinished jobs > ... > make[2]: Leaving directory '/home/yoda/rpmbuild/BUILD/NetworkManager- > 1.14.6' > make[1]: *** [Makefile:17787: all-recursive] Error 1 > make: *** [Makefile:7870: all] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.2zCe40 (%build) > Any ideea ? > Thx! Hi, It doesn't seem you are using 1.14.6. In file "src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c" the quoted line is not that way. also, `git grep 'strncpy.*IFNAMSIZ'` gives no result on 1.14.6. Neither does `git grep 'IFNAMSIZE-1'` [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/plugins/ifcfg-rh/nms-ifcfg-rh-reader.c?id=1.14.6 best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-applet edit unplugged device connections/profiles
On Fri, 2019-02-22 at 09:31 -0600, Greg Oliver via networkmanager-list wrote: > On Fri, Feb 22, 2019 at 9:08 AM Thomas Haller > wrote: > > On Fri, 2019-02-22 at 07:43 -0600, Greg Oliver via networkmanager- > > list > > wrote: > > > Hi, > > > > > > Is there some way to get nm-applet to show unplugged (ethernet > > > dongles) devices profiles in it's menu at all times? All of my > > > recent laptops have been thunderbolt usb-c only and my wired > > ethernet > > > adapters have all been one of the variants, but until I plug them > > in, > > > I cannot even see my profiles from the GUI anywhere. Is there > > some > > > way to change this behavior? > > > > > > Running Fedora (29). > > > > > > > > > Hi, > > > > > > nm-applet is a tool (GUI in the system tray bar) to show devices, > > which > > profiles are currently active, and to activate/deactivate profiles > > on > > devices. > > > > Consequently, you don't see profiles that have no suitable device > > at > > the moment. > > > > Use nm-connection-editor for that, which only focuses on > > creating/modifing/deleting profiles. > > > > > > In nm-applet, you can also right click and select "Edit > > Connections...", which spawns nm-connection-editor -- though, I > > think > > right-click does not work if nm-applet uses libappindicator. > > Regardless > > of that, you can always start nm-connection-editor manually, the > > effect > > is the same. > > > > > > Does that work? > > Perfect - exactly what I needed! > > Thanks Thomas - I have been looking through the config files and > nmcli to flip some switch without luck :) > > I sure wish that the Gnome folks would not have removed the > bonding/vlan/connection stuff from Settings, and I always seem to > forget about nm-connection-editor :-/ Hi, your last remark makes me wonder whether you are using Gnome3. Note that gnome-shell in Gnome3 itself has a NetworkManager integration. That is similar in purpose and appearance to nm-applet. But nm-applet is a separate application. Likewise, Gnome3's control-center has a built-in connection-editor. That's not the same as nm-connection-editor. While gnome-control- center's NetworkManager GUI does not support bonding/vlan, nm- connection-editor does. Just to clear that up -- it is indeed confusing. Use whatever GUI suits you. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-applet edit unplugged device connections/profiles
On Fri, 2019-02-22 at 07:43 -0600, Greg Oliver via networkmanager-list wrote: > Hi, > > Is there some way to get nm-applet to show unplugged (ethernet > dongles) devices profiles in it's menu at all times? All of my > recent laptops have been thunderbolt usb-c only and my wired ethernet > adapters have all been one of the variants, but until I plug them in, > I cannot even see my profiles from the GUI anywhere. Is there some > way to change this behavior? > > Running Fedora (29). > Hi, nm-applet is a tool (GUI in the system tray bar) to show devices, which profiles are currently active, and to activate/deactivate profiles on devices. Consequently, you don't see profiles that have no suitable device at the moment. Use nm-connection-editor for that, which only focuses on creating/modifing/deleting profiles. In nm-applet, you can also right click and select "Edit Connections...", which spawns nm-connection-editor -- though, I think right-click does not work if nm-applet uses libappindicator. Regardless of that, you can always start nm-connection-editor manually, the effect is the same. Does that work? best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and FirewallD
On Fri, 2019-02-15 at 14:38 +0200, Berend De Schouwer wrote: > On Fri, 2019-02-15 at 13:05 +0100, Thomas Haller wrote: > > On Fri, 2019-02-15 at 12:15 +0200, Berend De Schouwer via > > networkmanager-list wrote: > > > > > NetworkManager almost never directly configures iptables. The only > > place is for enabling MASQUERADING, with "ipv4.method=shared". > > nftables > > is not supported here, and optimally this could would be improved > > to > > let firewalld handle this. It's ugly that NetworkManager does this, > > but > > you are not using "ipv4.method=shared", are you? > > Yes, I am. OK, then it sounds like a NetworkManager issue. > > > > That aside, all that NetworkManager does regrading > > iptables/firewalld, > > is to call "addInterface", "changeZone", and "removeInterface" on > > the > > firewalld D-Bus API -- depending on "connection.zone" parameter in > > NetworkManager's connection profile. > > The only change seems to be the order of the rules, which indicates a > race condition. So the entire interface and/or zone do get > added/removed. > > So far, I've only seen the nat table trashed (pre/postrouting), not > input/forward/output. > > The order can be wrong in multiple places. It's not always the same > place. > > Does NM both call D-Bus "addInterface" *and* modify iptables manually > for masquerading? If so, is there a D-Bus API to find out when > FirewallD is done adding the interface? [1] are the rules that NetworkManager configures (calling iptables directly). In the logfile (with level=TRACE, see [2]) logging you will also see: - when NetworkManager calls to firewalld. Grep for "firewall:" - when NM calls iptables. Yes, what NM does here is not optimal, possibly even wrong as you see... [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices/nm-device.c#n10259 [2] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: libnm
On Fri, 2019-02-15 at 12:32 +0200, Kalev Toots wrote: > Hello > > I try to connect 3G GSM modem to network using Network Manager,libnm > API > and C/C++ code. > I cannot find any C/C++ example code which connects prepared NM > profile > to network > and waits until connection is up or error or timeout. Can anybody > direct > me to such > piece of code. > Hi, see https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/C NetworkManager is profile based, that means in one step you create the profile to your liking, then you just call nm_client_activate_connection_async(). This returns you a D-Bus path to the NMActiveConnection (which represents the activation and ties the profile (NMRemoteConnection) to the device (NMDevice). See for example, nmcli: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/clients/cli/connections.c?id=c032690df227a609fc4b47c78269448576b6bda1#n2790 The complicated part is waiting until the profile is fully activated: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/clients/cli/connections.c?id=c032690df227a609fc4b47c78269448576b6bda1#n2584 Another example is the ansible-role (Which is Python with libnm via GObject introspection): https://github.com/linux-system-roles/network/blob/master/library/network_connections.py#L1083 This is a rather unconventional example, because it manually iterates the glib mainloop. If you are unclear how to use the glib mainloop, then this might *not* be the example to look at. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and FirewallD
On Fri, 2019-02-15 at 12:15 +0200, Berend De Schouwer via networkmanager-list wrote: > Hi, > > I've got a connection setup with NetworkManager on Fedora 29, and > sometimes on reboot the firewall rules are re-ordered. > > The firewall is managed by firewalld. It creates a few zones, and > sometimes the rules in the zones are re-ordered. For example, a diff > between startups: > > Chain POSTROUTING_ZONES (1 references) > target prot opt source destination > -POST_public all > -- 0.0.0.0/00.0.0.0/0 [goto] > POST_home all -- 0.0.0.0/00.0.0.0/0 [goto] > +POST_public all > -- 0.0.0.0/00.0.0.0/0 [goto] > POST_FedoraServer all > -- 0.0.0.0/00.0.0.0/0 [goto] > > This can prevent some traffic from flowing, especially if it re- > orders > a MASQUERADING rule. > > Note, in this case it actually broke some traffic swapping public & > home in both POST and PRE. > > I can fix it by either re-starting NetworkManager, or by dropping the > connection and bringing it up again. I can also break it that way. > > I'm assuming it's triggered by a race condition. It happens on a > Raspberry Pi, which is a little slower. > > > Is there some way to prevent this? Hi, TL;DR: this does not sound like a NetworkManager issue to me. Why do you think it is. I would ask firewalld [1]. [1] https://firewalld.org/community.html NetworkManager almost never directly configures iptables. The only place is for enabling MASQUERADING, with "ipv4.method=shared". nftables is not supported here, and optimally this could would be improved to let firewalld handle this. It's ugly that NetworkManager does this, but you are not using "ipv4.method=shared", are you? That aside, all that NetworkManager does regrading iptables/firewalld, is to call "addInterface", "changeZone", and "removeInterface" on the firewalld D-Bus API -- depending on "connection.zone" parameter in NetworkManager's connection profile. Note that firewalld may also feed back into NetworkManager, when you modify a zone in Firewalld persistently, then firewalld may update "connection.zone" in NetworkManager's profile. This interaction between the two is rather hairy, because they both might call to each other. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: networkmanager and hostapd - wireless managed as wired
Hi, On Thu, 2019-02-14 at 19:06 +0100, Mithnar Menengrothello via networkmanager-list wrote: > Hi, > > I'm trying to build a gateway/AP with two SSID managed by hostapd > without completely disabling NetworkManager. Base is CentOS7 > > My current setup looks like this and works. > > +++-+-- > --+ > >| enp5s6 - public IP by > > DHCP || > >| | > > | > >| managed by > > NM|| > >| | > > | > >| | > > | > >+-^^--- > > +| > > || > > | > > +--MASQ-++MASQ- > > + | > > | | > > | > +--+---+--+ +-+---+ > --+ > > > br0 - 192.168.1.0/24 +<-+ | br1 - > > > 192.168.50.0/24 || > > > created by network | XXX | created by > > > network|| > > > managed by NM, | +->+ managed by > > > NM || > > >| | > > > || > > ---+-- --+- > > -| > > > enp7s0 | wlp6s0| > > > wlp6s0.1 || > > > joined to > > > br0| | || > > > by network | | created and managed by > > > hostapd|| > > > | | joined to br1 on > > > creation || > > > | +--- > > > -| > > > | managed by > > > hostapd|| > > > | joined to br0 by > > > hostapd || > +---+-- --- > --+ Nice ASCII art :) > > - br0 is interal network comprised of wired enp7s0 and wireless > wlp6s0 (wireless managed by WPA2 Enterpise), > - br1 is public guest wifi network with WPA2 Consumer. There is no > routing between the two. > - Both are MASQeraded to external interface (enp5s6). > - Firewall and masquerading is managed by firewalld. > > All config is kept in /etc/sysconfig/ifcfg-* files, so during bootup > networking could be assembled by old networking initscript (it is not > disabled). > > I'd like to let NetworkManager manage all interfaces, unfotunately as > for now it does not allow me to manage only III layer and up without > touching II Iayer of wifi interface (or I was not able to find > appropriate setting). Thus I had to create br1 to separate IP > configuration (managed by NM) and let hostapd manage AP > functionality > on virtual wlp6s0.1. This seem to be unnecessary, but I could not > make > it work any other way. > > My questions: > > 1. Is is it possible to make NetworkManager manage a wifi interface > just as an ordinary wired ethernet (no fooling around wireless > settings)? Wired interfaces can be with or without 802.1X so here > situation potentially can be no different. > > 2. Is it possible to let NM take over management of virtual wireless > interface (here wlp6s0.1) once it is created? > Now when the interfece is defined as NM-managed, "hotplug" to "yes" > and "type" is set to "wifi", network manager does not react to its > creation by hostapd and whet I try to bring the connection manually, > NM complains it canot find a device to manage. Should it be possible > I could get rid of br1. there is "connection.type=generic". Which basically is Layer3/IP configuration that can be applicable to any externally created netdev (i.e. device visible in `ip link`). Generic connections however don't support 802.1x (maybe it should?). It's also not entirely to me clear whether that would actually work for you. It's worth a try. In general, I think it won't work easily. But we'd be interested in getting your setup to work :) best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Reciving multiple RAs causes NetworkManager to storm the network with RSes
On Thu, 2019-02-14 at 10:29 -0500, Brian J. Murrell wrote: > On Thu, 2019-02-14 at 15:16 +0100, Thomas Haller via networkmanager- > list wrote: > > Hi, > > Hi. > > > From the logs it looks like to me the IPv6 address of the sender is > > indeed the instance managed by NetworkManager. > > Oh yes, I am sure it's the NM machine that is sending the RSes. > > > Is the issue hard to reproduce? > > Not hard to reproduce but I don't have a "lab" to reproduce it in and > so have to do it on my production network and doing so brings the > router/switch that everything is connected to to it's knees so it's > pretty catastrophic to reproduce. > > I'm also concerned with the disk load that disabling the rate > limiting > of journald is going to cause on the NM machine given that it's > suppressing thousands of messages at a time. > > But I will give it another go. > > Just so that I only have to do this once and as briefly as possible, > what level of debugging do I need to set to get the messages logged > by: > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/ndisc/nm-ndisc.c?id=2c881b8064e1cb5b227e5a3c61abfe95c6ddd05a#n711 Hi, Best way is: - first disable ratelimiting in journald. For that, set RateLimitIntervalSec=0 in /etc/systemd/journald.conf and `systemctl restart systemd-journald.service` - enable level=TRACE in /etc/NetworkManager/NetworkManager.conf (level=DEBUG would be enough for these particular loglines, but as you go throgh the effort of collecting logs, there is no need to restrict what to collect). - restart NM, reproduce, and provide logs. In particular, loglines with the word "solicitation" seem relevant. Thanks, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Reciving multiple RAs causes NetworkManager to storm the network with RSes
On Thu, 2019-02-14 at 08:25 -0500, Brian J. Murrell wrote: > On Thu, 2019-02-14 at 13:46 +0100, Thomas Haller wrote: > > Hi, > > Hi, > > > In 1.10.2-16.el7_5, that code looks pretty similar. NetworkManager > > should either log > > > > "router solicitation sent" > > > > or > > > > "failure sending router solicitation: ... > > > > for every RS that gets send. > > > > > > Possibly the logging message was suppressed by journald's > > ratelimiting > > Most likely. > > > (as the journal would tell you, if that's the case). Make sure to > > disable rate-limiting, see [1]. > > > > > > [1] > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 > > Is it really necessary to actually see the messages in the journal at > this point? Doesn't the packet trace and CPU load of NM from my > previous message sufficiently prove that NM is storming RSes? > Hi, well, NetworkManager uses libndp for IPv6 neighbor discovery. From the logs it looks like to me the IPv6 address of the sender is indeed the instance managed by NetworkManager. However, 1) libndp never sends RS without being told to do so (I think). 2) NetworkManager sends RS (via libndp) only at one place. It's not clear to me how that code could be wrong so that it might result in a flood of RS. The logfile should show whether this code is culprit or not. Is the issue hard to reproduce? Your efforts are appreciated!! :) best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Reciving multiple RAs causes NetworkManager to storm the network with RSes
Hi, On Thu, 2019-02-14 at 07:01 -0500, Brian J. Murrell wrote: > On Thu, 2019-02-14 at 07:49 +0100, Thomas Haller via networkmanager- > > > It's not clear to me what you mean. > > > > Do you mean, that the many RA received at NetworkManager cause > > NetworkManager to send too frequent RS (in turn, repeating a > > vicious > > cycle)? > > That's exactly how I understand the description from the author of > the > software on the router that is sending the RAs, yes: > > https://github.com/openwrt/odhcpd/issues/122#issuecomment-459263681 OK, makes sense. > > Also, NM only sends RS based on timeouts, not based on RAs that it > > receives [1]. > > Assuming no bugs, of course. Such as could the receiving of the > multiple RAs perhaps be causing the timeout to get reset, etc.? > > How/when does the logging in send_rs_timeout: > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/ndisc/nm-ndisc.c?id=2c881b8064e1cb5b227e5a3c61abfe95c6ddd05a#n711 > > supposed to get logged? In 1.10.2-16.el7_5, that code looks pretty similar. NetworkManager should either log "router solicitation sent" or "failure sending router solicitation: ... for every RS that gets send. Possibly the logging message was suppressed by journald's ratelimiting (as the journal would tell you, if that's the case). Make sure to disable rate-limiting, see [1]. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Reciving multiple RAs causes NetworkManager to storm the network with RSes
On Thu, 2019-01-31 at 06:46 -0500, Brian J. Murrell wrote: > On Thu, 2019-01-24 at 17:15 -0500, Brian J. Murrell wrote: > > On Tue, 2019-01-22 at 16:25 -0500, Brian J. Murrell wrote: > > > Seems I already had level=TRACE set. > > > > Was that debug useful? > > So, it seems this behaviour is more harmful to the network than just > spamming a log on the NM host. > > It's causing a message storm with the router that is sending the > multiple RAs in that NM is sending RS messages in response to the RAs > crushing the router with RS messages. > > Given that, can any more importance be put on this issue? > Hi Brian, It's not clear to me what you mean. Do you mean, that the many RA received at NetworkManager cause NetworkManager to send too frequent RS (in turn, repeating a vicious cycle)? I wouldn't see that from the log. There are no log lines about additional router solicitations sent by NetworkManager. Also, NM only sends RS based on timeouts, not based on RAs that it receives [1]. can you clarify what you think is the harmful behavior? Also, does tcpdump/wireshark show that NM sends too many RS? [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/ndisc/nm-ndisc.c?id=2c881b8064e1cb5b227e5a3c61abfe95c6ddd05a#n698 best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: automatic APN selection
On Tue, 2019-02-12 at 11:49 +0100, Belisko Marek via networkmanager- list wrote: > Hello, > > I posted yesterday question to ModemManger mailing list about > implementing automatic APN selection (based on mobile broadband > database) and it was pointed [0] out that this feature should be > added to NM. My case is that embedded device using GSM modem should > connect to internet automatically (without user intervention only by > plugging SIM card). Isomebody working on such solution already? It is > right approach? Thanks for replies. > > 0 - > https://lists.freedesktop.org/archives/modemmanager-devel/2019-February/006996.html Hi, sounds reasonable to me. Maybe the first step would be to move the code from libnma (network- manager-applet) to libnm (NetworkManager) to handle the mobile- provider-database. Or maybe better, make it an independent libnm- mobile-provider-database.so library to keep core libnm smaller. As it is, NetworkManager certainly cannot link against libnma. [1] https://gitlab.gnome.org/GNOME/network-manager-applet/blob/master/src/libnma/nma-mobile-providers.c best, Thomas > > , > > marek > -- > as simple and primitive as possible > - > Marek Belisko - OPEN-NANDRA > Freelance Developer > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic > Tel: +421 915 052 184 > skype: marekwhite > twitter: #opennandra > web: http://open-nandra.com > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network connection local to devices.
Hi, On Wed, 2019-01-30 at 13:51 +0100, Alexandre Garreau via networkmanager-list wrote: > In what cases here for example? You mean, cases where this behavior is preferred? Good question. Dunno. > And are there ways (like a configuration option) to make so that nm- > applet stop creating profiles tied to to a device by default? for me? No, there are no such options in nm-applet. You could create the profile via other means (nm-connection-editor, `nmcli connection add`), but that is not as convenient, as nm-applet fills in all the required fields automatically, based on the content of the Wi-Fi network. As such it's like `nmcli device wifi connect ...`. Or, just modify the profile after it was created. > And what about that unexisting -g options? is there a way to get that > list of profiles without using it? "-g $FIELDS" is a shortcut for "--mode tabular --terse --fields $FIELDS". On older versions of nmcli you can use that. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network connection local to devices.
On Tue, 2019-01-22 at 22:25 +0100, Alexandre Garreau wrote: > Thank you very much for your answer! Indeed, just erasing what’s in > “Device” (under “Ethernet” as you said, but only for wired > connections: for wifi (what’s most likely to change and require auth > info), it’s “Wifi”) works. > On 2019-01-22 at 20:27, Thomas Haller wrote: > > > Why does that work that way by default in GUI? or did I do > > > something wrong at some point maybe? > > > > > I think it makes sense to restrict a profile by default to one > > device. Ultimately, that is decided by the client tool (like nm- > > applet) that creates the profile profile in such a way. It doesn't > > sound like you did anything wrong. If the setting is not best for > > your case, modify the profile as it suits you. > > > > Then, I’d like to know if there’s a way to make that “device” section > unimportant for every wifi profile, or otherwise, how to erase it for > all of them, or otherwise, in which file is this written so I write a > script to do it. well, you could do something like: for U in $(nmcli -g TYPE,UUID connection show | sed -n 's/^802-3-ethernet://p'); do nmcli connection modify $U connection.interface-name '' ethernet.mac-address ''; done > Also why is this the default for nm-applet (are there other widely > used clients? isn’t this mailing-list the appropriate place for > asking about it? or is there some other development team and mailing- > list?)? isn’t there a way to change that? So I don’t forget all the > connection I happen to find around each time I change computer… it's the right list. it's not clear which component initialized the profile in that manner for you. Even if we identify the component, it's not clear whether this is desirable behavior by default. But sure, what exactly did you do to end up with such configuration? All connections are shown by `nmcli c`. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: multiple RAs spamming log with policy: set 'enp2s0' (enp2s0) as default for IPv6 routing and DNS
On Tue, 2019-01-22 at 08:50 -0500, Brian J. Murrell wrote: > My router is (now) sending multiple RAs instead of aggregating all > prefixes/routes into a single RA as such: > > Soliciting ff02::2 (ff02::2) on pc_bridge... > > Hop limit : 64 ( 0x40) > Stateful address conf.: No > Stateful other conf. : No > Mobile home agent : No > Router preference : medium > Neighbor discovery proxy : No > Router lifetime :0 (0x) seconds > Reachable time: unspecified (0x) > Retransmit time : unspecified (0x) > Source link-layer address: 6C:B0:CE:F5:1E:4A > MTU : 1500 bytes (valid) > Prefix : fd31:aeb1:48df::/64 > On-link : Yes > Autonomous address conf.: Yes > Valid time : infinite (0x) > Pref. time : infinite (0x) > Route: fd31:aeb1:48df::/48 > Route preference: medium > Route lifetime : infinite (0x) > Recursive DNS server : fd31:aeb1:48df::2 > DNS server lifetime : 6000 (0x1770) seconds > from fe80::6eb0:ceff:fef5:1e4a > > Hop limit : 64 ( 0x40) > Stateful address conf.: No > Mobile home agent : No > Router preference : medium > Neighbor discovery proxy : No > Router lifetime : 1800 (0x0708) seconds > Reachable time: unspecified (0x) > Retransmit time : unspecified (0x) > Source link-layer address: 6C:B0:CE:F5:1E:4A > MTU : 1500 bytes (valid) > Prefix : 2001:1234:5678:a700::/64 > On-link : Yes > Autonomous address conf.: Yes > Valid time :84531 (0x00014a33) seconds > Pref. time :41331 (0xa173) seconds > Route: 2001:1234:5678:a700::/56 > Route preference: medium > Route lifetime :84531 (0x00014a33) seconds > Recursive DNS server : fd31:aeb1:48df::1 > DNS server lifetime : 6000 (0x1770) seconds > from fe80::6eb0:ceff:fef5:1e4a > > But now that it's going this NetworkManager-1.10.2-16.el7_5.x86_64 is > spamming the log as such: > > Jan 22 08:49:40 server NetworkManager[1842]: > [1548164980.5807] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:42 server NetworkManager[1842]: > [1548164982.0102] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:42 server NetworkManager[1842]: > [1548164982.5751] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:43 server NetworkManager[1842]: > [1548164983.2225] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:43 server NetworkManager[1842]: > [1548164983.5056] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:44 server NetworkManager[1842]: > [1548164984.7597] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:45 server NetworkManager[1842]: > [1548164985.4752] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:46 server NetworkManager[1842]: > [1548164986.1900] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:46 server NetworkManager[1842]: > [1548164986.8223] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:47 server NetworkManager[1842]: > [1548164987.5415] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:47 server NetworkManager[1842]: > [1548164987.5820] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:47 server NetworkManager[1842]: > [1548164987.7178] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:47 server NetworkManager[1842]: > [1548164987.8289] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:48 server NetworkManager[1842]: > [1548164988.2436] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:48 server NetworkManager[1842]: > [1548164988.9381] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:49 server NetworkManager[1842]: > [1548164989.1140] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:49 server NetworkManager[1842]: > [1548164989.8361] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:49 server NetworkManager[1842]: > [1548164989.9141] policy: set 'enp2s0' (enp2s0) as default > for IPv6 routing and DNS > Jan 22 08:49:51
Re: Network connection local to devices.
Hi, On Tue, 2019-01-22 at 09:56 +0100, Alexandre Garreau wrote: > How do you do that through GUI? There are several GUIs. For example, in nm-connection-editor there is the "Ethernet" tab with "Device" (which corresponds to the "connection.interface-name" and "ethernet.mac-address" properties). > Why does that work that way by default in GUI? or did I do something > wrong at some point maybe? I think it makes sense to restrict a profile by default to one device. Ultimately, that is decided by the client tool (like nm-applet) that creates the profile profile in such a way. It doesn't sound like you did anything wrong. If the setting is not best for your case, modify the profile as it suits you. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network connection local to devices.
On Mon, 2019-01-21 at 19:22 +0100, Alexandre Garreau via networkmanager-list wrote: > I often change computer, but keep my configuration files, or even my > whole system. Or, sometimes, I only change or add a new wifi card. > Each time I do that, network-manager becomes unable to automatically > use the old registered connection, as it is parametered for a > specific device: is there a way to disable that? Hi, don't set the parameters in the connection profile that restrict the profile to a particular device. For example, do not set (as applicable): - connection.interface-name - ethernet.mac-address - wifi.mac-address - match.interface-names - gsm.device-id - gsm.network-id And see `man nm-settings`. $ nmcli connection modify "$PROFILE" ethernet.mac-address '' best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Access Point & WPA2
SCAN_07012019.PDF > On Tue, 2018-12-11 at 20:12 +0100, Thomas Haller wrote:> > On Tue, 2018-12-11 at 12:38 +0200, Berend De Schouwer via> > networkmanager-list wrote:> > > On Tue, 2018-12-11 at 10:58 +0100, Thomas Haller wrote:> > > > On Tue, 2018-12-11 at 10:41 +0200, Berend De Schouwer wrote:> > > > > On Mon, 2018-12-10 at 17:22 +0100, Thomas Haller wrote:> > > > > > On Mon, 2018-12-10 at 12:15 +0200, Berend De Schouwer via> > > > > > > > Hi Berend,> > > > > > > > > > > > : ifindex=3 (wlan0) alg=4> > > > addr=0xe5906648 key_idx=4 set_tx=1 seq_len=0 key_len=16> > > > nl80211: set_key failed; err=-22 Invalid argument)> > > > WPA: group state machine entering state FATAL_FAILURE> > > > > > > > Beniamino said, "alg=4 is the IGTK, that should be required by> > > > PMF."> > > > Maybe try:> > > > > > > > nmcli connection modify "$PROFILE" wifi.pmf disable> > > > > > > > and reactivate the profile.> > > > > > That fixed it! Thanks Beniamino and Thomas.> > > > > > wifi.pmf disable resulted in alg=2:> > > > > > Dec 11 12:35:16 morgue.deschouwer.co.za NetworkManager[839]:> > > [1544524516.5910] device (wlan0): Activation: (wifi) Stage> > > 2> > > of 5 (Device Configure) successful. Started Wi-Fi Hotspot> > > 'HotelGUI'.> > > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]:> > > wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=2> > > addr=0xce5e1648 key_idx=1 set_tx=1 seq_len=0 key_len=32> > > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]:> > > nl80211: KEY_DATA - hexdump(len=32): [REMOVED]> > > Dec 11 12:35:16 morgue.deschouwer.co.za> > > wpa_supplicant[2426]:broadcast key> > > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]:> > > nl80211: Set wlan0 operstate 0->1 (UP)> > > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]:> > > netlink: Operstate: ifindex=3 linkmode=-1 (no change), operstate=6> > > (IF_OPER_UP)> > > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]:> > > wlan0:> > > interface state UNINITIALIZED->ENABLED> > > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]:> > > wlan0:> > > AP-ENABLED> > > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]:> > > wlan0:> > > State: SCANNING -> COMPLETED> > > > Hi,> > > > good to know. I wonder whether this is a bug in NetworkManager. If> > you> > leave pmf at "0 (default)", it seems it should just work.> > > > > > best,> > Thomas> > nmcli describes the default as "optionally enabled", which would> indicate that this behaviour is a bug.> > You could view it as a bug in NetworkManager or wpa_supplicant, or the> driver. Which layer needs the change?> > Also, now that I know what I'm looking for, there's this:> https://fedoramagazine.org/troubleshoot-pmf-f28/ ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP lease renew
On Mon, 2018-12-24 at 13:43 +, Usyskin, Alexander wrote: > > -Original Message- > > From: Thomas Haller [mailto:thal...@redhat.com] > > Sent: Monday, December 24, 2018 11:35 > > To: Usyskin, Alexander ; > > networkmanager- > > l...@gnome.org > > Subject: Re: DHCP lease renew > > > > On Mon, 2018-12-24 at 08:03 +, Usyskin, Alexander via > > networkmanager- > > list wrote: > > > Hi > > > > > > I'm trying to force DHCP lease renew for specific interface. > > > Basically replicate in Linux IpRenewAddress function from Win32 > > > API. > > > Without NetworkManager it's fairly simple, like "dhclient -r eth4 > > > && > > > dhclient -1 eth4". > > > But NetworkManager manages dhclient in different way, so that > > > lead to > > > an unexpected consequences. > > > > > > I can't find a way to ask NetworkManager to forcefully renew the > > > lease. Neither through DBus API, nor from command line. > > > Is there any way to do such thing? > > > If not, how can I file an enhancement request? > > > > > > Please CC me on reply, I'm not subscribed to this list. > > > > > Hi, > > > > > > $ nmcli device reapply $IFNAME > > > > (or, on D-Bus, via Device's Reapply() method). > > > > > > (or, fully reactivate the profile, like) > > > > nmcli connection up "$PROFILE" > > > > > > best, > > Thomas > > Tried to run reapply (via DBus call, but also tried nmcli), have > "NetworkManager[916]: [1545650569.2423] audit: op="device- > reapply" interface="eth4" ifindex=2 pid=28554 uid=0 result="success" > " > in syslog, but no DHCP activity observed on the link. > > What I'm doing wrong here? > > For the record it's Ubuntu 16.04 LTS with nm version 1.2.6 > > Thanks Hi, ah right. Reapply() doesn't restart DHCP. Sorry. I guess, that leaves you with: - a full reactivation, like nmcli connection up "$PROFILE" - disable and re-enable DHCP: nmlic device modifiy "$IFACE" ipv4.method disabled nmlic device modifiy "$IFACE" ipv4.method auto This also uses Reapply() D-Bus method under the hood. However, I don't know whether that works with 1.2.6, which is 2 years old. Maybe you could explain, why you want to request a new lease? best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: signal for (De)ActivateConnection?
On Sun, 2018-12-23 at 23:41 +0100, Michael Hirmke wrote: > Hi, > > after a long time I found some time to start the rewrite of my > script. > There are a few questions remaining, though. > > If I understood correctly, for a generic script I have to iterate > over > all existing connections (ListConnections). > What I don't understand actually is how to get a relation between the > connection settings object and an existing active connection object. > Do I have to iterate over all active connections and find a matching > uuid? Or do we have a simpler way to get to this > relation/information? Yes, that's one way. Of, if you know already which Device you are interested in, you can get from the device to the active connection to the (settings) connection. best, Thomas > > Thx. > > Bye. > Michael. > > [...] > > Hi, > > sounds a bit like you want to perform some action when a particular > > connection profile activates/deactivates. > > First, you need to know which a connection profile you care about, > > that > > is, you need its /org/freedesktop/NetworkManager/Settings/* path. > > You need to call GetSettings() on each of the profiles, to match > > what > > you are looking for (for example, matching the connection.id). > > When a connection is activated, it has an active-connection that > > references it. Usually there is at most one such active-connection, > > but while re-activating a connection there can be multiple once > > (one > > that is about to deactivate, and once that is about to activate). > > Anyway, you need to monitor these active connections for whether > > they > > reference the profile you care about. The Manager's PropertyChanged > > event for ActiveConnections notifies you when active-connection > > come to > > be and cease to exist. > > The ActiveConnection basically ties the profile to the networking > > device. > > and as said, an active VPN connection is a bit odd, they are > > active- > > connections too (with an additional > > org.freedesktop.NetworkManager.VPN.Connection interface). > > I would inspect the state with the "d-feet" GUI. > > You could also use libnm via GObject introspection (e.g. from Perl > > or > > Python). That might be more convenient to use, then a plain D-Bus > > library (the latter works of course too). We don't have any perl > > examples, only Python: > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/pyth > > on > > best, > > Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DHCP lease renew
On Mon, 2018-12-24 at 08:03 +, Usyskin, Alexander via networkmanager-list wrote: > Hi > > I'm trying to force DHCP lease renew for specific interface. > Basically replicate in Linux IpRenewAddress function from Win32 API. > Without NetworkManager it's fairly simple, like "dhclient -r eth4 && > dhclient -1 eth4". > But NetworkManager manages dhclient in different way, so that lead to > an unexpected consequences. > > I can't find a way to ask NetworkManager to forcefully renew the > lease. Neither through DBus API, nor from command line. > Is there any way to do such thing? > If not, how can I file an enhancement request? > > Please CC me on reply, I'm not subscribed to this list. > Hi, $ nmcli device reapply $IFNAME (or, on D-Bus, via Device's Reapply() method). (or, fully reactivate the profile, like) nmcli connection up "$PROFILE" best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Access Point & WPA2
On Tue, 2018-12-11 at 12:38 +0200, Berend De Schouwer via networkmanager-list wrote: > On Tue, 2018-12-11 at 10:58 +0100, Thomas Haller wrote: > > On Tue, 2018-12-11 at 10:41 +0200, Berend De Schouwer wrote: > > > On Mon, 2018-12-10 at 17:22 +0100, Thomas Haller wrote: > > > > On Mon, 2018-12-10 at 12:15 +0200, Berend De Schouwer via > > > > Hi Berend, > > > > > > : ifindex=3 (wlan0) alg=4 > > addr=0xe5906648 key_idx=4 set_tx=1 seq_len=0 key_len=16 > > nl80211: set_key failed; err=-22 Invalid argument) > > WPA: group state machine entering state FATAL_FAILURE > > > > Beniamino said, "alg=4 is the IGTK, that should be required by > > PMF." > > Maybe try: > > > > nmcli connection modify "$PROFILE" wifi.pmf disable > > > > and reactivate the profile. > > That fixed it! Thanks Beniamino and Thomas. > > wifi.pmf disable resulted in alg=2: > > Dec 11 12:35:16 morgue.deschouwer.co.za NetworkManager[839]: > [1544524516.5910] device (wlan0): Activation: (wifi) Stage 2 > of 5 (Device Configure) successful. Started Wi-Fi Hotspot > 'HotelGUI'. > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]: > wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=2 > addr=0xce5e1648 key_idx=1 set_tx=1 seq_len=0 key_len=32 > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]: > nl80211: KEY_DATA - hexdump(len=32): [REMOVED] > Dec 11 12:35:16 morgue.deschouwer.co.za > wpa_supplicant[2426]:broadcast key > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]: > nl80211: Set wlan0 operstate 0->1 (UP) > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]: > netlink: Operstate: ifindex=3 linkmode=-1 (no change), operstate=6 > (IF_OPER_UP) > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]: wlan0: > interface state UNINITIALIZED->ENABLED > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]: wlan0: > AP-ENABLED > Dec 11 12:35:16 morgue.deschouwer.co.za wpa_supplicant[2426]: wlan0: > State: SCANNING -> COMPLETED Hi, good to know. I wonder whether this is a bug in NetworkManager. If you leave pmf at "0 (default)", it seems it should just work. best, Thomas > > PS: it would be better to reply to the mailing list, and not me > > personally. Because so nobody else can help, and it's also not > > helpful > > for others. And if you paste text (the logfile) into the email, it > > would be nice to make sure that the lines are not wrapped. > > Preferably, > > attach the file to the email instead. Thanks!! > > It was my intention to mail the list, but I didn't check the To: > field > after hitting 'reply'. My mistake. Sorry. no problem!! :) signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Adhoc via dbus API?
On Tue, 2018-12-11 at 10:15 -0500, Jane Wyngaard via networkmanager- list wrote: > Hi, > > I just started using the python dbus API, but am having some > difficulties, hoping someone here might be able to help me? (I did > find the old thread in this list with an example script but API has > changed so much that no longer works even with significant changes). > > In brief: > - I can successfully configure and use an ADHOC network using (1) > manual edits of host file (after disabling NetworkManager), and (2) > using iwconfig. > - I can create an ADHOC with nm-applette gui but cannot connect to > it. > - What I need to do is create an adhoc with dbus but the attached > script which works perfectly to create a hotspot (with mode 'ap') > fails with bellow syslog messages when mode is 'adhoc' > > It looks like it creates the connection fine and even attempts to > activate but then hits some weird authentication issue I can't debug? Hi, while the script is not particularly elegant (e.g. it keeps polling whether the profile is fully activate), it should work fine in principle. It also succeeds to create a profile, but activation fails later on. This has nothing to do with D-Bus API. You can create the exact same profile with nmcli and encounter the same problem. What I mean, is that when I try `nmcli connection up MyAdhoc`, the activation also fails (just like with the python script). The question is, why it fails. But I don't know... General tip: enabling level=TRACE logging is helpful (see [1]). Also, check what is happening with `nmcli connection` and `nmcli device`. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 best, Thomas > > Any chance someone has a working dbus API Adhoc network setup script > they could share with me? > > */var/log/syslog* > Dec 11 10:12:01 Squid NetworkManager[17463]: > [1544541121.4386] keyfile: add connection /etc/NetworkManager/system- > connections/MyAdhoc-bac3019c-6be0-4d07-9617-c91a5438f422 (bac3019c- > 6be0-4d07-9617-c91a5438f422,"MyAdhoc") > Dec 11 10:12:01 Squid NetworkManager[17463]: > [1544541121.4397] audit: op="connection-add" uuid="bac3019c-6be0- > 4d07-9617-c91a5438f422" name="MyAdhoc" pid=18019 uid=1000 > result="success" > Dec 11 10:12:01 Squid NetworkManager[17463]: > [1544541121.4479] device (wlp4s0): disconnecting for new activation > request. > Dec 11 10:12:01 Squid NetworkManager[17463]: > [1544541121.4479] device (wlp4s0): state change: activated -> > deactivating (reason 'new-activation', sys-iface-state: 'managed') > Dec 11 10:12:01 Squid NetworkManager[17463]: > [1544541121.4480] manager: NetworkManager state is now > CONNECTED_LOCAL > Dec 11 10:12:01 Squid NetworkManager[17463]: > [1544541121.4594] audit: op="connection-activate" uuid="bac3019c- > 6be0-4d07-9617-c91a5438f422" name="MyAdhoc" pid=18019 uid=1000 > result="success" > Dec 11 10:12:01 Squid dbus-daemon[878]: [system] Activating via > systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus- > org.freedesktop.nm-dispatcher.service' requested by ':1.5229' (uid=0 > pid=17463 comm="/usr/sbin/NetworkManager --no-daemon " > label="unconfined") > Dec 11 10:12:01 Squid NetworkManager[17463]: > [1544541121.4600] device (wlp4s0): state change: deactivating -> > disconnected (reason 'new-activation', sys-iface-state: 'managed') > Dec 11 10:12:01 Squid avahi-daemon[961]: Withdrawing address record > for fe80::d80d:7c02:f195:d84f on wlp4s0. > Dec 11 10:12:01 Squid avahi-daemon[961]: Leaving mDNS multicast group > on interface wlp4s0.IPv6 with address fe80::d80d:7c02:f195:d84f. > Dec 11 10:12:01 Squid avahi-daemon[961]: Interface wlp4s0.IPv6 no > longer relevant for mDNS. > Dec 11 10:12:01 Squid systemd[1]: Starting Network Manager Script > Dispatcher Service... > Dec 11 10:12:01 Squid dbus-daemon[878]: [system] Successfully > activated service 'org.freedesktop.nm_dispatcher' > Dec 11 10:12:01 Squid systemd[1]: Started Network Manager Script > Dispatcher Service. > Dec 11 10:12:01 Squid nm-dispatcher: req:1 'connectivity-change': new > request (1 scripts) > Dec 11 10:12:01 Squid nm-dispatcher: req:1 'connectivity-change': > start running ordered scripts... > Dec 11 10:12:01 Squid NetworkManager[17463]: > [1544541121.4951] dhcp4 (wlp4s0): canceled DHCP transaction, DHCP > client pid 17430 > Dec 11 10:12:01 Squid NetworkManager[17463]: > [1544541121.4951] dhcp4 (wlp4s0): state changed bound -> done > Dec 11 10:12:01 Squid avahi-daemon[961]: Withdrawing address record > for 10.38.83.150 on wlp4s0. > Dec 11 10:12:01 Squid avahi-daemon[961]: Leaving mDNS multicast group > on interface wlp4s0.IPv4 with address 10.38.83.150. > Dec 11 10:12:01 Squid kernel: [510680.306141] wlp4s0: > deauthenticating from 88:1d:fc:e2:f0:1d by local choice (Reason: > 3=DEAUTH_LEAVING) > Dec 11 10:12:01 Squid wpa_supplicant[963]: wlp4s0: CTRL-EVENT- > DISCONNECTED bssid=88:1d:fc:e2:f0:1d reason=3
Re: Using both VPN and non-VPN (default route non-VPN)
On Mon, 2018-12-10 at 17:34 +0100, Alexandre Garreau via networkmanager-list wrote: > Hi, > I’ve already asked some help on irc: I have a VPN that provides me a > public IP, which I use to run network servers, but I want to access > the local network I’m connecting too, without passing through the VPN > (otherwise stuff accessible only through local network is not > accessible anywore), while still being able to use the tun0 > interface. It’s a OpenVPN VPN, configured and ran through network- > manager. I was told to go in IPv4, routes… and check the last > checkbox. > But beside routing, when doing that tun0 becomes inaccessible: > everything ends timeouting, and the other way around while not > checking the checkbox: the wifi interface is inaccessible, only the > tun0 answers… > Why that? is it more an openvpn problem? But if asking openvpn people > will I find a way to apply that through network-manager? > Thank you for any help ^^ Hi, you need to have the routes configured properly, which depends on your environment. 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 best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: u-blox R410M modem (QMI) configuration with modern Network-manager
On Fri, 2018-11-30 at 11:24 -0800, Tim Harvey wrote: > root@bionic-newport:~# nmcli connection add type gsm con-name mymodem > apn $APN > Error: 'ifname' argument is required. try: $ nmcli connection add type gsm con-name mymodem apn $APN ifname '' or $ nmcli connection add type gsm con-name mymodem apn $APN ifname '*' best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: D-Bus: Asking for a wifi rescan
On Mon, 2018-11-26 at 11:22 +0100, Damien Cassou wrote: > Thomas Haller writes: > > On Mon, 2018-11-26 at 09:53 +0100, Damien Cassou wrote: > > > How do my code know when the scan is finished? > > > > wait for "LastScan" property to change. You don't really care > > about > > the timestamp value there, just that it changes. > > thank you for your answer. I would like to add the information to the > method description in the documentation: > > https://developer.gnome.org/NetworkManager/stable/gdbus-org.freedesktop.NetworkManager.Device.Wireless.html#gdbus-method-org-freedesktop-NetworkManager-Device-Wireless.RequestScan > > Where can I find the source of this page please? I will send a PR. > Hi, that is welcome! here: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/introspection/org.freedesktop.NetworkManager.Device.Wireless.xml?id=25a0739658a19aa3e445088bbec7dca3aebd5279#n36 libnm API gets generated fom there: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/libnm/nm-device-wifi.c?id=25a0739658a19aa3e445088bbec7dca3aebd5279#n353 See also, the latest documentation generated for master branch: https://networkmanager.pages.freedesktop.org/NetworkManager/NetworkManager/ https://networkmanager.pages.freedesktop.org/NetworkManager/libnm/ ^^ these two URLs will likely change in the future. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: D-Bus: Asking for a wifi rescan
On Mon, 2018-11-26 at 09:53 +0100, Damien Cassou wrote: > Hi, > > with the interface org.freedesktop.NetworkManager.Device.Wireless, I > can > call the method "RequestScan" on a wifi device. How do my code know > when the > scan is finished? > > Relevant documentation: > https://developer.gnome.org/NetworkManager/stable/gdbus-org.freedesktop.NetworkManager.Device.Wireless.html > > Hi, wait for "LastScan" property to change. You don't really care about the timestamp value there, just that it changes. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Unable to add IPv6 address?
On Fri, 2018-11-23 at 22:26 +0100, Florian Leeber via networkmanager- list wrote: > Hello again, > > this seems to be phone specific for some reason, but we dont know > why. > We cannot add IPv6 addies on the mobile: > > Nov 23 22:23:46 ubuntu-phablet NetworkManager[1774]: > [1543008226.9182] platform-linux: netlink: recvmsg: error message > from > kernel: Invalid argument (22) for request 1653 > Nov 23 22:23:46 ubuntu-phablet NetworkManager[1774]: > [1543008226.9188] platform-linux: do-add-ip6-address[21: > 2a02:8388:8980:e700:9c4b:f32a:6c81:df77]: failure 22 (Invalid > argument) > > I found only very few informations about this. Any ides? > > > BR > > Hi, please enable level=TRACE logging and show more context. See hints at [1] for how to do that. What is the version of NetworkManager, and which kernel? https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf It's probably not directly related to mobile, but IPv6 in general. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Tue, 2018-11-06 at 12:23 +0100, Thomas HUMMEL wrote: > On 10/26/18 12:55 PM, Thomas HUMMEL wrote: > > > Generally, there are the device states "unmanaged" -> > > > "unavailable" -> > > > and "disconnected". For ethernet devices, a device is usually > > > "unavailable" because it has no carrier. > > > > As a matter of fact, when no udev rules for NM_UNMANAGED, the > > device is > > in the disconnected state. > > > > As for the traces, here's what I've got : > > > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.5859] ifcfg-rh: loading from file > > "/etc/sysconfig/network-scripts/ifcfg-eth0"... > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.5861] settings-connection[0x7fbffc006890]: constructed > > (NMIfcfgConnection) > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.5870] > > settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1- > > d6edd65f3e03]: update > > settings-connection flags to visible (was none) > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.5875] > > settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1- > > d6edd65f3e03]: disposing > > > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.5878] > > settings-connection[0x7fbffc006890,5fb06bd0-0bb0-7ffb-45f1- > > d6edd65f3e03]: update > > settings-connection flags to none (was visible) > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6729] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6752] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6771] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6790] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6809] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6827] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6845] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6865] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:44:04 xcat-myriad NetworkManager[606]: > > [1540550644.6883] platform-linux: event-notification: > > RTM_NEWROUTE, > > flags 0, seq 1540550645: ignore > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0031] device[0x55a73f560c80] (eth1): sys-iface-state: > > external -> assume > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0033] device[0x55a73f560c80] (eth1): unmanaged: flags > > set to > > [user-udev,!sleeping,!loopback,!platform-init,!user-explicit,!user- > > settings=0x400/0x479/managed], > > > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0033] device (eth1): state change: unmanaged -> > > unavailable > > (reason 'connection-assumed', sys-iface-state: 'assume') > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0034] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/accept_ra': '1' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0035] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/accept_ra_defrtr': '1' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0035] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/accept_ra_pinfo': '1' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0035] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/accept_ra_rtr_pref': '1' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0036] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/forwarding': '0' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0036] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/disable_ipv6': '1' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0036] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/hop_limit': '64' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0037] platform-linux: sysctl: reading > > '/proc/sys/net/ipv6/conf/eth1/use_tempaddr': '0' > > Oct 26 12:47:03 xcat-myriad NetworkManager[606]: > > [1540550823.0039] device[0x55a73f560c80] (eth1): device not yet > > available for transition to DISCONNECTED > > Oct 26
Re: nmcli connection down
On Tue, 2018-11-13 at 14:03 +0100, Thomas HUMMEL wrote: > On 11/13/18 1:56 PM, Thomas Haller wrote: > > > > I think this is just a documentation bug. > > > > Fixed: > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=17f9801e07df0c544e0416c65cedc28727476e55 > > > > Thanks for actually reading the documentation and pointing out > > confusing/wrong parts!! > > Thanks for your time. > > By the way : isn't there a typo in your path ? > > + Note that the deactivating connection profile is > + internally blocked from autoconnecting again > > didn't you mean deactivatED ? > Hi, Maybe. But the moment when you issue $ nmcli connection down "$PROFILE" the "$PROFILE" is in the process of deactivating. It's not yet fully deactivated. Hence, it is "the profile which is currently deactivating". Seems correct to me as-is, but no strong preference. WDYT? best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nmcli connection down
On Thu, 2018-11-08 at 16:30 +0100, Thomas HUMMEL wrote: > Hello, > > nmcli(1) states about the connection down command : > > "Be aware that this command deactivates the specified active > connection, > but the device on which the connection was active, is still ready to > connect and will perform auto-activation by looking for a suitable > connection that has the 'autoconnect' flag set. This includes the > just > deactivated connection. So if the connection is set to auto-connect, > it > will be automatically started on the disconnected device again." > > In the following simple test : > > # ls -l /var/lib/NetworkManager/no-auto-default.state > -rw-r--r-- 1 root root 0 Nov 8 16:25 > /var/lib/NetworkManager/no-auto-default.state > > # nmcli connection delete foobar > Connection 'foobar' (eedc4b58-5a81-45e9-9cac-586f9f25f61d) > successfully > deleted. > > # nmcli connection add type ethernet con-name foobar ifname eth1 > Connection 'foobar' (1c34b34b-f3ab-4d7d-8a19-3fdf618a16f3) > successfully > added. > > # nmcli -f connection.autoconnect connection show foobar > connection.autoconnect: yes > > # nmcli -f GENERAL.AUTOCONNECT device show eth1 > GENERAL.AUTOCONNECT:yes > > # nmcli connection down foobar > Connection 'foobar' successfully deactivated (D-Bus active path: > /org/freedesktop/NetworkManager/ActiveConnection/2) > > # nmcli connection show > NAMEUUID TYPE DEVICE > foobar 1c34b34b-f3ab-4d7d-8a19-3fdf618a16f3 ethernet -- > > # ip address show dev eth1 > 3: eth1: mtu 1500 qdisc mq state > UP > group default qlen 1000 > link/ether 00:50:56:8a:42:bf brd ff:ff:ff:ff:ff:ff > > > it seems to me I'd qualified to the "This includes the just > deactivated > connection." case ? So why doesn't the device auto-reconnects ? Hi, I think this is just a documentation bug. Fixed: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=17f9801e07df0c544e0416c65cedc28727476e55 Thanks for actually reading the documentation and pointing out confusing/wrong parts!! best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM - dnsmasq, shared conn. no IP to client
On Mon, 2018-11-05 at 20:25 +0200, Kemal Kilic via networkmanager-list wrote: > Hello Folks, > > I have 64 bit openSUSE Tumbleweed. > Just a week ago my shared wifi and ethernet connections were working > with NetworkManager > > I do not know what happened but now I got such messages and the > client can not get IP address > Why dnsmasq can not create that lease file in > /var/lib/NetworkManager? > How can I get over this problem? > > Thanks for your time. > Here is the NetworkManager log: > > systemctl status NetworkManager > ● NetworkManager.service - Network Manager > Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; > enabled; vendor preset: disabled) > Drop-In: /usr/lib/systemd/system/NetworkManager.service.d > └─NetworkManager-ovs.conf > Active: active (running) > Docs: man:NetworkManager(8) > Main PID: 1319 (NetworkManager) >Tasks: 4 (limit: 4915) > CGroup: /system.slice/NetworkManager.service > ├─1319 /usr/sbin/NetworkManager --no-daemon > └─1704 /sbin/dhclient -d -q -sf /usr/lib/nm-dhcp-helper -pf > /var/run/dhclient-enp5s0.pid -lf /var/lib/NetworkManager/dhclient- > 5aa08187-8d97-4502-836f-6f26683d034e-enp5s0.lease -cf /var/lib/N> > > Nov 05 20:13:51 michael NetworkManager[1319]: > [1541441631.6756] Executing: /usr/sbin/iptables --table nat --insert > POSTROUTING --source 10.42.0.0/255.255.255.0 ! --destination > 10.42.0.0/255.255> > Nov 05 20:13:51 michael NetworkManager[1319]: > [1541441631.6767] dnsmasq-manager: starting dnsmasq... > Nov 05 20:13:51 michael NetworkManager[1319]: > [1541441631.6778] device (wlp2s0f0u10): state change: ip-config -> > ip-check (reason 'none', sys-iface-state: 'managed') > Nov 05 20:13:51 michael NetworkManager[1319]: > [1541441631.6788] device (wlp2s0f0u10): state change: ip-check -> > secondaries (reason 'none', sys-iface-state: 'managed') > Nov 05 20:13:51 michael NetworkManager[1319]: > [1541441631.6790] device (wlp2s0f0u10): state change: secondaries -> > activated (reason 'none', sys-iface-state: 'managed') > Nov 05 20:13:51 michael NetworkManager[1319]: dnsmasq: cannot open or > create lease file /var/lib/NetworkManager/dnsmasq-wlp2s0f0u10.leases: > Permission denied > Nov 05 20:13:51 michael dnsmasq[692]: cannot open or create lease > file /var/lib/NetworkManager/dnsmasq-wlp2s0f0u10.leases: Permission > denied > Nov 05 20:13:51 michael dnsmasq[692]: FAILED to start up > Nov 05 20:13:51 michael NetworkManager[1319]: > [1541441631.6902] device (wlp2s0f0u10): Activation: successful, > device activated. > Nov 05 20:13:51 michael NetworkManager[1319]: > [1541441631.6907] dnsmasq-manager: dnsmasq exited with error: > Filesystem problem (missing file/directory, permissions) (3) > Hi, maybe an SELinux problem? If that's the case, there should be SELinux warnings in your syslog. Note that the SELinux policy is commonly not maintained upstream (here), but by your distibution. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dns-search ordering on dual nic setup
On Mon, 2018-11-12 at 11:37 +0100, Thomas HUMMEL wrote: Hi, > > [I'm talking only about ipv4.method=manual wired ethernet connections > here] > > As far as I experience, the 'search' line in the NetworkManager > resolv.conf file comes from the union of all the ipv4.dns-search > properties of all the active profiles and the order of the domains > it > lists doesn't depend on the order of profile activation. > > - am I right ? Right, I think the time of profile activations is not generally meaningful. > - does the order then depend on the order of the underlying devices > (i.e. dns-search of eth0 first, dns-search of eth1 second, ...) ? No, devices neither have a meaningful sort order. > What would be the best way to enforce a particular order ? > > For instance let's say > > eth0 profile : ipv4.dns-search my.public.domain > eth1 profile : ipv4.dns-search some.private.non-routed-domain > > By default, it seems that when the 2 profiles are connected, I've got > > search my.public.domain some.private.non-routed-domain > > in /etc/resolv.conf > > What if I want the opposite order ? Configure `ipv4.dns-priority` accordingly. You may require a recent NM verions for that. In the usual case, where multiple profiles have the same dns-priority, the device with the (best) default-route is preferred. > > Note : the idea here is to have the short non-qualified host name as > the > hostname and make hostname --fqdn return > .some.private-non-routed.domain > > Thanks > best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: stale prefix being resurrected on each received RA
On Thu, 2018-11-08 at 08:05 -0500, Brian J. Murrell wrote: > Hi. I have NM on 1.12.4 on Fedora 29 sitting behind my Internet > gateway router which has both IPv4 and IPv6 upstream connections. > > Recently one of my IPv6 upstream connections changed and got a new > prefix. My Internet gateway handled that just fine and started > announcing the new prefix in it's RAs to the LAN. > > However, this NM 1.12.4 machine, upon receiving the RAs from the > Internet gateway seems to be resurrecting an address to the previous > prefix that was being advertised by my upstream (as well as the > currently advertised prefix). > > Even if I remove the stale address using "ip addr del", on the next > received RA, NM will resurrect that old address even though it's not > even one of the addresses the Internet gateway is including in it's > RA. > > I have not restarted NM. Probably if I do, this problem will go away > but I wanted to hopefully take this opportunity to provide any > desired > debug info to help solve this issue. > > Is there any useful info I can gather at this point or shall I just > restart NM? > > Cheers, > b. Hi, 1.12.4 has https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=c7d8f17094a24aec4a1a79447cda3bc208b751a5 With this, it would be expected that the prefix continues to exist for up to two hours. However, the old prefix's preferred time should also be expired right away. Did you for wait up to two hours for the prefix to disappear? Was the problem still present after two hours? Was the old addresse expired (preferred_lft)? best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Fri, 2018-10-26 at 12:01 +0200, Thomas HUMMEL wrote: > On 10/26/2018 10:05 AM, Thomas Haller wrote: > > > > Ah, there is also `nmcli -f GENERAL.NM-MANAGED device show eth0 `, > > but > > this just returns (state != "unmanaged"). > > Wait : what's the diffence (if any) between GENERAL.NM-MANAGED == no > and > GENERAL.STATE == 10 (unmanaged) ? There is none: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices/nm-device.c?id=085b769729e9c623cc60bb0f88df36d1843cd22b#n16346 > > > > Optimally, there would be a nother flag which is the opposite of > > `nmcli > > device set $DEV managed $VALUE`. So, when you issue device-set, it > > would succeed and would toggle this flag, but that alone may not be > > sufficient to make the device (fully) GENERAL.NM-MANAGED yet. > > I don't see what you mean here by "the opposite" : maybe just a flag > to > reflect the request (and its ack) of the desire to manage the device > ? I mean, a flag (in NetworkManager public API) that exposes the user's intent of managing the device. That is, what `nmcli device set $DEV managed yes` sets. ... which may be slighly different than whether the device is actually "state != unmanaged". > > > > > > # nmcli device set eth1 managed yes > > > # echo $? > > > 0 > > > # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show > > > GENERAL.DEVICE: eth1 > > > GENERAL.STATE: 20 (unavailable) > > > > state "unavailable", looks like the device has no cable plugged in > > (no > > carrier). You'd also see that with `ip link show eth1` saying "NO- > > CARRIER". > > Well, it's a VMWare virtual interface but 'connected' in VMWare and > iproute shows : > > 3: eth1: mtu 1500 qdisc noop state DOWN mode > DEFAULT group default qlen 1000 > link/ether 00:50:56:8a:42:bf brd ff:ff:ff:ff:ff:ff > > It seems normal to me the device is down since no one as configured > it. > But it seems I'm in a different case than no carrier'... > Maybe I'm supposed to see a LOWER_DOWN ? > > > Activation of the created profile then probably fails, because the > > device has no carrier (which is required for successful DHCP). > > Obviously the reason here is that the device is still unavailable > but > the question is why ? ;-) hm, good question. I don't know, I would need to see the level=TRACE syslog (journal) of NM. Btw, for hints for getting the logfile see https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf Generally, there are the device states "unmanaged" -> "unavailable" -> and "disconnected". For ethernet devices, a device is usually "unavailable" because it has no carrier. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
Hi, On Thu, 2018-10-25 at 20:35 +0200, Thomas HUMMEL wrote: > On 10/18/2018 11:30 PM, Thomas Haller wrote: > > Btw, note that if you configure the device as unmanaged via > > NM_CONTROLLED=no in ifcfg, then the device cannot be set to > > managed. > > This way of unmanaging a device is definite, > > Hello again, another use case I'm still wrapping my head around > (even > with the precious knowledge acquired thanks to your help!) > > Let's say I've got this setup : > > - eth0 NM_CONTROLLED=no > - eth1 NM_UNMANAGED=1 via udev > (and suppose eth1 in no-auto-default.state) > > here's what I'm testing > > - about NM_CONTROLLED=no : > > # nmcli connection show > NAME UUID TYPE DEVICE > > # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show > GENERAL.DEVICE: eth0 > GENERAL.STATE: 10 (unmanaged) > > GENERAL.DEVICE: eth1 > GENERAL.STATE: 10 (unmanaged) > > GENERAL.DEVICE: lo > GENERAL.STATE: 10 (unmanaged) > > # nmcli device set eth0 managed yes > # echo $? > 0 > # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show > GENERAL.DEVICE: eth0 > GENERAL.STATE: 10 (unmanaged) > > -> as you explained, unmanaging a device this way is definite, but > is > the 0 return value legit here ? The return value of the nmcli command is odd, maybe a bug. It returns success, because it successfully flagged the device that the user wishes to manage it. However, there may still be other (stronger) reasons, why the device stays unmanaged (NM_CONTROLLED=no). Ah, there is also `nmcli -f GENERAL.NM-MANAGED device show eth0 `, but this just returns (state != "unmanaged"). Optimally, there would be a nother flag which is the opposite of `nmcli device set $DEV managed $VALUE`. So, when you issue device-set, it would succeed and would toggle this flag, but that alone may not be sufficient to make the device (fully) GENERAL.NM-MANAGED yet. > - about the following sentence in man regarding NM_UNMANAGED : > > "You will still be able to attach a connection to the > device manually or observe externally added configuration such as > addresses or routes." I think this part of the manual should be improved. https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=085b769729e9c623cc60bb0f88df36d1843cd22b > > # nmcli device set eth1 managed yes > # echo $? > 0 > # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show > GENERAL.DEVICE: eth1 > GENERAL.STATE: 20 (unavailable) state "unavailable", looks like the device has no cable plugged in (no carrier). You'd also see that with `ip link show eth1` saying "NO- CARRIER". > -> it's not unmanaged anymore, so it's managed > > # nmcli connection show > NAME UUID TYPE DEVICE > > -> still no connection, seems normal to me I agree. A connection would only be created via the "auto-default" mechanism, which depends on main.no-auto-default setting and /var/lib/NetworkManager/no-auto-default.state. Not sure whether that's the case, or because the device state is still unavailable... either way, this doesn't seem wrong here (without knowing all the details). > # nmcli device connect eth1 > Error: Failed to add/activate new connection: Connection 'eth1' is > not > available on the device eth1 at this time. Here, (I think), first nmcli tried to activate a profile on the device. That failed, because no profile exists. Then it tried to create a new profile (with ipv4.method=auto). Activation of the created profile then probably fails, because the device has no carrier (which is required for successful DHCP). > -> ok, seems normal to as well since auto profile creation must not > work > under NM_UNMANAGED conditions no, I think this part of the manual is misleading. A device is either "unmanaged" or not. Udev's NM_UNMANAGED is a way to configure the device as unmanaged, and `nmcli device set $DEV managed yes` can overrule that. Aterwards, there is no further difference between other managed devices. > > # nmcli connection add type ethernet con-name managed-eth1 ifname > eth1 > Connection 'managed-eth1' (41727fca-d424-40d9-91e7-55197ff9a962) > successfully added. > > # nmcli connection show > NAME UUID TYPE DEVICE > managed-eth1 41727fca-d424-40d9-91e7-55197ff9a962 ethernet -- > > -> ok I managed to create a connection somehow linked to eth1 > device. > It's not active which also seems normal to me It didn't autoactivate, because the device's state is "unavailable" If you'd create a profile with ipv4.method=manual, you could also activate it on a device with cabel unplugged. > But then I cannon neither connect the eth1 device nor activate the > newly > created profile > > -> what's happening here ? > best, Thomas signature.asc Description: This is a digitally
Re: NetworkManager behavior answers not found in docs
On Wed, 2018-10-24 at 16:40 +0200, Thomas HUMMEL wrote: > On 10/24/2018 04:11 PM, Thomas HUMMEL wrote: > > > > Reapply doesn't seem to have any relevance with modification or > > > persistance. > > > > Yes so now my understanding of reapply is more like "restore" (to > > its > > original settings). Does this make sense even with non disk backed > > applied profiled (I guess that's what you tried to explain to me in > > a > > previous message where you were talking about a clone of the > > profile). > > In fact I don't understand reapply anymore : > > - it doesn't affect the profile right, the profile is unchanged. > - a nmcli device modify (802-3-ethernet.mtu for instance) > seems > to immediatly (re)apply the change I'm doing to the active profile. > > So, I don't understand anymore when I'm supposed to issue a nmcli > device > reapply ? First of all, device-reapply might not be something that is frequently used. So, you can be perfectly fine, without ever using it. Remember, that a modification of the profile (`nmcli connection modify`) does not take effect immeiately (except "connection.zone" and "connection.metered" properties). You usually need to do a full re- activation for the changes to take effect (`nmcli connection up`). `nmcli device reapply` is mostly like re-activating the profile, however it does not a full re-activation. As such, it may be less disruptive. For example, if your device is a bridge (with vlan devices on top of it), a full `nmcli connection up "$BRIDGE_PROFILE"` needs to destroy all the vlans on top, and unenslave all slaves from the bridge. That's pretty disruptive. `nmcli device reapply` wouldn't. However, you can also reapply certain changes, like an IP address but not a MAC address change. It would simply fail if the changes are too invasive. Yes, it's not unlike `nmcli device modify $DEVICE`. For example, nmcli connection up "$PROFILE" ifname "$DEVICE" nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.77.5/24 nmcli device reapply "$DEVICE" is basically the same as: nmcli connection up "$PROFILE" ifname "$DEVICE" nmcli connection modify "$PROFILE" +ipv4.addresses 192.168.77.5/24 nmcli device modify "$DEVICE" +ipv4.addresses 192.168.77.5/24 best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Thu, 2018-10-25 at 15:09 +0200, Thomas HUMMEL wrote: > On 10/25/2018 03:05 PM, Thomas Haller wrote: > > On Thu, 2018-10-25 at 14:58 +0200, Thomas HUMMEL wrote: > > > On 10/24/2018 01:19 PM, Thomas Haller wrote: > > > > > > > > > > Both the device and the profile must be willing to autoconnect > > > > for > > > > it > > > > to happen. It's both ways. That's why you can suppress > > > > autoconnect > > > > on > > > > both sides. > > > > > > > > > Also, how can I check the status of a device autoconnect flag (as > > > set > > > by > > > nmcli device set autoconnect) ? > > > > > > > hi > > > > that would be: > > > >nmcli -f GENERAL.AUTOCONNECT device show "$DEVICE" > > Indeed. How is it that I don't see that property with a simple > single > nmcli device show ? try: nmcli -f ALL device show wlan > > Thanks > > -- > Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Wed, 2018-10-24 at 19:58 +0200, Thomas HUMMEL wrote: > On 10/24/2018 06:22 PM, Thomas Haller wrote: > > > Let's call this "externally managed". Not sure that's helpful, but > > in > > NetworkManager source code it's called like that. > > > > In nmcli output, you cannot really distinguish a regular activated > > profile from such an externally managed one. Except, that in the > > latter > > case the profiles was autocreated and its name is the device name > > (eth1). > > Understood. > > Now if I edit this connection matching an externally managed device > (for > instance using nmcli connection edit), would that turn it into a > normally managed one ? Hi, Optimally yes. the profile for the externally managed device is at first in a way, that when the device disconnects (for example, because you remove the IP address again), that it gets automatically removed again. If you modify the profile, then the generated profile will no longer be automatically removed when the device disconnects later. It will continue to exist until you delete it (or until NetworkManager restarts, in case of `nmcli connection modify --temporary`). If you interact with such an externally managed device, then NM is supposed to fully take over... that in particular is the case with - nmcli device disconnect ... - nmcli device connect ... - nmcli connection up $ANY_PROFILE # on the device in question - nmcli connection down $THE_GENERATED_PROFILE - nmcli connection delete $THE_GENERATED_PROFILE where NM disconnects the device (and possibly fully activates a profile afterwards). optimally, the following would fully take over the device too, however in a graceful manner that does not affect your connectivity: - nmcli device reapply $DEVICE - nmcli connection modify $THE_GENERATED_PROFILE - nmcli device set "$DEVICE" managed yes after such an operation, the device should no longer be externally managed. But likely there are issues with this. They should be fixed, but to be safe, you should just fully re-connect the device with one of the above. also, optimally - nmcli device set $DEV managed no marks the device directly as unmanaged (including removing the generated profile), without interfering with the external configuration at all. There might be issues with this as well (meaning: it might touch the device and destroy some external configuration). best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Thu, 2018-10-25 at 14:58 +0200, Thomas HUMMEL wrote: > On 10/24/2018 01:19 PM, Thomas Haller wrote: > > > > Both the device and the profile must be willing to autoconnect for > > it > > to happen. It's both ways. That's why you can suppress autoconnect > > on > > both sides. > > > Also, how can I check the status of a device autoconnect flag (as set > by > nmcli device set autoconnect) ? > hi that would be: nmcli -f GENERAL.AUTOCONNECT device show "$DEVICE" best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Wed, 2018-10-24 at 15:52 +0200, Thomas HUMMEL wrote: > On 10/24/2018 01:23 PM, Thomas Haller wrote: > > > Hi, > > > > An unmanaged device is in state "unmanaged". All other states (like > > "100 (connected)") are not-unmanaged, which means they are > > "managed". > > > >$ nmcli -f GENERAL.DEVICE,GENERAL.STATE device show > >$ nmcli -f GENERAL.DEVICE,GENERAL.STATE device show "$DEVICE" > > Hello, > > That's what I thought but on a previously discussed case of an > externally configured device, here's what I'm experiencing : > > > # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show eth1 > GENERAL.DEVICE: eth1 > GENERAL.STATE: 30 (disconnected) > > > # ip addr show eth1 > 3: eth1: mtu 1500 qdisc mq state > UP > group default qlen 1000 > link/ether 00:50:56:8a:42:bf brd ff:ff:ff:ff:ff:ff > > > # ip addr add 192.168.10.200/24 dev eth1 > > # nmcli -f GENERAL.DEVICE,GENERAL.STATE device show eth1 > GENERAL.DEVICE: eth1 > GENERAL.STATE: 100 (connected) > > But I thought we said that in such a case a profile would be > autocreated > (and autoconnected) but only to reflect that something is active but > which is not going to be managed (like for dhcp requests...) by NM ? > > Did I misunderstood ? I wasn't very clear here, sorry. So, the device can be in state "unmanaged" and that's it. If you have a device not "unmanaged" (that is, any other state), and you externaly add IP configuration (like you did here), this is the case 3) from my earlier email. I said, in this case the device is not actively managed by NM, meaning, NM does not do anything with it. This is different from the proper "unmanaged" case. The device looks managed, but NM also doesn't mess with it. Let's call this "externally managed". Not sure that's helpful, but in NetworkManager source code it's called like that. In nmcli output, you cannot really distinguish a regular activated profile from such an externally managed one. Except, that in the latter case the profiles was autocreated and its name is the device name (eth1). best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Tue, 2018-10-23 at 17:29 +0200, Thomas HUMMEL wrote: > On 10/17/2018 10:38 AM, Thomas Haller wrote: > > 3) if you do > > > >nmcli device disconnect eth0 > >ip addr add 192.168.7.5/24 dev eth0 > > > > NM now creates an in-memory connection "eth0". This means that > > NetworkManager*does not* manage this device. > > Among the things I forgot : I understand what you explained but I > cannot > figure out a way to make nmcli confirm that the device is not > managed. > > For instance : > > # nmcli -f GENERAL.STATE device show eth1 > GENERAL.STATE: 100 (connected) > > I guess the 'connected' hides the 10 (unmanaged) I can see in > different > situations ? > > # nmcli device show eth1 | grep -i managed > # Hi, An unmanaged device is in state "unmanaged". All other states (like "100 (connected)") are not-unmanaged, which means they are "managed". $ nmcli -f GENERAL.DEVICE,GENERAL.STATE device show $ nmcli -f GENERAL.DEVICE,GENERAL.STATE device show "$DEVICE" best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Tue, 2018-10-23 at 15:25 +0200, Thomas HUMMEL wrote: > On 10/18/2018 11:30 PM, Thomas Haller wrote: > > The profile has a "connection.autoconnect" property. If it's "no", > > the > > profile never autoconnects. Period. > > > > But there also needs to be a device which is currently in a state > > where > > it would like to autoconnect a profile. With `nmcli device set > > "$DEVICE" autoconnect no" you can set that. > > > > for example, `nmcli device disconnect "$DEVICE"` will block > > autoconnect > > on the device. It would be pretty annoying, if you disconnect the > > device and immediatley some profile autoconnects again. > > > > > > > > > > "Autoconnect" prefers profiles which > > > > were active last > > > > > > Same remark here > > > > When a device wants to autoconnect a profile, there might be > > multiple > > profiles which are compatible candidtes. Then, the one is chosen > > with > > the best "connection.autoconnect-priority" or as last, the > > timestamp > > when the profile was activate the last time. > > > > > > So, would that be correct to think about it this way : > > it is a device which, by defaults, "wants" to autoconnect and try to > find a profile with connection.autoconnect property set to yes ? > > and device disconnect or device set autoconnect no inhibit > this > behavior ? > > I mean as opposed to a profile which would "want" to auto "connect" > to a > device ? Yes, kind of. Both the device and the profile must be willing to autoconnect for it to happen. It's both ways. That's why you can suppress autoconnect on both sides. And in various situations, autoconnect will also be internally blocked. For example for the device (after `nmcli device disconnect`) and or the profile (e.g. no secrets provided)). best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Fri, 2018-10-19 at 19:22 +0200, Thomas HUMMEL wrote: Hi, > > > > Usually, NetworkManager (the daemon) does not automatically > > > > create > > > > connection profiles > > > > > > > > > But when it does (as in your cases), is it always only in RAM > > > (unless > > > we > > > then save the profile to disk of course) ? > > > > Yes. But when you modify this profile, it usually gets persisted to > > disk. > > I see in my tests that a profile modification is persisted even > before > the call to nmcli device reapply : am I right ? Hm, `nmcli device reapply` does not modify the profile at all, does it? > What's the link between persistence, modification and reapplication > of a > profile ? A profile may be backed by a file on disk or not. Accordingly, it is persited or not. Whenever you modify a profile, you can also say whether it should be persited to disk or not. If the profile had a backing file on disk, making it in-memory only may or may not involve deleting the file. On the D-Bus API, it controlled via Update2 flags [1]. [1] https://developer.gnome.org/libnm/unstable/libnm-nm-dbus-interface.html#NMSettingsUpdate2Flags nmcli gives you some control over that, like `nmcli connection add save no ...` and `nmcli connection modify --temporary ...`. Reapply doesn't seem to have any relevance with modification or persistance. > > Maybe NM created such an "auto-default" (named "Wired Connection > > #"), > > but then you deleted it? It wouldn't create it again, see file > > /var/lib/NetworkManager/no-auto-default.state. > > The MAC is indeed in there although I don't remember deleting an > auto > created profile > best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IPv6 RA route add/removal does not trigger dispatch action
On Sun, 2018-10-21 at 18:18 -0700, Matthew Gyurgyik wrote: > My ISPs router/modem does not support DHCPv6 and therefore I can only > use stateless configuration. To deal with some silliness from my from > my ISP, I need perform some extra configuration once the interface > gets an IP address. I'd like to re-run the script when addresses are > added or removed from the interface. > > When I bring up the interface, I see the `pre-up`, `up`, and `dhcp6- > change` actions get triggered. However, when new routes are added or > removed from the router advertisement, NetworkManager adds/removes > the the corresponding addresses, but does not trigger a dispatch > event. > > Is the lack of a dispatch event expected and/or desired behavior? > Should an action get triggered? > > Running Fedora 28 with NetworkManager-1.10.12. > Hi, I think it's a missing feature. However, it also seems problematic, because a lot of router advertisements are received. Running the dispatcher scripts each time, sounds expensive. But they could be in a separate directory, and NM would only spawn the dispatcher if there are any scripts there. Like already done for pre-up and pre-down. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Wed, 2018-10-17 at 19:34 +0200, Thomas HUMMEL wrote: > Hello, > > thanks for your answers. Very useful ! > Much content to digest ;-) > > > you can ignore > > initscripts entirely. > > I know, I was just curious about how they used D-Bus and nmcli and > how > compatibility worked both ways (network-scripts <-> NM) > > > > There is little difference > > > >- `nmcli connection up "$PROFILE"` will find a suitable device > > automatically. > >- `nmcli device connect "$DEVICE"` will find a suitable > > connection > > automatically. Note this may create a new profile (see later). > >- `nmcli connection up "$PROFILE" ifname "$DEVICE" explicitly > > selects > > both the profile and the device. > > ok > > > As the profile contains the necessary settings for what to do with > > the > > device, you cannot ~configure~ a device without a profile. > > ok > > > re-activating can be done via `nmcli connection up` (or similar) > > and > > goes through a full re-activation cycle (and temporarily > > disconnects > > you). A more graceful way is `nmcli device reapply "$DEVICE"` which > > takes the changes and configured on the device. > > > > `nmcli device reapply` may also be useful if there are no actual > > changes in the device. For example, it will re-start DHCP and > > restore > > IP address configuration (if it was modified, for example via > > iproute). > > > > > > You see, when a profile is activated on a device, the original > > settings > > were internally copied and those are "applied". And "nmcli device > > reapply" just updates the "applied" clone to be the current profile > > and > > does the changes. > > ok, so those details apart, > > - profile is applied or re-applied to a device > - connection is up-ed or activated > - profile is activated > - device is connected > > > are kind of synonymous ? Yes. > > Usually, NetworkManager (the daemon) does not automatically create > > connection profiles > > > But when it does (as in your cases), is it always only in RAM (unless > we > then save the profile to disk of course) ? Yes. But when you modify this profile, it usually gets persisted to disk. Except case 4). But there it's not really NetworkManager who creates the profile but nmcli/nm-applet. Such profiles to get persisted. > > Regarding "autoconnect", that is a property of the connection > > profile > > itself. > > So in a way, when a profile is autocreated and activated, it is > first > created with this property which make it then immediatly > (auto)connect, > correct ? Not necessarily. When NetworkManager creates a bluetooth pan profile (case 1)), this one will not be connected right away. Such a profile also has "connection.autoconnect=no". For the auto-default profiles (case 2, "Wired Connection #"), the purpose is to create a profile and activate it right away. Indeed, such a generated profile has "connection.autoconnect=yes". But it would work the same (and connect the profile) also with "connection.autoconnect=no". NM here (auto)creates the profile and goes ahead to activate it. I wouldn't call this behavior "autoconnect", but yes, kind of. > >- per-device: nmcli device set $DEVICE autoconnect no > > this confuses me since we just said autoconnection was a property of > a > profile and this command deals with a device ? The profile has a "connection.autoconnect" property. If it's "no", the profile never autoconnects. Period. But there also needs to be a device which is currently in a state where it would like to autoconnect a profile. With `nmcli device set "$DEVICE" autoconnect no" you can set that. for example, `nmcli device disconnect "$DEVICE"` will block autoconnect on the device. It would be pretty annoying, if you disconnect the device and immediatley some profile autoconnects again. > > "Autoconnect" prefers profiles which > > were active last > > Same remark here When a device wants to autoconnect a profile, there might be multiple profiles which are compatible candidtes. Then, the one is chosen with the best "connection.autoconnect-priority" or as last, the timestamp when the profile was activate the last time. > > > > If a device is unmanaged, NetworkManager does nothing with it. It > > won't > > autocreate a profile for it, and it won't autoactivate anything > > > Depending on the reasons why it's unmanaged, you still can let > > NetworkManager take over, either via > > > >nmcli device set $DEVICE managed yes > > > > or simply `nmcli con up` or `nmcli device connect`. > > My understanding is that a device is managed by default unless > explicitly set to unmanaged (via one of the several ways you > described) yes > Also, that profile autocreation works (when its not forbidden by > no-auto-default for instance) only on managed devices yes > So in your above example I don't understand how nmcli con up alone > or > nmcli device connect alone would actually create the profile without > the > device set managed
Re: NetworkManager behavior answers not found in docs
> > -> where is that magic described ? How does a simple connect > > CREATES > > a > > connection. Man states that connect looks for a matching EXISTING > > connection ? > > man nmcli: > >connect ifname >Connect the device. NetworkManager will try to find a > suitable connection that will be activated. It will also consider > connections that are not set to auto >connect. > > ok. It's not described. That's a documentation bug. Hi, fixed: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=1b732e28f7aafbbfb98748f6a873c98be361ef67 best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Tue, 2018-10-16 at 14:56 +0200, Thomas HUMMEL wrote: > I forgot : it seems to me that nmcli connection add also imply > "managed" > as in nmcli device set managed yes. > > Am I correct ? Then again when do we need those device commands > manipulation ? > I don't see that happening, and it shouldn't: $ nmcli device | grep ^eth0 eth0 ethernet disconnected -- $ nmcli connection add type ethernet con-name t ifname eth0 ipv4.addresses 192.168.10.5/24 ipv4.method manual ipv6.method ignore Connection 't' (deeb17f3-dd68-492a-b653-55800f9a3715) successfully added. $ nmcli device | grep ^eth0 eth0 ethernet connected t $ nmcli connection delete t Connection 't' (deeb17f3-dd68-492a-b653-55800f9a3715) successfully deleted. $ nmcli device set eth0 managed no $ nmcli device | grep ^eth0 eth0 ethernet unmanaged -- $ nmcli connection add type ethernet con-name t ifname eth0 ipv4.addresses 192.168.10.5/24 ipv4.method manual ipv6.method ignore Connection 't' (83fc7338-6897-4e2a-a4ec-1ecf396ccc68) successfully added. $ nmcli device | grep ^eth0 eth0 ethernet unmanaged -- that is, autoconnect does not kick in, because eth0 is unmanaged. If you however do $ nmcli device connect eth0 Device 'eth0' successfully activated with '83fc7338-6897-4e2a-a4ec-1ecf396ccc68'. or $ nmcli connection up t Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/12) then indeed, that implies a `nmcli device set eth0 managed yes`. But it didn't happen automatically. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager behavior answers not found in docs
On Tue, 2018-10-16 at 14:40 +0200, Thomas HUMMEL wrote:
Hi,
>
> I'm considering migrating from a CentOS 6 HPC cluster to CentOS 7
> one.
> For this purpose I've read quite a lot of doc (man, guides, ...)
> about
> systemctl and NetworkManager to be fluent in their use.
>
> Regarding NetworkManager, I've been at first confused by the induced
> complexity or number of possible mixed old way/native use cases
> brought
> by the "network-scripts" compatibility layer provided by the ifcfg-
> rh
> plugin.
The compatibility layer doesn't need to concern you much. With this,
- connection profiles are persisted as ifcfg-rh files
- `ifup`/`ifdown` delegates to calling `nmcli connection up`
but there is no reason to even care about that and you can ignore
initscripts entirely. For example, the ifcfg-rh file format (`man nm-
settings-ifcfg-rh`) would only concern you if you plan to edit these
file manually. Which is more cumbersome then just using nmcli.
> As a matter of fact, I experimented a lot to be sure of who did what
> and
> how or when between network-scripts and NetworkManager.
>
> Digging deeper, things got clearer. Still I'm not really sure about
> the
> points described below.
>
> Notes :
>
> - I'm running NetworkManager-1.10.2-16.el7_5.x86_64 on a CentOS
> Linux
> release 7.5.1804 (Core)
> - I'm using default settings, so this must be ifcfg-rh plugin first,
> then keyfile otherwise
> - I'm talking only about ethernet connections/devices here
>
>
> 1. /run/NetworkManager/devices directory
>
>
> I know NetworkManager exports connections as
> /org/freedesktop/NetworkManager/Settings/ D-Bus objets
>
> What exactly is under /run/NetworkManager/devices/ path ? UUID
> inside those files don't always match what nmcli shows me ?
This directory is the internal per-device state. It should not be
necessary to be concerned with it (also: it's not stable nor public
API!). That said:
- the number is the "ifindex" of the device, as known to kernel and
visible in `ip link` output. This is the only real identifier for a
networking device in linux, as the name and MAC address may change.
That is why we usually match a profile against a device via attributes
like "connection.interface-name" or "ethernet.mac-address". This
ifindex is not meaningful after reboot. And so are all files under /run
(on RHEL/Fedora/CentOS this is a tempfs mount and lost after reboot).
- when NetworkManager is stopped, it writes there some state for each
file. In particular, so that `systemctl restart NetworkManager` works
better, with possibly few changes. One usually wouldn't ever restart
NetworkManager daemon (unless having good reasons, like package
update), but when doing so, the aim is that connectivity is not
affected. Hence the state directory.
- NetworkManger may also slightly behave differently whether it is
started the first time (for the current boot) or after a `systemctl
restart NetworkManager`. You see that in the logfile with
NetworkManager (version ...) is starting... (after a restart)
and this is also determined based on the presence of this "devices" directory.
If you stop NetworkManager and delete the directory, NetworkManager will think
it starts first time after boot. Again, the difference again shouldn't matter
and you shouldn't rely on this.
> 2. device vs connection
>
>
> My understanding is that there's a clear distinction between a
> device
> and a connection. To be more precise, that an active connection is a
> set
> of settings (potentially persisted on disk on a connection file via
> some
> plugin) "applied" to a device. The applied part is not very clear to
> me :
I find the name "profile" clearer. But we often say "connection" or
"connection profile". Sometimes also "settings connection" to
distinguish it from "active connection".
An "active connection" is the data associate with the fact that a
connection profile. There is the "device" ("networking interface"), the
profile, and when you activate a profile on a device, you also have an
"active connection". The active connection is usually not directly
visible in nmcli, except with `nmcli -f ACTIVE-PATH connection show`.
And of course, the current activation state with `nmcli -f NAME,STATE
connection show`.
> What's the difference between connecting a device (nmcli device
> connect)
> and activating a connection (nmcli connection up) ? Maybe my
> confusion
> comes from the fact that adding a connection automatically connects
> it
> to a device ?
There is little difference
- `nmcli connection up "$PROFILE"` will find a suitable device
automatically.
- `nmcli device connect "$DEVICE"` will find a suitable connection
automatically. Note this may create a new profile (see later).
- `nmcli connection up "$PROFILE" ifname "$DEVICE" explicitly selects
both the profile and the device.
As the profile contains the necessary settings for what to do with the
device, you cannot ~configure~ a device without a
Re: [RFC] Automatically remove stored SIM-PIN from gsm connection settings if it fails to unlock?
On Mon, 2018-10-08 at 09:24 +0200, Aleksander Morgado wrote: > Hey, > > I've SIM-PIN blocked one of my SIM cards just by having a gsm > autoconnected settings with a PIN stored and then PIN not matching > the > one in the device. When this happens, NM will try to unlock SIM-PIN > once, and if it fails it won't try again (good) (*)... until the next > reboot (bad). So, I forgot about this setup and after just a couple > of > system reboots got the SIM-PIN blocked, and had to recover it with > the > PUK. > > Don't know if this kind of thing is done in other kinds of settings, > but could we completely remove the SIM-PIN stored within the settings > if it fails once, so that not even on the next reboot the unlock with > the wrong PIN is attempted? Or is this considered a user error? I'm > not exactly sure where to draw the line about this issue, I think I > have pros and cons for both solutions, so just opening the question > here. > > What do you think? > > (*) It also doesn't re-ask the user for the PIN right away, still > need > to get trace logs as thaller suggested. Hi, That sounds good to me. it's slightly ugly, that activating a profile may result in writing it anew to disk. But we already do that when (for example with Wi-Fi), when the password is wrong and we get a better password from the secret agent. While a bit odd that activating a profile may re-write it, it probably makes sense. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: unsecured networks
On Wed, 2018-10-03 at 20:19 +0200, live--- via networkmanager-list wrote: > Hello NM-community, > > > firth of all: thank you for this feature-rich networking tool, so far > did it never missed my needs! > > > However did I run into huge problems since I am working on changing > locations and need to connect into unsecured wifi-networks that use a > web-based login-page (sometimes you have to enter a username and > password sometimes you just need to press a bottom to confirm to the > Terms of Usage). In any way, I can login to those networks to the > firth time and use it without any problems. But after some time I got > disconnected or turned off the laptop and from this moment on was I > complete unable to connect to those networks again. Even the "forget > network" function inside the history doesn't changed anything. Can > this be related to that I use '''wifi.cloned-mac-address=random''' to > randomly change my mac-addresses on every new connection? > Hi, it is quite possible that such a login-page (captive portal) would recognize you base on the MAC address. So, if you change the MAC address, you would need to re-authenticate. If you subsequently fail to re-authenticate, then it's unclear why the login-page would be have that way. Maybe it stores a cookie in your browser and does not like you changing the MAC address? That seems a bit unusual though. I wouldn't expect that deleting and re-creating the connection profile in NetworkManager would help here. Note there is "wifi.cloned-mac-address=stable" which precisely exists to give you a scrambled MAC address but also control of when it changes. The "stable" goes together with "connection.stable-id", see `man nm-settings` and [1]. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/nm-conf.d/30-anon.conf#n31 best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] core: fix typo in comment
On Mon, 2018-10-01 at 09:54 +0200, Frédéric Danis via networkmanager- list wrote: > Not refering to the right function > --- Hi, merged to master as https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=995ff778ce075e66b69c39db124a640043ff9c9d Thanks! Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IPv6 Prefix Delegation through Network Manager
Hi, in the log [1538019154.6638] policy: ipv6-pd: enp5s0 needs a subnet [1538019154.6638] policy: ipv6-pd: no device to obtain a subnet to share on enp5s0 from ... [1538019154.6719] policy: ipv6-pd: none of 0 prefixes of enp2s0 can be shared on enp5s0 [1538019154.6719] device (enp2s0): ipv6-pd: device doesn't use DHCPv6, can't request prefixes ... [1538019158.9088] ndisc[0x561734e850e0,"enp2s0"]: neighbor discovery configuration changed [dGR]: [1538019158.9088] ndisc[0x561734e850e0,"enp2s0"]: dhcp-level managed ... [1538019158.9359] dhcp6 (enp2s0): dhclient started with pid 6501 ... It seems there is a bug. At the moment when enp5s0 required a prefix, it wasn't available. And later on, when enp2s0 did DHCPv6, it wrongly wasn't retried to share a prefix. What to do about that, and how to fix is, that is a good question... best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: No new PIN request to the user if PIN stored in settings is wrong
On Thu, 2018-09-27 at 11:51 +0200, Aleksander Morgado wrote: > Hey, > > I'm trying to understand whether this behavior is on purpose or not. > > I have some "gsm" settings for a broadband connection, and the > settings have a PIN stored. I then try to use those settings on a > modem device but the expected PIN in the modem is a different one, so > the connection attempt fails with a "sim-pin-incorrect" reason. At > this point NetworkManager doesn't request the user new secrets for > this connection after finding that the stored ones are wrong; i.e. i > don't see any popup window in the shell asking to enter PIN. The > connection attempt just fails and we do get reported in the UI about > the failed attempt. > > Is this behavior (asking the user for PIN after a "sim-pin-incorrect" > failure) not implemented or am I missing some reason that would > prevent doing that? The behavior is different e.g. with WiFi; if I > change the key in my router and I request NM to connect to the WiFi > network, the authentication failure triggers a new request for > secrets > to the user. > > Cheers! Hi, sounds like a bug. If a secret/pin is wrong, NM should re-ask for it. Do you have a level=TRACE log? best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Can't map keyfile path to /home/* directory
On Tue, 2018-09-25 at 17:50 -0400, Jackson Wiegman via networkmanager- list wrote: > Hi > > [testing this on a system with 1.2.6] > > I have a setup that (will be) a read-only root file system with RW > /home directory. To allow for network changes, I have mapped the > keyfile path in NetworkManager.conf to /home. However when I do this > I get an error when trying save a connection (nmcli connection add > gives me No plugin supported adding this connection, connection edit > / save gives me read-only file system). If I map keyfile path to > anywhere but /home, such as /tmp or /etc/TEST it works fine. > > Any idea why this won't work with any subdirectories in the /home > folder? > Hi, /usr/lib/systemd/system/NetworkManager.service contains: ProtectHome=read-only See `man systemd.exec`. You may change that via $ systemctl edit NetworkManager.service but a better idea would be to choose a directory like /var/lib/NetworkManager, which is required to be read-write and persisted. Also, because NetworkManager is a system daemon and has no business with your home directory. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] core: fix route metric set to -1 on DHCP renewal
Hi, merged to master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=7d155757b195274c8ebac1b50d16332a5b7c91ec nm-1-14: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=474cf750548d2702925600bdb2be617f3b6525ff Thanks!! best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.12.4 and 1.10.12 released
Hello, yesterday new minor releases 1.12.4 and 1.10.12 of NetworkManager were done [1] [2]. Find the tarballs at our usual location: https://download.gnome.org/sources/NetworkManager/ They only contain bugfixes and a few translation updates. They are only backports from master and nm-1-12 branch, respectively. Maybe the most important fix is for a crash during connectivity checking on 1.12.4 (not affecting 1.10.x) [3]. best, Thomas [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=1.12.4 [2] https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=1.10.12 [3] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=3dbd264418f235dd11e7802ae6f3970734653ab8 signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nmcli and cdc-wdm0 device for UMTS connection
On Tue, 2018-09-18 at 14:02 +0200, Giovanni Parodi via networkmanager- list wrote: > Hello everybody, > I have a problem connecting to a UMTS network on an embedded system. > Here are the details: > - Modem Quectel UC20 > - packages installed: usbutils, usb_modeswitch, NetworkManager > (1.0.4), ModemManager (1.4.2). > > To activate network connection, I work as follows: > > // Start ModemManager with log debug > ModemManager --debug & > > // Enable modem > mmcli -m 0 -e > > // Start NetworkManager > NetworkManager & > > // cdc-wdm0 is the primary port oc the modem, look at the > following text. > nmcli c add type gsm ifname cdc-wdm0 con-name remoteConnection > apn ibox.tim.it > > // By this command I'm able to verify that the modem is > registered to the network > mmcli -m 0 -w > > Output is > /org/freedesktop/ModemManager1/Modem/0: Initial state, > 'registered > > The output of the command > mmcli -m 0 > is: > > /org/freedesktop/ModemManager1/Modem/0 (device id > 'fdecd6b32808f6d001a07e35d54ac8635ac19228') > - > Hardware | manufacturer: 'QUALCOMM INCORPORATED' >| model: '0' >| revision: 'UC20EQAR03A04M1024 1 [2014/05/05 > 9:00:00]' >| supported: 'gsm-umts' >|current: 'gsm-umts' >| equipment id: '861075021304068' > - > System | device: '/sys/devices/soc0/soc/210.aips- > bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1.2' >|drivers: 'option1, qmi_wwan' >| plugin: 'Generic' >| primary port: 'cdc-wdm0' >| ports: 'ttyUSB0 (qcdm), ttyUSB2 (at), cdc-wdm0 > (qmi), wwan0 (net), ttyUSB3 (at)' > - > Numbers | own : 'unknown' > - > Status | lock: 'sim-pin2' >| unlock retries: 'sim-pin (3), sim-pin2 (3), sim-puk > (10), sim-puk2 (10)' >| state: 'registered' >|power state: 'on' >|access tech: 'umts' >| signal quality: '36' (recent) > - > Modes| supported: 'allowed: 2g; preferred: none >| allowed: 3g; preferred: none >| allowed: 2g, 3g; preferred: none >| allowed: 2g, 3g; preferred: 2g >| allowed: 2g, 3g; preferred: 3g' >|current: 'allowed: 2g, 3g; preferred: none' > - > Bands| supported: 'cdma-bc15-aws, dcs, egsm, pcs, g850, > u2100, u900' >|current: 'cdma-bc15-aws, dcs, egsm, pcs, g850, > u2100, u900' > - > IP | supported: 'ipv4, ipv6, ipv4v6' > - > 3GPP | imei: '861075021304068' >| enabled locks: 'none' >|operator id: '22201' >| operator name: 'TIM' >| subscription: 'unknown' >| registration: 'home' > - > SIM | path: '/org/freedesktop/ModemManager1/SIM/0' > > - > Bearers | paths: 'none' > > > So, once again, it seems the modem is registered. > However the output of the command > nmcli con > is as follows: > > NAME UUID TYPE > DEVICE > remoteConnection 3c1a500d-fc67-4523-9ba9-6973249a859a gsm > -- > > So it seems that the remoteConnection is not associated with any > device (I think that the device should be cdc-wdm0). > > The output of > nmcli dev > is: > > DEVICE TYPE STATE CONNECTION > can0 can disconnected -- > can1 can disconnected -- > tunl0ipip disconnected -- > wlan0wifi disconnected -- > wwan0wwan disconnected -- > bond0bond unmanaged -- > eth0 ethernet unmanaged -- > gre0 gre unmanaged -- > gretap0 gretapunmanaged -- > lo loopback unmanaged -- > > And running the command > nmcli con up remoteConnection > I get the error: > Error: Connection activation failed: No suitable device found > for this connection Hi, in the output of `nmcli device` there is no device named "cdc-wdm0". It seems, to NetworkManager, the device is called differently. Since there is only one wwan typed device, the name seems to be "wwan0"? Also, you don't need to restrict the profile to a device by name, if that doesn't suit you. Just specify an empty name. best, Thomas > > I'm working on an embedded device without gui, and the SW version are > the following ones: >nmcli version 1.0.4 > mmcli version 1.4.2 > I'm not
Re: [PATCH] ppp-manager: fix pppd not exiting correctly on modem hangup
On Tue, 2018-09-11 at 18:56 +0200, Frederic Danis wrote: > When unplugging an USB 3G modem device, pppd does not exit correctly > and > we have the following traces: Hi Frederic, good catch. Thank you for the patch. Merged to master: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e66e4d0e718b0f9102160e98fb6a1bf059677d71 nm-1-14: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=b3ca8abe3810af3eda85d446b6c45dd96d820489 nm-1-12: https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=3392c439582b4ba5da19423fbaeed5843aeae9a9 best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
ANN: NetworkManager 1.13.90 (1.14-rc1) released
Hello, I am happy to announce that we just released the first release- candidate for upcoming 1.14.0 NetworkManager. If all goes according to plan, the stable 1.14.0 release will already happen next Friday, 14th Sepember 2018. Find the preliminary NEWS file here: https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?id=1.14-rc1 and the release tarball at our usual location https://download.gnome.org/sources/NetworkManager/ https://download.gnome.org/sources/NetworkManager/1.13/NetworkManager-1.13.90.tar.xz Thanks to everybody who contributed to this release. Testing and feedback is appreciated. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IPv6 Prefix Delegation through Network Manager
On Wed, 2018-09-05 at 19:50 -0500, dag dg via networkmanager-list wrote: > Thanks Thomas. Going into debug was able to point me in the right > direction. For those stumbling on this like myself, the > "ipv6.method=shared" refers to your *LAN* interface, not your WAN > interface. While this might seem intuitive to some, when I think > "shared" I think of the WAN though that is mostly a holdover from > IPv4 > conventions. > > In an earlier fit of desperation I had tried setting the LAN > interface > to "shared", but at the time ipv6 ICMP was unintentionally blocked by > the firewall which was preventing the negotiation with my ISP from > happening. I eventually figured it out that it was the firewall when > I > switched to wide-dhcpv6 using the known working config I had used > with > my old router, but I never went back to try setting the LAN interface > to shared. > > After switching to debug I was able to see that the errors hinted at > NM trying to find an interface(device) other than my WAN to assign a > range to. The informational level message "no device to obtain a > subnet to share on from" sort of gives this away but by > itself can appear a bit cryptic, especially if like me you don't > fully > understand how ipv6 works. > > I think it would really help out if the documentation had a smidgen > more detail, even if it was just a "for example if you are > configuring > a router for prefix delegation you would want to set your > LAN/local/whatever interface to shared mode". Maybe it's already > supposed to appear obvious but I definitely missed it, for what it's > worth. > > Thanks again Thomas and thanks Vladimir; your earlier post was what > made me aware Network Manager began supporting prefix delegation in > the first place. Hi, I added a comment about that in `man nm-settings` [1], but it's unclear that this is sufficiently discoverable. But it's also unclear where else to document it. Regarding firewall, at least for ipv4.method=shared, NetworkManager adds some iptables rules to enable NAT [2]. This has room for improvement. Possibly firewalld should be informed about the sharing and it's up to firewalld to do the right thing. Todo. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=e90e1536c91678dcf34ab496aa750598052e1143 [2] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices/nm-device.c?id=e90e1536c91678dcf34ab496aa750598052e1143#n10068 So, after all you got it working?? Cool!! best, Thomas > > ~dag > On Wed, Sep 5, 2018 at 8:11 AM Thomas Haller > wrote: > > > > On Tue, 2018-09-04 at 09:29 -0500, dag dg via networkmanager-list > > wrote: > > > > > > There doesn't seem to be much documentation for Network Manager > > > on > > > the > > > prefix delegation support. Any insight would be appreciated. > > > > Hi, > > > > > > it's not much documented, because there isn't much to configure > > about > > ipv6.method=shared. It's supposed to just work -- except when it > > doesn't. > > > > Could you provide a full logfile with level=TRACE enabled? > > > > See the hints about logging at > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf > > > > > > best, > > Thomas > > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IPv6 Prefix Delegation through Network Manager
On Tue, 2018-09-04 at 09:29 -0500, dag dg via networkmanager-list wrote: > > There doesn't seem to be much documentation for Network Manager on > the > prefix delegation support. Any insight would be appreciated. Hi, it's not much documented, because there isn't much to configure about ipv6.method=shared. It's supposed to just work -- except when it doesn't. Could you provide a full logfile with level=TRACE enabled? See the hints about logging at https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: wifi permanently switching between 2.4 and 5 GHz
Hi, On Wed, 2018-08-15 at 23:23 +0200, Shawn Adams wrote: > For general roaming, I think it would be great for NM expose the > bgscan and related configs, On Mon, 2018-08-27 at 20:21 -0700, Michael Butash wrote: > It would be nice if this were adjustable in NM ui [...] I am not sure we need more configuration options. If we become aware of a better behavior, then NetworkManager and wpa_andsupplicant should just do it out of the box. At most there should be very generic settings to let the user choose between "low-latancy" vs. "powersave". But such a setting "wifi.powersave" already exists. Of course, user's testing and feedback is very valuable, to understand how to improve (thanks!!). best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Setting MACADDR with nmcli
Hi, On Wed, 2018-08-08 at 08:24 -0400, Robert Moskowitz wrote: > On 08/07/2018 09:07 AM, Thomas Haller wrote: > > On Tue, 2018-08-07 at 08:43 -0400, Robert Moskowitz wrote: > > > I hope this is the right list for nmcli. > > > > > > I want to set MACADDR in ifcfg-eth0 > > > > > > I thought it was: > > > > > > nmcli con mod eth0 mac "02:67:15:00:81:0B" > > > > > > but this sets HWADDR, which has a totally different use. I could > > > then > > > change HWADDR to MACADDR with: > > > > > > sed -i -e "s/HWADDR/MACADDR/w /dev/stdout" > > > /etc/sysconfig/network-scripts/ifcfg-eth0 > > > > > > But that is a hack. It would be nice to be able to directly set > > > MACADDR, but I cannot find any documentation that states how to > > > do > > > this. > > > > > > thanks > > > > > > > Hi, > > > > $ nmcli connection modify "$PROFILE" ethernet.cloned-mac-address > > "$MAC" > > I wonder what the history of naming this object 'cloned' mac > address? > Perhaps because we were cloning the address of the broken card for > the > new card so the licensed software would work? :) Historical reasons. I agree, the name is suboptimal. But changing it now, would be too much hazzle. > I did that a lot in my early days with 3com cards and VAX ethernet > adapters. > > Now we use it for ARM boards (and others) that come without a MAC > address and the uboot or OS has to invent some local scope address. Oh, btw, you might like setting it to "stable". The property can also be configured with a system-wide default value (see `man NetworkManager.conf`). That is, drop a file /etc/NetworkManager/conf.d/90-mac-addr.conf with [connection-mac-addr] ethernet.cloned-mac-address=stable and it will be used by default in all profiles (which don't specify the cloned-mac-address option explicitly). If you'd like some details, see `man nm-settings` or [1]. [1] https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/ > > Theoretically, this is documented in `man nm-settings`. However, > > the > > manual is generated and for cloned-mac-address the > > generated documentation is confusing. It's confusing, because `man > > nm- > > settings` is undecided whether it documents libnm GObject > > properties or > > D-bus API. Especially, since you care about nmcli syntax. In most > > cases, there is little difference between libnm API, D-Bus API and > > nmcli, so "nm-settings" manual does apply. For "cloned-mac-address" > > it's different. > > > > And as you seem concerned about ifcfg files, see also > > `man nm-settings-ifcfg-rh`. But usually, you would not concern > > yourself > > with the details of ifcfg files. > > You do for ARM based servers. No GUI typically. Fixed IP > addressing > and the like and a predictable MAC addr. Sometimes the uboot is > consistent for a given board on how it computes the MAC address. Of > course a new version of uboot may compute it differently. > > So perhaps there is a more modern method than using ifcfg files for > servers. I have not encountered it. I have at least switched from > hand > coding my ifcfg to using nmcli in scripts. The modern way is NetworkManager ;-) > > > If you look at `man nmcli` it has a table: > > > > PROPERTY ALIASES > > > > Table 3. Wired Ethernet options > > ┌───┬──┐ > > │Alias │ Property │ > > ├───┼──┤ > > │mtu│ wired.mtu│ > > ├───┼──┤ > > │mac│ wired.mac-address│ > > ├───┼──┤ > > │cloned-mac │ wired.cloned-mac-address │ > > └───┴──┘ > > And you have to realize that mac maps to HWADDR to link the ifcfg to > a > specific card. While cloned-mac maps to MACADDR to set the MAC > address > actually used for an interface. I had to read a lot to tease that > distinction out. The details of ifcfg syntax, are only relevant if you want to switch between NetworkManager and initscripts, and use the same ifcfg files in both setups. If you use NetworkManager exclusively, it is not necessary to concern yourself with ifcfg syntax. For $MACADDR variable, this is relatively straight forward. But how $IPV6INIT, $IPV6FORWARDING, $IPV6_AUTOCONF, and $DHCPV6C work together to result in ipv6.method setting, is far from obvious. It's less error- prone to just set ipv6.method via nmcli. But if you want to pre-deploy profiles and copy them around, you are indeed concerned with the files. Sure, that works. Maybe you'd want to use keyfiles for that however. best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager and SLAAC
Hi, On Tue, 2018-08-07 at 14:33 -0500, Lesley Kimmel wrote: > > I'm looking for a way to globally disable SLAAC when using > NetworkManager on RHEL-based systems. > > I am able to disable SLAAC on a pre-interface basis by adding > IPV6_AUTOCONF=no to the relevant interface configuration file. > However, I cannot find a way to make this setting in a generic way > that would apply to all current and future interfaces. > > Any thoughts? I don't think there is a reasonably easy solution for this. Your question is about the ipv6.method option. The ipv6.method is configured per-profile. There is no global setting that affects all profiles. Can you not adjust all the profiles to your liking? for UUID in $(nmcli -g UUID connection); do nmcli connection modify uuid $UUID ipv6.method link-local done Also note, that (almost) all profiles are created by a client application. For example a user clicking in nm-connection-editor, or a script calling nmcli. The settings of future profiles will be determined by these clients. For example, if you want that future profiles don't use SLAAC, don't create them as such. They are (usually) not created by NetworkManager itself. Note, that for some reasons, nobody implemented a ipv6.method=disabled option. So, while you can disable SLAAC per-profile (with methods "ignore", "link-local" or "manual"), "disabled" is not implemented yet. best, Thomas PS: you are welcome to look at ifcfg files and edit them. However, the relevant part is how NetworkManager interprets the file. Looking at IPV6_AUTOCONF variable only makes it more complicated. What matters in the end is the ipv6.method option (as visible in `nmcli connection show "$PROFILE"`). signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Setting MACADDR with nmcli
On Tue, 2018-08-07 at 08:43 -0400, Robert Moskowitz wrote: > I hope this is the right list for nmcli. > > I want to set MACADDR in ifcfg-eth0 > > I thought it was: > > nmcli con mod eth0 mac "02:67:15:00:81:0B" > > but this sets HWADDR, which has a totally different use. I could > then > change HWADDR to MACADDR with: > > sed -i -e "s/HWADDR/MACADDR/w /dev/stdout" > /etc/sysconfig/network-scripts/ifcfg-eth0 > > But that is a hack. It would be nice to be able to directly set > MACADDR, but I cannot find any documentation that states how to do > this. > > thanks > Hi, $ nmcli connection modify "$PROFILE" ethernet.cloned-mac-address "$MAC" Theoretically, this is documented in `man nm-settings`. However, the manual is generated and for cloned-mac-address the generated documentation is confusing. It's confusing, because `man nm- settings` is undecided whether it documents libnm GObject properties or D-bus API. Especially, since you care about nmcli syntax. In most cases, there is little difference between libnm API, D-Bus API and nmcli, so "nm-settings" manual does apply. For "cloned-mac-address" it's different. And as you seem concerned about ifcfg files, see also `man nm-settings-ifcfg-rh`. But usually, you would not concern yourself with the details of ifcfg files. If you look at `man nmcli` it has a table: PROPERTY ALIASES Table 3. Wired Ethernet options ┌───┬──┐ │Alias │ Property │ ├───┼──┤ │mtu│ wired.mtu│ ├───┼──┤ │mac│ wired.mac-address│ ├───┼──┤ │cloned-mac │ wired.cloned-mac-address │ └───┴──┘ best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager, n-acd and GPLv2 license compatibility
Hi David, Tom, nm-list, Since version 1.11.2-dev, NetworkManager uses n-acd library [1] for IPv4 address collision detection. We imported commit [2] to NetworkManager's source tree in April 2018 [3]. NetworkManager daemon is licensed GPLv2+, while n-acd at that time was licensed Apache License 2.0. That means, the combination was only redistributable under the terms of GPLv3, which is undesirable for us. This in particular affects NetworkManager releases 1.12.0 and 1.12.2. In the meantime, David Herrmann and Tom Gundersen were very forthcoming and dual-licensed n-acd under APL2 and LGPL2.1+ [4]. We hereby ask David and Tom to retroactively agree using the older n- acd commit a68b55992dd7b38bdb9dbbdba4a9284ff2c2cce3 [2] under terms of GPLv2+, to resolve this licensing issue for NetworkManager. Thanks, Thomas Haller [1] https://github.com/nettools/n-acd [2] https://github.com/nettools/n-acd/commit/a68b55992dd7b38bdb9dbbdba4a9284ff2c2cce3 [3] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=8a01bdc2d1e5af7f97afc8eb4b9db9d7e18b0e52 [4] https://github.com/nettools/n-acd/commit/4e6a169a0eb705ff1abe962b8cba0f19d375cd60 signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: networkmanager-applet
On Tue, 2018-07-31 at 10:33 +0300, Cristian Crinteanu wrote: > can't build networkmanager-applet 1.8.14 with headers of > networkmanager 1.12.2 > > + make -O -j4 > GEN src/libnm-gtk/nm-resources.c > GEN src/libnm-gtk/nm-resources.h > GEN src/wireless-security/ws-resources.h > GEN src/wireless-security/ws-resources.c > CC src/libnma/src_libnma_libnma_la-nma-vpn-password-dialog.lo > In file included from /usr/include/libnm/NetworkManager.h:46:0, > from ./shared/nm-default.h:75, > from src/libnma/nma-vpn-password-dialog.c:26: > /usr/include/libnm/nm-device-ovs-port.h:45:1: error: macro > "G_UNAVAILABLE" passed 3 arguments, but takes just 2 > NM_AVAILABLE_IN_1_12_2 > ^~ > /usr/include/libnm/nm-device-ovs-port.h:46:1: error: expected ‘=’, > ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘const’ > const GPtrArray *nm_device_ovs_port_get_slaves (NMDeviceOvsPort > *device); > ^ > In file included from /usr/include/libnm/NetworkManager.h:47:0, > from ./shared/nm-default.h:75, > from src/libnma/nma-vpn-password-dialog.c:26: > /usr/include/libnm/nm-device-ovs-bridge.h:45:1: error: macro > "G_UNAVAILABLE" passed 3 arguments, but takes just 2 > NM_AVAILABLE_IN_1_12_2 > ^~ > /usr/include/libnm/nm-device-ovs-bridge.h:46:1: error: expected ‘=’, > ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘const’ > const GPtrArray *nm_device_ovs_bridge_get_slaves (NMDeviceOvsBridge > *device); > ^ > make: *** [Makefile:2676: src/libnma/src_libnma_libnma_la-nma-vpn- > password-dialog.lo] Error 1 > make: *** Waiting for unfinished jobs > CC src/libnma/src_libnma_libnma_la-nma-mobile-providers.lo > In file included from /usr/include/libnm/NetworkManager.h:46:0, > from ./shared/nm-default.h:75, > from src/libnma/nma-mobile-providers.c:25: > /usr/include/libnm/nm-device-ovs-port.h:45:1: error: macro > "G_UNAVAILABLE" passed 3 arguments, but takes just 2 > NM_AVAILABLE_IN_1_12_2 > ^~ > /usr/include/libnm/nm-device-ovs-port.h:46:1: error: expected ‘=’, > ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘const’ > const GPtrArray *nm_device_ovs_port_get_slaves (NMDeviceOvsPort > *device); > ^ > In file included from /usr/include/libnm/NetworkManager.h:47:0, > from ./shared/nm-default.h:75, > from src/libnma/nma-mobile-providers.c:25: > /usr/include/libnm/nm-device-ovs-bridge.h:45:1: error: macro > "G_UNAVAILABLE" passed 3 arguments, but takes just 2 > NM_AVAILABLE_IN_1_12_2 > ^~ > /usr/include/libnm/nm-device-ovs-bridge.h:46:1: error: expected ‘=’, > ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘const’ > const GPtrArray *nm_device_ovs_bridge_get_slaves (NMDeviceOvsBridge > *device); > ^ > make: *** [Makefile:2669: src/libnma/src_libnma_libnma_la-nma-mobile- > providers.lo] Error 1 > CC src/libnma/src_libnma_libnma_la-nma-mobile-wizard.lo > In file included from /usr/include/libnm/NetworkManager.h:46:0, > from ./shared/nm-default.h:75, > from src/libnma/nma-mobile-wizard.c:23: > /usr/include/libnm/nm-device-ovs-port.h:45:1: error: macro > "G_UNAVAILABLE" passed 3 arguments, but takes just 2 > NM_AVAILABLE_IN_1_12_2 > ^~ > /usr/include/libnm/nm-device-ovs-port.h:46:1: error: expected ‘=’, > ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘const’ > const GPtrArray *nm_device_ovs_port_get_slaves (NMDeviceOvsPort > *device); > ^ > In file included from /usr/include/libnm/NetworkManager.h:47:0, > from ./shared/nm-default.h:75, > from src/libnma/nma-mobile-wizard.c:23: > /usr/include/libnm/nm-device-ovs-bridge.h:45:1: error: macro > "G_UNAVAILABLE" passed 3 arguments, but takes just 2 > NM_AVAILABLE_IN_1_12_2 > ^~ > /usr/include/libnm/nm-device-ovs-bridge.h:46:1: error: expected ‘=’, > ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘const’ > const GPtrArray *nm_device_ovs_bridge_get_slaves (NMDeviceOvsBridge > *device); > ^ > make: *** [Makefile:2662: src/libnma/src_libnma_libnma_la-nma-mobile- > wizard.lo] Error 1 > CC src/libnma/src_libnma_libnma_la-nma-wifi-dialog.lo > In file included from /usr/include/libnm/NetworkManager.h:46:0, > from ./shared/nm-default.h:75, > from src/libnma/nma-wifi-dialog.c:23: > /usr/include/libnm/nm-device-ovs-port.h:45:1: error: macro > "G_UNAVAILABLE" passed 3 arguments, but takes just 2 > NM_AVAILABLE_IN_1_12_2 > ^~ > /usr/include/libnm/nm-device-ovs-port.h:46:1: error: expected ‘=’, > ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘const’ > const GPtrArray *nm_device_ovs_port_get_slaves (NMDeviceOvsPort > *device); > ^ > In file included from /usr/include/libnm/NetworkManager.h:47:0, > from ./shared/nm-default.h:75, > from
Re: Broken Cross Compile with NetworkManager 1.12.0
On Wed, 2018-07-25 at 19:09 +, Matthew Starr wrote: > I am trying to compile NetworkManager 1.12.0 for armhf using an amd64 > install of Ubuntu 17.10 and building the ARM software using > buildroot. During the configure step, I am getting the following > error: > > checking for /etc/sysconfig/network-scripts... configure: error: > cannot check for file existence when cross compiling > > This was not an issue with NetworkManager 1.10.8 which compiles fine > with the same build environment. > > I did some digging and it looks like the use of AC_CHECK_FILE in the > configure.ac file will cause cross compile errors like this. See the > following mailing list entry from autotools: > https://lists.gnu.org/archive/html/autoconf/2000-10/msg00018.html > > Best regards, > Matthew Starr > hi, if you look at configure.ac, you'll see AS_IF([test -z "$enable_ifcfg_rh"], AC_CHECK_FILE(/etc/sysconfig/network-scripts, enable_ifcfg_rh=yes)) meaning, you should be able to workaround this issue, by `./configure --disable-ifcfg-rh` ... and possibly --disable-ifupdown best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Change of route metric are not well propagated for default route
On Wed, 2018-07-18 at 23:18 +0200, Thomas Haller via networkmanager- list wrote: > > In 1.8, NetworkManager treated the default-route specially, and then > reapply (`nmcli device modify`) worked correctly to change the metric > of the default-route. > > With 1.10, NetworkManager's handling of routes was significantly > reworked. I actually would expect, that the bug was introduced > already > in 1.10.0, as side effect of the rework. Since you say, it worked in > 1.10, I am a bit surprised. > Anyway, clearly there is a misbehavior in 1.12.0. Ah, seems the issue was introduced by commit [1], which is 1.12.0. So, it makes sense that you say, > This works perfectly fine with NetworkManager 1.10.10 and I ended up > with a routing table like this one: [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=f4cbed3d4ff4e91e83f42c63b3602efa014ed72f best, Thomas signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Change of route metric are not well propagated for default route
On Wed, 2018-07-18 at 07:30 +, Frederic Martinsons wrote: > Hello guys, > > I would like to change route metric on a device without reactivated > its connection profile. For example, with nmcli, to change the metric > from 100 to 800, I do the following: > > nmcli device modify eth0 ipv4.route-metric 800 > > This works perfectly fine with NetworkManager 1.10.10 and I ended > up with a routing table like this one: > > default via 10.30.1.254 dev eth0 proto static metric 800 > 10.30.0.0/16 dev eth0 proto kernel scope link src 10.30.38.49 metric > 800 > > But this doesn't work with NetworkManager 1.12.0 and only the route > metric to reach subnet is changed (the one to reach the gateway is > not changed): > > default via 10.30.1.254 dev eth0 proto static metric 100 > 10.30.0.0/16 dev eth0 proto kernel scope link src 10.30.38.60 metric > 800 > > Moreover, always with NM 1.12, if I configured my device with a > manual IP (ip4.method=manual), the metric change is also correctly > propagated to all route that implies the device. > > I've raised the logging level of NetworkManager but I did'nt manage > to know why the default route is not changed when dhcp setup is > involved. I join two log files (one in dhcp and one in manual) to > emphasize the moment I execute the nmcli command. > > Can you guys please help me or give me some advice to solve this ? > > Note: I use internal dhcp client in the NetworkManager conf. Hi, I think what you see here is a bug. It has the effect, that nmcli device modify "$IF" ipv4.route-metric "$VALUE" and nmcli connection modify "$PROFILE" ipv4.route-metric "$VALUE" nmcli device reapply "$IF" don't work correctly to change the default-route. I think this issue is also tracked as [1]. In 1.8, NetworkManager treated the default-route specially, and then reapply (`nmcli device modify`) worked correctly to change the metric of the default-route. With 1.10, NetworkManager's handling of routes was significantly reworked. I actually would expect, that the bug was introduced already in 1.10.0, as side effect of the rework. Since you say, it worked in 1.10, I am a bit surprised. Anyway, clearly there is a misbehavior in 1.12.0. TODO. Sorry for the incovenience. best, Thomas [1] https://bugzilla.redhat.com/show_bug.cgi?id=1528071#c4 signature.asc Description: This is a digitally signed message part ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
