"InfiniBand" has a capital "B". Fix that everywhere it's being used as
a human-readable string.
In particular, the RH initscripts recognize "TYPE=infiniband" and
"TYPE=InfiniBand", but not "TYPE=Infiniband", which is what we were
writing before.
This is a proposal to include the NMActiveConnection master property in
nmcli con status.
Feel free to suggest a more user friendly method of printing this
information.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
The command didn't delete the connection, because nmcli exited before NM could
check permissions (actually ConsoleKit didn't see the process).
Now nmcli waits for "Removed" signal or D-Bus return (error) message on "Delete"
method call.
Field values can now be string arrays. print_fields() recognizes the format and
prints values accordingly.
Setter functions was added to facilitate setting string vs. array:
set_val_str(), set_val_arr()
nm_access_point_get_hw_address() is deprecated in 0.9.
Also change 'hwaddr' parameter for 'nmcli dev wifi list' to 'bssid'. 'hwaddr'
still works but is deprecated and not documented any more.
nm_client_activate_connection() now uses NMConnection instead of
D-Bus connection path. Also, callback uses NMActiveConnection instead
of the path.
We can also remove the workaround waiting for "active-connections" change,
because the activation callback is now called *after* the NMActiveConnection
object is available in the active connections list.
These days more and more devices are showing up that support a
number of different access technology families in the same hardware,
like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM),
Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra
320U (GSM and LTE), etc. The previous scheme of having device
classes based on access technology family simply cannot handle
this hardware and attempting to add LTE to both the CDMA and GSM
device classes would result in a bunch of code duplication that
we don't want. There's a better way...
Instead, combine both CDMA and GSM device classes into a generic
"Modem" device class that provides capabilities indicating what
access technology families a modem supports, and what families
it supports immediately without a firmware reload. (Gobi devices
for example require a firmware reload before they can switch
between GSM and CDMA). This provides the necessary flexibility
to the client and allows us to keep the API stable when the
same consolidation change is made in ModemManager.
The current code doesn't yet allow multi-mode operation internally,
but the API is now what we want it to be and won't need to be
changed.
Clients need to do their own logging using glib or whatever; these
macros while somewhat helpful were not flexible and are not a
substitute for actual logging in the client. g_warning, g_message,
and g_error are more suitable anyway.
