A few examples:
nmcli --ask connection add
nmcli connection add type ethernet
nmcli -p connection add type ethernet con-name "my ethernet connection 1"
nmcli connection add type ethernet ip4 192.168.100.5/24
nmcli connection add type ethernet ip4 192.168.100.100/24 gw4 192.168.100.1 ip4 1.2.3.4 ip6 abbe::cafe
nmcli connection add type ethernet ifname eth0
nmcli connection add type ethernet autoconnect no ifname eth0
nmcli connection add type wifi con-name Rakosnicek ssid Brcalnik
nmcli --ask connection add type wifi con-name My_WiFi
nmcli c a type infiniband con-name Infi1 transport-mode connected
nmcli c a type bluetooth addr 12:54:00:fd:db:26
nmcli c a type bluetooth addr 12:54:00:fd:db:26 bt-type dun-cdma
nmcli c a type gsm apn internet
nmcli c a type cdma
nmcli c a type bond
nmcli c a type bond ifname mybond0 mode active-backup
nmcli c a ifname maxipes-fik type vlan dev eth0 id 55
nmcli c a con-name VLAN1 type vlan dev eth0 id 44 ingress "2:4,3:55" egress "1:3" flags 6
nmcli c a type bridge ifname br0 stp on ip4 10.0.0.25
nmcli c a ifname eth0 type bridge-slave master 30fc816a-e7dd-4ae7-a86e-ab0c9cee51c2 hairpin no path-cost 333 priority 20
nmcli c a type bridge-slave master br2
nmc_string_to_int() - converts string to signed long int (decimal)
nmc_string_to_uint() - converts string to unsigned long int (decimal)
nmc_string_to_int_base() - converts string to signed long int with given base
nmc_string_to_uint_base() - converts string to unsigned long int with given base
This function checks whether a string is contained among allowed strings. It
performs case-insensitive comparison and supports shortcuts if they are unique.
It returns a pointer to the found string in allowed array, or NULL.
Add a new libnm-glib method to get the type description for a device,
and use it in nmcli. For most types, the type description is based on
the class name, but for NMDeviceGeneric, it comes from the
:type-description property.
Add NMDeviceGeneric, to provide generic support for unknown device
types, and create NMDeviceGenerics for those devices that NM
previously was ignoring. Allow NMSettingGeneric connections to be
activated on (managed) NMDeviceGenerics.
Allow devices to declare themselves unmanaged-by-default, but tweak
nm-manager and nm-policy to allow activating matching connections on
those devices anyway.
(This ensures that NM keeps its hands completely off the device unless
the user explicitly asks it to do something with it.)
If the Intel WiMAX stack is built with libnl1, but NM is built with a
newer libnl, then symbol conflicts between libnl versions will occur
when the WiMAX plugin is loaded into NM, and NM will crash.
Distros should be building their WiMAX stack with libnl3, using the
following git repos, rather than the long-defunct Intel git repos:
git://people.freedesktop.org/~dcbw/wimax
git://people.freedesktop.org/~dcbw/wimax-tools
These repos contain fixes to allow the WiMAX stack to build against
libnl3.
If the Intel WiMAX stack is built with libnl1, but NM is built with a
newer libnl, then symbol conflicts between libnl versions will occur
when the WiMAX plugin is loaded into NM, and NM will crash.
Distros should be building their WiMAX stack with libnl3, using the
following git repos, rather than the long-defunct Intel git repos:
git://people.freedesktop.org/~dcbw/wimax
git://people.freedesktop.org/~dcbw/wimax-tools
These repos contain fixes to allow the WiMAX stack to build against
libnl3.
This suppression didn't work on F17 for some reason, even though the
stacktrace was the same. Valgrind wanted some kind of:
obj:<path to libglib>
between the calloc and the g_malloc0 lines; but we don't actually
care much about the calloc anyway.
Now that NMDevice reads the hwaddr directly from netlink, it's silly
to have every device subtype maintain its own hw-address property
(using data that it gets from the NMDevice base class).
Remove all the device-specific hw-address properties, and add one to
NMDevice instead. (Because of the way nm-properties-changed-signal
works, this has no effect on the D-Bus API.) Subclasses now call
nm_device_get_hw_address() in places where they used to just refer to
priv->hw_addr (and to simplify this, we now allow passing NULL for the
out length parameter, since the subclasses almost always know what the
length will be already).
Also reorganize/simplify a few other methods to take advantage of the
fact that NMDevice is now keeping track of the hw-address directly.
https://bugzilla.gnome.org/show_bug.cgi?id=699391
and use it in 'allowed-bands' property installation.
The macro NM_SETTING_GSM_BANDS_MAX also allows libnm-util users to check
if bands are valid (before setting them).
This is a simple testing tool. Even though it includes a basic help (just run
it without arguments), the command syntax often requires looking into the
code. Use it whenever you want to test specific behavior of nm-platform.
For regular tests, please amend the automatic testsuite instead.
On Linux, the gateway attribute is not a key attribute and therefore is
not necessary for functions that just need to identify a route. This may
be revisited when porting to other platforms but for now I want to keep
things simple.
"g_assert_cmpint (x, ==, y)" is nicer than "g_assert (x == y)",
because if it fails, it shows you the values of x and y in the assert
message. Likewise g_assert_cmpstr().
The "ifindex > 0" checks still just use g_assert(), since we don't
need to distinguish specific negative values there.
nm_setting_to_hash() would return NULL if the setting had entirely
default values, but this effectively meant that you could never have a
connection whose "connection type" setting (eg, NMSettingWired) had
all default values. (This ended up not usually being a problem in
practice because most such settings had at least one property with a
mandatory string value where the GObject property had a default value
of NULL.)
However, NMSettingGeneric will have no properties, so it would always
get stripped out when converting to a hash, invalidating the
connection. Fix that.
In some cases, callers don't need to distinguish, eg,
ip4-address-added from ip6-address-added, but just need to know what
device the event occurred on. Make this simpler by including the
ifindex as a separate explicit argument, allowing callers to just
ignore the struct part.
If a device becomes unmanaged or unavailable (eg, due to loss of carrier, becoming
unmanaged, rfkilled, supplicant crashing, etc), the ActiveConnection would simply
set state to UNKNOWN and the Manager wouldn't tear it down and remove it from the
ActiveConnections property list. Instead, these states should be treated the same
as if the device was deactivated cleanly so that the AC will accurately reflect
the device state and the Manager will clean the AC up.
Fixes comment #12 in:
https://bugzilla.gnome.org/show_bug.cgi?id=676285
