Commit Graph

82 Commits

Author SHA1 Message Date
Thomas Haller
1df7ed0cbe release: update NEWS 2018-09-07 14:50:12 +02:00
Thomas Haller
61976d2c20 release: update NEWS 2018-08-13 09:59:33 +02:00
Thomas Haller
16389f1037 core: implement connection.multi-connect to activate profiles multiple times
Make use of the new property, and implement it.

See previous commits for the reasons why.

https://bugzilla.redhat.com/show_bug.cgi?id=1555012
2018-08-08 11:24:29 +02:00
Thomas Haller
b26efa5b68 libnm: fix missing symbols in libnm ABI
Also backport the ABI to 1.12.2 (and thus, don't bother
initially adding the API as libnm_1_14_0).
2018-06-30 12:29:35 +02:00
Thomas Haller
cbeb34d355 release: bump version to 1.13.1-dev after 1.12.0 release
After 1.12.0 is released, merge it back into master so that
1.12.0 is part of the history of master. That means,
  $ git log --first-parent master
will also traverse 1.12.0 and 1.12-rc*.

Also bump the micro version to 1.13.1-dev to indicate that this is
after 1.12.0 is out.
2018-06-29 18:06:13 +02:00
Thomas Haller
db8696f164 release: update NEWS 2018-06-29 17:01:42 +02:00
Thomas Haller
e0dc1da411 release: fix NEWS entry for NM_DISPATCHER_ACTION
This was not backported to nm-1-10 branch.
2018-06-29 17:01:42 +02:00
Lubomir Rintel
09d296a1a2 NEWS: add an entry for WPAN & 6LowPAN support 2018-06-26 16:21:55 +02:00
Thomas Haller
2800232bbf dispatcher: add NM_DISPATCHER_ACTION environment variable
Previously, the action was only passed as the first command line
argument to the dispatcher scripts. Now, also set it via the
"$NM_DISPATCHER_ACTION" environment variable.

The main purpose is to have a particular, nm-dispatcher specific
variable that is always set inside the dispatcher scripts.
For example, imagine you have a script that can be either called by
dispatcher or some other means (manually, or spawned via
/etc/NetworkManager/dispatcher.d/11-dhclient).  Then it might make
sense to differenciate from inside the script whether you are called
by nm-dispatcher. But previously, there was no specific environment
variable that was always set inside the dispatcher event. For example,
with the "hostname" action there are no other environment variables.

Now (with version 1.12), you can check for `test -n "$NM_DISPATCHER_ACTION"`.

(cherry picked from commit ce9619047c)
2018-06-18 14:19:16 +02:00
Thomas Haller
ce9619047c dispatcher: add NM_DISPATCHER_ACTION environment variable
Previously, the action was only passed as the first command line
argument to the dispatcher scripts. Now, also set it via the
"$NM_DISPATCHER_ACTION" environment variable.

The main purpose is to have a particular, nm-dispatcher specific
variable that is always set inside the dispatcher scripts.
For example, imagine you have a script that can be either called by
dispatcher or some other means (manually, or spawned via
/etc/NetworkManager/dispatcher.d/11-dhclient).  Then it might make
sense to differenciate from inside the script whether you are called
by nm-dispatcher. But previously, there was no specific environment
variable that was always set inside the dispatcher event. For example,
with the "hostname" action there are no other environment variables.

Now (with version 1.12), you can check for `test -n "$NM_DISPATCHER_ACTION"`.
2018-06-18 14:18:08 +02:00
Thomas Haller
4822bff7aa release: update NEWS for 1.10.10 release
1.10.10 was released still before 1.12.0. Update the
NEWS to reflect that.

(cherry picked from commit f8dfc436b1)
2018-06-18 14:16:44 +02:00
Thomas Haller
f8dfc436b1 release: update NEWS for 1.10.10 release
1.10.10 was released still before 1.12.0. Update the
NEWS to reflect that.
2018-06-18 13:38:38 +02:00
Thomas Haller
cc3d577acd release: update NEWS 2018-06-15 17:16:18 +02:00
Lubomir Rintel
df58895fb3 build: disable libnm-glib by default
It's deprecated and has been replaced by libnm for 6 major releases now.

