We actually don't want to understand these options unless the legacy
*-slave types are used. The properties should be used directly instead.
https://bugzilla.gnome.org/show_bug.cgi?id=748302
This basically undoes most of what has been done in commit 00e0fffea2.
Bump NM version number to 1.2 and add the project name to non-XML
pages. Also, update the dates to the date of the last non-trivial
change and update their format to YYYY-MM-DD, as specified by 'man
man-pages'.
Until now the internal DHCP client could start a DHCPv6 transaction
but was not able to parse the lease and pass the information back to
the core. Add the missing glue code to make this work.
https://bugzilla.gnome.org/show_bug.cgi?id=762432
Choose a new logging format.
- the logging format must not be configurable and it must be the
same for all backends. It is neat that journal supports additional
fields, but an average user still posts the output of plain
journalctl, without "--output verbose" (which would also be hard
to read).
Also, we get used to a certain logging format, so having different
formats is confusing. If one format is better then another, it should
be used for all backends: syslog, journal and debug.
The only question is, what is the best format.
- the timestamp: I find it useful to see how much time between two
events passed. The timestamp printed by syslog doesn't have sufficient
granularity, and the internal journal fields are not readily available.
We used to print the timestamps for <error>, <debug> and <trace>,
but ommited them for <info> and <warn> levels. We now print them for
all levels, which has a uniform alignment.
- the location: the "[file:line] func():" part is mostly redundant
and results in wide lines. It also causes a misalignment of the
logging lines, or -- as I recently added alignment of the location --
it results in awkward whitespace and truncation.
But the location is really just necessary because our logging messages
are bad:
"<debug> [1456397604.038226] (9) 11-dhclient succeeded"
The solution to this is not
"<debug> [1456397604.038226] [nm-dispatcher.c:358] dispatcher_results_process(): (9) 11-dhclient succeeded"
but a properly worded message:
"<debug> [1456397604.038226] dispatcher: request #9, script 11-dhclient succeeded"
- logging-message: we need to write better logging messages.
I like some form of "tags" that are easy to grep:
"platform: signal: link changed: 4: ..."
Downside is, that this is not nice to read as a full sentence.
So, especially for <info> and <warn> logging, more human readable
messages are better.
We should find a compromise, where the log message explains what
happens, but is still concise and contains patterns that are easy
to grep and identify visually.
https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00077.html
Some drivers (or things outside NM like 'powertop') may turn powersave
on, so don't touch it unless explicitly configured by user.
To achieve this, add new 'default' and 'ignore' options; the former
can be used to fall back to a globally configured setting, while the
latter tells NM not to touch the current setting.
When 'default' is specified, a missing global default configuration is
equivalent to 'ignore'.
It is possible to enable Wi-Fi power saving for all connections by
dropping a file in /etc/NetworkManager/conf.d with the following
content:
[connection]
wifi.powersave=3
https://bugzilla.gnome.org/show_bug.cgi?id=760125
Only install nm-settings-ifcfg-rh.5 man page if the ifcfg-rh
configuration plugin has been enabled.
But still add them to EXTRA_DIST so that the source tarball
contains the generated man-file, but it isn't installed.
https://bugzilla.gnome.org/show_bug.cgi?id=759823
- it controls echoing passwords input on terminal
- it replaces --show-secrets in 'nmcli connection show', which is deprecated now
- it replaces --show-password in 'nmcli device wifi hotspot', which is deprecated now
If the supplicant supports it and the connection requests it, tell
the supplicant to randomize the MAC address for the association.
In addition, like both iOS, Android, and other OSs always randomize
the MAC address when performing a WiFi scan.
Synopsis:
nmcli connection clone [--temporary] [id|uuid|path] <ID> <new name>
It copies the <ID> connection as <new name>. The command is very useful
if there is a connection, but another one is needed for a related
configuration. One can copy the existing profile and modify it for the
new situation.
For example:
$ nmcli con clone main-eth second-eth
$ nmcli con modify second-eth connection.interface-name em4
https://bugzilla.gnome.org/show_bug.cgi?id=757627
The list of LLDP neighbors is available through the D-Bus interface
and libnm already provides functions to retrieve it; make the list
available through nmcli as well. Sample output:
$ nmcli device lldp
NEIGHBOR[0].DEVICE: eth0
NEIGHBOR[0].CHASSIS-ID: 00:13:21:58:CA:42
NEIGHBOR[0].PORT-ID: 1
NEIGHBOR[0].PORT-DESCRIPTION: 1
NEIGHBOR[0].SYSTEM-NAME: ProCurve Switch 2600-8-PWR
NEIGHBOR[0].SYSTEM-DESCRIPTION: ProCurve J8762A Switch 2600-8-PWR, revision H.08.89
NEIGHBOR[0].SYSTEM-CAPABILITIES: 20 (mac-bridge,router)
NEIGHBOR[1].DEVICE: eth2
NEIGHBOR[1].CHASSIS-ID: 00:01:30:F8:AD:A2
NEIGHBOR[1].PORT-ID: 1/1
NEIGHBOR[1].PORT-DESCRIPTION: Summit300-48-Port 1001
NEIGHBOR[1].SYSTEM-NAME: Summit300-48
NEIGHBOR[1].SYSTEM-DESCRIPTION: Summit300-48 - Version 7.4e.1 (Build 5)
NEIGHBOR[1].SYSTEM-CAPABILITIES: 20 (mac-bridge,router)
https://bugzilla.gnome.org/show_bug.cgi?id=757307
It is useful to show nmcli-generated hotspot password (if a user does not
provide his own password). Without the option the user would have to look into
the generated profile in order to find out the password.
Add the 'lldp' property to NMSettingConnection, which specifies
whether the reception and parsing of LLDP frames to discover neighbor
devices should be enabled.
