If the WiMAX plugin isn't installed, or the WiMAX device isn't
recognized, NetworkManager shouldn't treat the interface as
regular ethernet since the device requires specific setup to
be ready for IP configuration, which of course NetworkManager
can't do because the WiMAX plugin isn't loaded. Ignore them
instead.
Plugin owns the object and callers must reference it if they wish to use it outside
of the function they called "add" from. Likewise, callers of the ConnectionProvider's
add_connection method must also reference the returned object if they wish to
continue using it.
Actually, this case should no longer happen, but just to be sure:
when a udev remove event without ifindex comes, get the ifindex from
the cache and announce the device removal.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before NMPlatform landed, the old NMManager code looked at either
DEVTYPE=wlan or asked the internal wifi utilities whether the
device was WiFi or not. This got lost when moving to NMPlatform.
It turns out that only mac80211-based drivers set the DEVTYPE=wlan
flag in sysfs, while older WEXT, out-of-tree, and staging drivers
often do not (though they should).
To avoid breaking recognition of these crappy drivers that used
to work, re-add the wifi utils checks.
When connecting to a hidden SSID, the Access Point object that NetworkManager
creates will have no frequency, because the frequency is unknown until the
connection succeeds. The warning has no use; if the AP doesn't have a
frequency then it even match a connection with a specified frequency.
Although it's convenient in some places to have IP configs on all
connections, it makes more sense in other places to not have IP
configs on slaves. (eg, it's confusing for nmcli, etc, to report a
full NMSettingIP4Config on a slave device). So revert parts of the
earlier patch. However, it's still safe to assume that s_ip4 != NULL
if method != DISABLED, so some of the earlier simplifications can
stay.
Also, add nm_utils_get_ip_config_method(), which returns the correct
IP config method for a connection, whether the connection has IP4 and
IP6 settings objects or not, and use that to keep some more of the
simplifications from the earlier patch.
We have to check if 'client' is valid when calling _nm_object_ensure_inited().
Creation of NMClient object can fail, because its parent NMObject's
constructor() returns NULL for D-Bus errors.
https://bugzilla.redhat.com/show_bug.cgi?id=1010288
ifcfg-rh had the rule that if an ifcfg file had no BOOTPROTO and no
IPv4 addresses, then it should be treated as method=auto for
compatibility. But in fact, current ifup treats it as method=disabled,
so we should too.
https://bugzilla.gnome.org/show_bug.cgi?id=708875
Make sure that all connections returned from NMSettings or created via
AddAndActivateConnection have an NMSettingIP4Config and an
NMSettingIP6Config, with non-NULL methods, and get rid of
now-unnecessary checks for those.
Also move the slaves-can't-have-IP-config checks into the
platform-independent code as well. This also gets rid of spurious
"ignoring IP4/IP6 configuration" warnings in ifcfg-rh when reading a
slave ifcfg file.
Partly based on a patch from Pavel.
https://bugzilla.gnome.org/show_bug.cgi?id=708875
gtk-doc recognizes that #NMFoos is the plural of #NMFoo now, so you
don't need to put an empty comment between the type name and the "s"
to make it work. (Unfortunately, it's not smart enough to realize that
"NMIP4Addresses" is the plural of "NMIP4Address".)
Also, add some missing "#"s noticed along the way.
To present a consistent API to clients, the IP-related properties
are only valid when the device has finished IP configuration. But
they are set before that happens, and their change notifications
were emitted before the IP configuration was considered valid.
Re-emit the change notifications when the device enters the IP_CHECK
state (and thus has IP configuration) and also when the device
deactivates to enusre clients have up-to-date IP-related property
information.
For the changes to has_ip_config(), the priv->ipX_state checks are
not necessary since the device will have valid IP configuration
when it enters the IP_CHECK state. The other checks can be
consolidated into a single statement.
Acked-by: Dan Winship
If the user disabled IPv6 support in the kernel with "ipv6.disable=1" on the
kernel boot line, then any attempts to open IPv6 sockets (which libndp does)
will fail. This failed the entire connection, even if IPv6's "may-fail"
property was TRUE. Instead, just fail IPv6 and allow IPv4 to proceed. If
IPv4 fails or is disabled, then other logic will fail the entire connection.
connection_from_file() requires the 'error' parameter. Not passing a
valid 'error' parameter causes the function to fail and return NULL,
which mean that commit_changes() would always re-write the connection
instead of ignoring commits where nothing has actually changed.
connection_from_file() no longer requires the unmanaged, keyfile,
or routefile parameters, so remove them.
Running `make check` on systems without running dbus failed
in test-remote-settings-client.c:383
make[4]: Entering directory `/tmp/NetworkManager/libnm-glib/tests'
/tmp/NetworkManager/libnm-glib/tests/test-remote-settings-client /tmp/NetworkManager/libnm-glib/tests test-remote-settings-service.py
** (/tmp/NetworkManager/libnm-glib/tests/.libs/lt-test-remote-settings-client:26983): WARNING **: Error connecting to D-Bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
make[4]: *** [check-local] Trace/breakpoint trap (core dumped)
Modify the Makefile to start the dbus-daemon, if it is not yet
running.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Some RA implementations (like radvd) dump whatever the user configures
onto the wire, accepting a prefix of "2001:db8:1:0::1/64" without
masking the host bits off.
This causes NetworkManager to send that route down to the kernel, which
*does* mask the host bits off. This causes a mismatch between the
route NetworkManager expects the kernel to create, and what the kernel
actually created, when searching for the kernel object in the platform's
refresh_object() function:
cache = choose_cache (platform, object);
cached_object = nl_cache_search (choose_cache (platform, object), object);
kernel_object = get_kernel_object (priv->nlh, object);
kernel_object is NULL since 'object' (a route which came from the RA
prefix) is not the same as the object the kernel actually did create.
Ensure we match kernel behavior by fixing up prefixes for dumb router
advertisement services.
All NMObjects created in response to property changes were getting
leaked, which in particular included all NMAccessPoint objects, which
meant that after disconnecting and reconnecting a wifi interface some
number of times (depending on how many access points were in the
area), gnome-shell would be watching so many D-Bus AccessPoint objects
(most of which didn't exist any more) that it would hit dbus-daemon's
limit on the number of match rules you can register, which meant that
NMActiveConnections created after that point wouldn't be able to
register for PropertiesChanged notifications, which meant that the
network status icon would get out of sync.
- completion now works for command shortcuts too
nmcli> g ethe<TAB>
- completion now allows leading spaces
nmcli> desc wifi.ss<TAB>
- fix completion of settings when property is already there
nmcli> set con<TAB>.id
- fix completion of properties in setting.property
nmcli> des con.inter<TAB> bla
This fixes an error in the following example:
$ nmcli con add type bridge con-name test-bridge <TAB>
Before, general options such as 'autoconnect' and 'ifname' were
wrongly not suggested.
Signed-off-by: Thomas Haller <thaller@redhat.com>
g_child_watch_add only emits one signal and gets automatically
removed from the source. No need for double removal, so unset
teamd_process_watch before calling teamd_cleanup.
Signed-off-by: Thomas Haller <thaller@redhat.com>
g_bus_watch_name immediatly emits a vanished signal, if the name does not exist
at the begining. So the first signal, does not indicate an actual change of
state and must be ignored.
Signed-off-by: Thomas Haller <thaller@redhat.com>
teamd was being watched using g_bus_watch_name(). But when the NM team device
was destroyed NM tried to remove the watcher with g_source_remove() instead of
g_bus_unwatch_name(). Thus the watcher was not removed and
teamd_dbus_appeared() was called on disposed device.
https://bugzilla.redhat.com/show_bug.cgi?id=1013593#c28
Signed-off-by: Thomas Haller <thaller@redhat.com>
