The input list of routes is allowed to contain non-normalized routes,
that is, routes which host part is non-zero. Such routes are rejected
by kernel, but NM should transparently allow them (by normalizing
the host part).
The ID comparison function route_id_cmp() already properly ignored
the (possibly non-zero) host part. However, in the internal list we
also should make sure not to track such routes. We achive that by
normalizing the host part to zero.
Note that below we check whether the tracked route is idential to
the route configured at platform. If we don't normalize the host part,
the comparison will always indicate that the route is not yet
configured, and thus we will re-sync the route every time.
Kernel requires that routes have a host part of zero. For NetworkManager
configuration we allow non-zero host parts (but ignore them). Fix
route_compare() to ignore the host part.
This has only effect during assuming connections. That means, on
restart NM would fail to match a connection with static routes
if it has a non-zero host part. So, the impact is rather small.
Routes with a non-zero host part are not allowed by kernel and
don't really exist. We didn't reject such routes in users configuration,
so various part of NM allow such routes. NM should silently strip
the host part.
Extend the cache's route ID to clear the host part too.
Note that NM's handling of routes is fundamentally flawed, as
for kernels routes don't have an "id" (or rather: all properties
of a route are part of it's ID, not only the family,ifindex,
network/plen and metric tuple (see related bug rh#1337855).
Platform's add/remove operations accept a "network" argument.
Kernel requires that the host part (based on plen) is all zero.
For NetworkManager we are more resilient to user configuration.
Cleanup the input argument already before calling _nl_msg_new_route().
Note that we use the same "network" argument to construct a obj_id
instance and to find the route in the cache (do_add_addrroute()).
Without cleaning the host part, the added object cannot be found
and the add-route command seemingly fails.
Got an assertion due to priv-proxy unset.
NMDevice:
- _platform_link_cb_idle()
- nm_device_unrealize() [NMDeviceTun]
- nm_device_state_changed()
- _set_state_full()
NMVpnConnection:
- _set_vpn_state()
- call_plugin_disconnect()
It seam to me, that can only happen if the NMVpnConnection never
completed on_proxy_acquired() and is still in preparing state when
being disconnected.
Avoid that be checking whether we have a proxy.
https://bugzilla.redhat.com/show_bug.cgi?id=1442064
If the D-Bus call to DeactivateConnection() fails, don't wait for the
connection to change state because this is not going to
happen. Instead, notify the user of the error and, if necessary, wait
for remaining connections to be deactivated.
https://bugzilla.redhat.com/show_bug.cgi?id=1422786
It's perfectly valid to call the function with out_connection == NULL
when connection_hash == NULL too, as cancel_get_secrets() does.
Fixes: fbb1662269
That allows for the property list to contain derived
property types. Also, the list can be directly passed
off as a "const NMMetaAbstractInfo *const*" list.
This change (improves) behavior.
Before, we would only complete
if (g_strcmp0 (con_type, nmc_tab_completion.con_type) != 0)
which doesn't really make sense as it depends on the slave-type,
not nmc_tab_completion.con_type.
This changes behavior, in that yes|no prompt and answer is no longer
localized.
For command line arguments, I think it is always wrong for nmcli to
behave differently based on the localization. That is, input properties
on command line should not be translated.
One could make an argument, that in interactive mode that is different
and the user can be prompted in the his language.
But I think for consistency, it is wrong to ask for localized nmcli input.
Don't mutate global state. For now, hack around it by putting
the mutable flags to a separate (global) cache. Obviously, it
still uses global data, but it no longer touches the global
option_info list.
- have the "self" argument first, before the environment arguments.
It's more idiomatic.
- from within cli, always pass nmc_meta_environment and nmc_meta_arg
where needed.
- drop the union in NMMetaAbstractInfo. I was suppost to make casts
nicer, but it doesn't really.
The show-secrets flag can be toggled in edit mode
nmcli> nmcli show-secrets yes
There is no point in tracking two separate flags for it. Inside
edit mode, when the user toggles the show-secrets flag, it should
overwrite the command line option.
These two flags can be merged.
The show-secret property is basically a part of the current
configuration, relevant during printing. It will be passed
on to nmc_print(), and hence must be part of NmcConfig.
We already have
- data sources (nm_cli, connections or settings)
- meta data information how to access the data sources (NMMetaAbstractInfo,
NmcMetaGenericInfo, NMMetaPropertyInfo)
Add now a generic way to output cli data using nmc_print(). It gets a
list of data-sources (@targets) and a list of available fields (meta
data). It also gets cli configuration (NmcConfig) and field selector
strings (@field_str).
Based on that, it should output the desired data.
This is intended to replaces the previous approach, where functions like
show_nm_status() have full knowledge about how to access the data and
create an intermediate output format (NmcOutputData, NmcOutputField)
that was printed via print_data().
show_nm_status() contained both knowledge about the data itself (how to
print a value) and intimate knoweledge about the output intermediate
format. Also, the intermediate format is hard to understand. For
example, sometimes we put the field prefix in NmcOutputField at index 0
and via the NmcOfFlags we control how to output the data.
Clearly separate the responsibilities.
- The meta data (NmcMetaGenericInfo) is only concerned with converting
a data source to a string (or a color format).
- the field selection (@field_str) only cares about parsing the list
of NMMetaAbstractInfo.
- _print_fill() populates a table with output values and header
entries.
- _print_do() prints the previously prepared table.
The advantage is that if you want to change anything, you only need to
touch a particular part.
This is only a show-case for `nmcli general status`. Parts are still
un-implemented and will follow.
This changes behavior for --terse mode: the values are now no longer
translated:
$ LANG=de_DE.utf8 nmcli -t --mode multiline general