Its use in modern distributions has faded to the point it can probably
be safely removed.
2018-06-15 13:07:53 +02:00
Alfonso Sánchez-Beato
e7d26cd871 NEWS: add note about new WoWLAN settings 2018-06-15 09:46:26 +02:00
Thomas Haller
644aa42f68 dns: change main.rc-manager=file behavior to always follow symlink
With "main.rc-manager=file", if /etc/resolv.conf is a symlink, NetworkManager
would follow the symlink and update the file instead.

However, note that realpath() only returns a target, if the file actually
exists. That means, if /etc/resolv.conf is a dangling symlink, NetworkManager
would replace the symlink with a file.

This was the only case in which NetworkManager would every change a symlink
resolv.conf to a file. I think this is undesired behavior.

This is a change in long established behavior. Although note that there were several
changes regarding rc-manager settings in the past. See for example commit [1] and [2].

Now, first still try using realpath() as before. Only if that fails, try
to resolve /etc/resolv.conf as a symlink with readlink().

Following the dangling symlink is likely not a problem for the user, it
probably is even desired. The part that most likely can cause problems
is if the destination file is not writable. That happens for example, if
the destination's parent directories are missing. In this case, NetworkManager
will now fail to write resolv.conf and log a warning. This has the potential of
breaking existing setups, but it really is a mis-configuration from the user's
side.

This fixes for example the problem, if the user configures
/etc/resolv.conf as symlink to /tmp/my-resolv.conf. At boot, the file
would not exist, and NetworkManager would previously always replace the
link with a plain file. Instead, it should follow the symlink and create
the file.

[1] 718fd22436
[2] 15177a34be

https://github.com/NetworkManager/NetworkManager/pull/127
2018-06-05 16:21:10 +02:00
Lubomir Rintel
0317fad966 release: update NEWS for a development snapshot 2018-05-31 16:57:49 +02:00
Beniamino Galvani
8ffa22d10d dhcp: dhclient: set type 0 for printable client IDs
The documentation for the ipv4.dhcp-client-id property says:

 If the property is not a hex string it is considered as a
 non-hardware-address client ID and the 'type' field is set to 0.

However, currently we set the client-id without the leading zero byte
in the dhclient configuration and thus dhclient sends the first string
character as type and the remainder as client-id content. Looking
through git history, the dhclient plugin has always behaved this way
even if the intent was clearly that string client-id had to be zero
padded (this is evident by looking at
nm_dhcp_utils_client_id_string_to_bytes()). The internal plugin
instead sends the correct client-id with zero type.

Change the dhclient plugin to honor the documented behavior and add
the leading zero byte when the client-id is a string.

This commit introduces a change in behavior for users that have
dhcp=dhclient and have a plain string (not hexadecimal) set in
ipv4.dhcp-client-id, as NM will send a different client-id possibly
changing the IP address returned by the server.

