It *is* legitimate to (re-)activate a connection on an already-active
device, so remove the newly-added "sanity check" preventing that.
Pointed out by jklimes.
If for some reason the connection is disrupted and the AP rejects
reconnection attempts (perhaps the driver has a bug, you get
disconnected, and the AP rejects association because it thinks
you're already associated), the AP object was being removed from
the scan list by code meant to handle out-of-range or turned-off
APs. Thus even though the AP was in-range, it wouldn't be
found and the connection retried until the next scan.
Instead, only remove the AP object from the scan list if the
supplicant hasn't been able to exchange any frames with the
AP. This preserves the out-of-range handling, becuase the
supplicant wouldn't be able to talk to the AP and thus
'ssid_found' will be FALSE, and also ensures that an in-range
but confused AP says in the scan list and will be retried
immediately.
This will help to store more link attributes in NMFakePlatform link
array than in public NMPlatformLink array. Some of the future
attributes will not be part of the NMPlatform API.
That way it is not displayed by default:
$ nmcli general status
But can be explicitly requested:
$ nmcli -t -f running,version general status
$ nmcli -f all general status
E.g. Fedora initscripts do this in
/etc/sysconfig/network-scripts/network-functions
is_nm_running ()
{
[ "$(LANG=C nmcli -t --fields running nm status 2>/dev/null)" = "running" ]
}
Update gnome-code-coverage.m4 from gnome-common to fix some (harmless)
error messages when coverage is disabled (bug 699943), and to add
support for lcov 1.10.
Although having different parts of NM in different subdirectories
keeps the source tree neat, it has made the build messy, particularly
because of cross-dependencies between the subdirs.
Reorganize to build all of the pieces of the NetworkManager binary
from src/Makefile, and only use recursive make for test programs,
helper binaries, and plugins.
As part of this, get rid of all the per-directory convenience
libraries, and switch to building a single top-level
libNetworkManager.la, containing everything except main.c, which all
of the test programs can then link against.
When --with-modem-manager-1=yes not explicitly specified (i.e. 'auto' mode), and
libmm-glib is not found, we should not report:
Features:
...
modemmanager-1: auto
Instead, better report:
Features:
...
modemmanager-1: no
Due to recent changes not all settings plugins send an IP config setting
when the method is 'auto'. Some old code in the NMDevice IP config paths
mishandled this. Fix that up; the expected behavior should be:
1) if the device is a slave, IP configuration is DISABLE/IGNORED
2) if the connection has an IP4 or IP6 setting, use the setting's method
3) default to AUTO
The bits in the result of ETHTOOL_GFEATURES are not in any defined
order; you need to use ETHTOOL_GSTRINGS to get the names associated
with each bit to find what each one does. Fix
NMPlatformLinux:link_supports_vlans() to do this.
https://bugzilla.gnome.org/show_bug.cgi?id=699649
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.
