summaryrefslogtreecommitdiff
path: root/NEWS
Commit message (Collapse)AuthorAgeFilesLines
...
* release: update NEWS for a development snapshotLubomir Rintel2018-05-311-0/+53
|
* dhcp: dhclient: set type 0 for printable client IDsBeniamino Galvani2018-03-151-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* all: drop trailing spacesThomas Haller2018-02-071-1/+1
|
* release: update NEWSBeniamino Galvani2017-11-101-4/+3
|
* NEWS: update for a release candidateBeniamino Galvani2017-11-031-0/+51
|
* release: update NEWSThomas Haller2017-05-101-5/+20
|
* release: update NEWSLubomir Rintel2017-04-201-1/+1
|
* NEWS: update for a release candidateLubomir Rintel2017-03-281-1/+8
|
* NEWS: update for a development snapshotLubomir Rintel2017-03-231-3/+20
|
* NEWS: updateThomas Haller2017-02-141-0/+14
|
* release: update NEWSThomas Haller2017-01-251-5/+2
|
* NEWS: move the more important entries upwardsLubomir Rintel2017-01-231-12/+12
|
* release: update NEWSLubomir Rintel2017-01-171-1/+16
| | | | Co-authored-by: Thomas Haller <thaller@redhat.com>
* NEWS: belatedly add news entry for th/preserve-fake-perm-hwaddr-bgo772880Thomas Haller2016-12-161-0/+3
| | | | This was already part of 1.5.2-dev.
* NEWS: add entry about th/sysctl-ifname-race-bgo775613 branchThomas Haller2016-12-161-0/+3
|
* NEWS: update for a development snapshotLubomir Rintel2016-12-151-1/+22
|
* NEWS: update for a development snapshotLubomir Rintel2016-11-031-3/+20
|
* device: change default value for cloned-mac-address to "preserve" (bgo#770611)Thomas Haller2016-09-121-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* NEWS: update file with changes to PropertiesChanged signalThomas Haller2016-09-021-0/+10
|
* NEWS: updateThomas Haller2016-08-231-2/+2
| | | | (cherry picked from commit 0a04b55491d98a3450cf1750ec96d4c4c819fa5b)
* NEWS: fix spellingThomas Haller2016-08-231-1/+1
| | | | (cherry picked from commit 154c86efc6711f2a8285cc7e74011c972f3b6c92)
* release: update NEWS with recently merged featuresLubomir Rintel2016-08-171-0/+3
|
* release: update NEWSBeniamino Galvani2016-08-031-0/+51
|
* NEWS: fix mistake in NEWS file about wifi.mac-address-randomizationThomas Haller2016-05-191-4/+6
|
* release: update NEWSLubomir Rintel2016-03-291-2/+11
|
* NEWS: minor update referencing 1.0.10 releaseThomas Haller2016-03-161-1/+1
|
* release: update NEWSBeniamino Galvani2016-03-011-1/+12
|
* release: improve NEWSBeniamino Galvani2016-01-211-15/+17
|
* relese: fix NEWS formattingLubomir Rintel2016-01-191-87/+0
| | | | The double spacing was probably a mistake. Also, there was an extra line break.
* release: update NEWSLubomir Rintel2016-01-181-0/+271
|
* NEWS: mention missing feature for 1.0Thomas Haller2015-01-271-1/+2
|
* release: update NEWSDan Williams2014-12-181-0/+2
|
* build: update NEWSDan Williams2014-11-201-0/+46
|
* trivial: typo in the NEWSJiří Klimeš2014-06-091-1/+1
|
* release: update NEWSDan Williams2014-06-061-0/+56
|
* release: update NEWSDan Williams2013-01-151-0/+36
|
* release: update NEWSDan Williams2012-08-071-0/+3
|
* release: update NEWSDan Williams2012-07-231-0/+3
|
* release: update NEWSDan Williams2012-06-271-2/+3
|
* release: update NEWSDan Williams2012-06-121-0/+5
|
* release: update NEWS with ADSL supportDan Williams2012-05-181-0/+1
|
* release: update NEWSDan Williams2012-05-011-0/+13
|
* release: update NEWSDan Williams2012-03-231-0/+1
|
* release: update NEWSDan Williams2012-03-161-0/+3
|
* release: update NEWSDan Williams2012-03-151-0/+4
|
* release: update NEWSDan Williams2012-03-011-0/+5
|
* release: update NEWSDan Williams2012-02-161-0/+3
|
* release: update NEWSDan Williams2011-12-021-1/+11
|
* release: update NEWSDan Williams2011-11-091-0/+16
|
* release: update NEWSDan Williams2011-11-071-0/+5
|
View Lorry Controller Status