https://bugzilla.gnome.org/show_bug.cgi?id=793957
2018-03-15 17:25:27 +01:00
Thomas Haller
28da0154fc all: drop trailing spaces 2018-02-07 13:32:04 +01:00
Beniamino Galvani
4fce1b90bf release: update NEWS 2017-11-10 16:15:23 +01:00
Beniamino Galvani
affeeb5a23 NEWS: update for a release candidate 2017-11-03 15:46:02 +01:00
Thomas Haller
4d47d5bf51 release: update NEWS 2017-05-10 13:19:16 +02:00
Lubomir Rintel
b5d63b8005 release: update NEWS 2017-04-20 17:02:31 +02:00
Lubomir Rintel
092cf11226 NEWS: update for a release candidate 2017-03-28 15:39:21 +02:00
Lubomir Rintel
da32a9f8bd NEWS: update for a development snapshot 2017-03-23 17:41:04 +01:00
Thomas Haller
37b659f75f NEWS: update 2017-02-14 18:00:18 +01:00
Thomas Haller
a101e0dc6a release: update NEWS 2017-01-25 17:38:43 +01:00
Lubomir Rintel
57c084a611 NEWS: move the more important entries upwards 2017-01-23 18:42:55 +01:00
Lubomir Rintel
c7b525f83e release: update NEWS
Co-authored-by: Thomas Haller <thaller@redhat.com>
2017-01-17 14:15:37 +01:00
Thomas Haller
a4b6a57688 NEWS: belatedly add news entry for th/preserve-fake-perm-hwaddr-bgo772880
This was already part of 1.5.2-dev.
2016-12-16 10:12:51 +01:00
Thomas Haller
7041e4d2ed NEWS: add entry about th/sysctl-ifname-race-bgo775613 branch 2016-12-16 10:04:35 +01:00
Lubomir Rintel
8afbf3d2b7 NEWS: update for a development snapshot 2016-12-15 20:29:47 +01:00
Lubomir Rintel
bcb158e1bc NEWS: update for a development snapshot 2016-11-03 17:56:13 +01:00
Thomas Haller
fae5ecec5a device: change default value for cloned-mac-address to "preserve" (bgo#770611)
Long ago before commit 1b49f94, NetworkManager did not touch the
MAC address at all. Since 0.8.2 NetworkManager would modify the
MAC address, and eventually it would reset the permanent MAC address
of the device.

This prevents a user from externally setting the MAC address via tools
like macchanger and rely on NetworkManager not to reset it to the
permanent MAC address. This is considered a security regression in
bgo#708820.

This only changed with commit 9a354cd and 1.4.0. Since then it is possible
to configure "cloned-mac-address=preserve", which instead uses the "initial"
MAC address when the device activates.
That also changed that the "initial" MAC address is the address which was
externally configured on the device as last. In other words, the
"initial" MAC address is picked up from external changes, unless it
was NetworkManager itself who configured the address when activating a
connection.

However, in absence of an explicit configuration the default for
"cloned-mac-address" is still "permanent". Meaning, the user has to
explicitly configure that NetworkManager should not touch the MAC address.
It makes sense to change the upstream default to "preserve". Although this
is a change in behavior since 0.8.2, it seems a better default.

This change has the drastic effect that all the existing connections
out there with "cloned-mac-address=$(nil)" change behavior after upgrade.
I think most users won't notice, because their devices have the permanent
address set by default anyway. I would think that there are few users
who intentionally configured "cloned-mac-address=" to have NetworkManager
restore the permanent address.

https://bugzilla.gnome.org/show_bug.cgi?id=770611
2016-09-12 14:01:57 +02:00
Thomas Haller
56bd86fd0c NEWS: update file with changes to PropertiesChanged signal 2016-09-02 20:13:36 +02:00
Thomas Haller
07e8ddbfd8 NEWS: update
(cherry picked from commit 0a04b55491)
2016-08-23 22:52:28 +02:00
Thomas Haller
965df5c571 NEWS: fix spelling
(cherry picked from commit 154c86efc6)
2016-08-23 22:44:24 +02:00
Lubomir Rintel
cb6f1f5751 release: update NEWS with recently merged features 2016-08-17 16:20:42 +02:00
Beniamino Galvani
65e522ee16 release: update NEWS 2016-08-03 09:39:03 +02:00
Thomas Haller
e0e1c59160 NEWS: fix mistake in NEWS file about wifi.mac-address-randomization 2016-05-19 12:11:38 +02:00
Lubomir Rintel
dbdb455cc8 release: update NEWS 2016-03-29 16:10:25 +02:00
Thomas Haller
c1383371cc NEWS: minor update referencing 1.0.10 release 2016-03-16 12:29:46 +01:00
Beniamino Galvani
24e3306b87 release: update NEWS 2016-03-01 09:56:14 +01:00
Beniamino Galvani
2446da1564 release: improve NEWS 2016-01-21 11:42:42 +01:00
Lubomir Rintel
ecd729706e relese: fix NEWS formatting
The double spacing was probably a mistake. Also, there was an extra line break.
2016-01-19 15:10:35 +01:00
Lubomir Rintel
636380d19d release: update NEWS 2016-01-18 13:06:30 +01:00
Thomas Haller
d4b257b613 NEWS: mention missing feature for 1.0 2015-01-27 21:46:01 +01:00
Dan Williams
ee65399030 release: update NEWS 2014-12-18 12:07:13 -06:00
Dan Williams
4b7a736c40 build: update NEWS 2014-11-20 15:15:10 -06:00
Jiří Klimeš
a7eae7a553 trivial: typo in the NEWS 2014-06-09 09:15:40 +02:00