DHCP timeout may now be explicitly disabled by setting the
ipv[4,6].dhcp-timeout options to "infinity".
This will set the DHCP timeout value to MAXINT32.
There are basically three options:
1) use a separate _get_fcn_gobject_dcb_priority() getter and
implement them as a new type _pt_gobject_dcb_priority.
2a) implement them as _pt_gobject_int and set nicks as value_infos,
repeating the nicks 3 times.
2b) like 2a, but use a macro to define how the DCB priority shall
behave at one place.
I think 1) is ugly. In the previous form, it also does not support
setting the property to "unset". We should implement properties as
types, and modify their behavior (by setting value_infos), instead
of implementing multiple, different types.
I slightly prefer 2b) over 2a) because it defines the behavior once,
but it's a bit harder to follow.
- Reduce duplicated code and implement the property according to
best-practice for integer types.
- Do not translate the output
- This way, the setter also supprts the nick names
No reason to, the other types are no less likely. Quite the contrary, if
the user specifies a GSM APN we're sure to use a DUN profile.
$ ./clients/cli/nmcli c add type bluetooth ifname '*' bluetooth.bdaddr 1C:E2:CC:56:6C:45 apn internet
$ nmcli c show bluetooth-1 |grep bluetooth.type
bluetooth.type: panu
^^^^ not cool
Unbreaks Bluetooth DUN. Probably broken with the nm-meta-setting-desc
refactor, hence the Fixes tag. I didn't actually check.
$ nmcli c add type bluetooth ifname '*' bluetooth.bdaddr 1C:E2:CC:56:6C:45 connection.id bt bt-type dun-gsm
Error: 'apn' argument is required.
$ nmcli c add type bluetooth ifname '*' bluetooth.bdaddr 1C:E2:CC:56:6C:45 connection.id bt bt-type dun-gsm apn internet
Error: invalid <setting>.<property> 'apn'.
$
This is where it starts to get sad ^
$ nmcli c add type bluetooth ifname '*' bluetooth.bdaddr 1C:E2:CC:56:6C:45 connection.id bt bt-type dun-gsm gsm.apn internet
Error: invalid or not allowed setting 'gsm': 'gsm' not among [connection, bluetooth, bridge, ipv4, ipv6, proxy].
$
This is where it gets obvious what went wrong ^
Fixes: b5c8622ad3
When the property is set, it specifies the device on which PPPoE is to
be started. The ppp interface will be named as the
connection.interface-name property.
When the property is not set the previous behavior will be retained,
i.e. the PPPoE connection will be started on connection.interface-name
and the PPP interface will have a random name.
The order matters for the 'nmcli connection show' output and for the
interactive mode of nmcli. Users should not rely on the order in both
cases, but since we have an extensive test suite for the interactive
mode, restore the order as it was in 1.8.
This way, we get tab completion for the enum values, and
can reuse existing code.
This requires a pre-set-notify hook, that is invoked before
setting the property.
Instead of having 3 implementations for setting an int (int, uint, int64), combine
them. Also, make them more configurable by allowing to specify min/max/base, outside
of GParamSpec.
Now that routes can include optional attributes, print the expected
syntax in case of parsing failure.
$ nmcli connection modify dummy ipv4.routes a
Error: failed to modify ipv4.routes: invalid route: Invalid IPv4
address 'a'. The valid syntax is: 'ip[/prefix] [next-hop] [metric]
[attribute=val]... [,ip[/prefix] ...]'.
Before refactoring nmcli recently, field names were marked for translation.
Note that for the property names, marking them had no effect as only
plain strings can be marked with N_().
Note how --fields are also an input argument. The input should be
independent of the locale and not translated. Likewise, when printing
the header names, they should not be translated to match the --fields
option.
$ LANG=de_DE.utf8 nmcli --fields GENERAL.DEVICE device show enp0s25
GENERAL.GERÄT: enp0s25
Drop the translation marks.
