Remove the HostnameThread stuff from nm-policy-hostname and just use
GResolver instead. Move the one remaining nm-policy-hostname function
into nm-policy.
Avoid warnings about GValueArray being deprecated by adding macros
that wrap G_GNUC_BEGIN_IGNORE_DEPRECATIONS /
G_GNUC_END_IGNORE_DEPRECATIONS around the GValueArray calls.
data_iface is the serial port over which PPP should be run, so
we need to preserve that and not overwrite it with the PPP interface
name. When reconnecting, pppd wants the TTY to run PPP over (eg the
ModemManager data_port like ttyUSB0) but if we overwrote that with
ppp0 on the last connection, that's extremely unhelpful and pppd will
fail to start.
When built with MM1 support, the restart handling code here would
fail for both old MM and new MM. The code should ignore the
name owner change even if the incoming bus name is *neither*
old MM nor new MM. It wasn't doing that.
Seems that NLM_F_CREATE isn't enough, we need to replace anything
that's already there. Oddly, this is even though we already cleaned
out anything that was already there.
Otherwise, priv->accept_ra_path would be NULL, which isn't very
useful and makes nm_utils_do_sysctl() angry. No reason we shouldn't
always create priv->accept_ra_path in the future though.
https://bugzilla.gnome.org/show_bug.cgi?id=691213
Add a "need_carrier" argument to nm_device_is_available(), to allow
distinguishing between "device is not available", "device is fully
available", and "device is available except for not having carrier".
Adjust various parts of NMDevice and NMManager to allow for the
possibility of activating a connection with :carrier-detect = "no" on
a device with no carrier, and to avoid auto-disconnecting devices with
:carrier-detect = "on-activate".
https://bugzilla.gnome.org/show_bug.cgi?id=688284
For settings corresponding to devices that have a :carrier property
(ie bond, bridge, infiniband, vlan, and wired), add a :carrier-detect
property specifying how that affects the connection:
yes: The connection can only be activated when the device
has carrier, and will be deactivated if the device loses
carrier (for more than 4 seconds).
no: The connection ignores carrier on the device; it can be
activated when there is no carrier, and stays activated
when carrier is lost.
on-activate: The connection can only be activated when the
device has carrier, but it will not be deactivated if the
device loses carrier.
https://bugzilla.gnome.org/show_bug.cgi?id=688284
Move some duplicated carrier-handling code into NMDevice (which can
introspect itself to see if it's a subclass that has carrier).
The "mostly ignore carrier" special handling for bridges and bonds is
now also handled as part of the NMDevice-level carrier handling.
https://bugzilla.gnome.org/show_bug.cgi?id=688284
The original used uuid_parse() but that function did not
work properly since the format of the machine-id is
not compatable with a real uuid. This patch adds a new
machine_id_parse() routine to correctly convert the
character string of hex digits to a 16 byte binary string.
nm_settings_connection_init() was calling nm_connection_set_path(),
but this was pointless since that would end up getting cleared by the
property's default value shortly after init() returned (and
claim_connection() depended on this). So remove that code.
https://bugzilla.gnome.org/show_bug.cgi?id=693829
GObject creation cannot normally fail, except for types that implement
GInitable and take a GError in their _new() method. Some NM types
override constructor() and return NULL in some cases, but these
generally only happen in the case of programmer error (eg, failing to
set a mandatory property), and so crashing is reasonable (and most
likely inevitable anyway).
So, remove all NULL checks after calls to g_object_new() and its
myriad wrappers.
https://bugzilla.gnome.org/show_bug.cgi?id=693678
g_malloc(), etc, never return NULL, by API contract. Likewise, by
extension, no other glib function ever returns NULL due to lack of
memory. So remove lots of unnecessary checks (the vast majority of
which would have immediately crashed had they ever run anyway, since
g_set_error(), g_warning(), and nm_log_*() all need to allocate
memory).
https://bugzilla.gnome.org/show_bug.cgi?id=693678
This reverts commit ff15a5e and adds netlink.h header file so that
we build on all systems. We haven't propery analyzed which systems
are affected and which are not.
If the Wifi device hadn't yet had a chance to transition away from
UNAVAILALBLE before the supplicant quit, the NMSupplicantInterface
would not be re-acquired becuase that was only happening from
the device state change handler when entering the UNAVAILALBE state,
and clearly setting the same state is NOP.
Since the old supplicant interface was torn down, and the wifi device
hadn't created a new supplicant interface (because it hadn't changed
state) nothing was listening for the supplicant to appear.
Fix that by ensuring that the wifi device reacquires a supplicant
interface whenever an old one is torn down and the device is enabled.
NetworkManager[3062]: <info> (wlan0): supplicant interface state: scanning -> down
NetworkManager[3062]: <info> (wlan0): device state change: config -> unavailable (reason 'supplicant-failed') [50 20 10]
NetworkManager[3062]: <info> (wlan0): deactivating device (reason 'supplicant-failed') [10]
NetworkManager[3062]: <info> wpa_supplicant started
NetworkManager[3062]: <info> wpa_supplicant stopped
NetworkManager[3062]: <info> (wlan0): supplicant interface state: starting -> down
<start new supplicant, nothing happens>
"config-changed" signal is added to dns-manager and emited when resolv.conf is
changed. Policy listens for the signal and restarts reverse-lookup in order to
get correct results.
If no config file was specified, and if no other plugins were given
on the command-line, the keyfile plugin would not be loaded. This
meant no connections would be read, and no connections could be
created either.
Always load the keyfile plugin.
This is a regression introduced by reworked active connections tracking:
7258dd270f core: add the NM_ACTIVE_CONNECTION_STATE_DEACTIVATED state
59420add04 core: track active connections directly in the manager
Because nm-manager.c:active_connection_state_changed() postpones active
connection removal to an idle handler (to be able to receive last property
change notifications), we also need to ensure that NM_ACTIVE_CONNECTION_STATE_DEACTIVATED
state is not changed again in the meantime in nm-activation-request.c:device_state_changed().
After the NMActRequest was deactivated (which is a terminal state) it was still
listening to state changes of its child NMDevice which could be starting a
new activation request. Thus the new activation's NMDevice state would cause
the old activation request's state to change from DEACTIVATED. To fix this
stop listening to the child NMDevice when DEACTIVATED becuase there's no point
to doing so anyway.
Reproducer:
Just activate already active connection by clicking it in nm-applet or
run 'nmcli con up id <connnection name>' several times, and then check
active connections with 'nmcli c s'.
Some wireless devices don't support Ad-Hoc mode. Expose this fact in
the wireless capabilities so that clients can disable the hot-spot
option if neither CAP_ADHOC nor CAP_AP is available.
https://bugzilla.gnome.org/show_bug.cgi?id=692869
This is a regression introduced by reworked active connections tracking:
7258dd270f core: add the NM_ACTIVE_CONNECTION_STATE_DEACTIVATED state
59420add04 core: track active connections directly in the manager
Because nm-manager.c:active_connection_state_changed() postpones active
connection removal to an idle handler (to be able to receive last property
change notifications), we also need to ensure that NM_ACTIVE_CONNECTION_STATE_DEACTIVATED
state is not changed again in the meantime in nm-activation-request.c:device_state_changed().
Reproducer:
Just activate already active connection by clicking it in nm-applet or
run 'nmcli con up id <connnection name>' several times, and then check
active connections with 'nmcli c s'.
The 'GDBusObjectManagerClient' won't signal added or removed objects when it
was created but no name owner was available in the bus. We can still use it for
name-owner changes, but in order to have added/removed object signals, we'll
need to re-create the whole 'MMManager' when we know the service came alive in
the bus.
See GLib/GIO/GDBus bug:
https://bugzilla.gnome.org/show_bug.cgi?id=693285
Various bits of code want the network interface which an IP config
came from, for example when distinguishing which interface to
send DNS requests to when the DNS servers are link-local. DNS
plugins may also want this data for various reasons.
So it makes sense to attach the interface name to the IP config
object when the DNS manager gets it, so that later DNS updates
that don't have any interface information (hostname changes, etc)
can still generate correct DNS information.
This also eliminates the "last_iface" hack, which was often
inaccurate.
It also now sends "NetworkManager" to SUSE netconfig as the
interface name, because the DNS information being sent is already
merged/prioritized and not specific to a network interface, so
it's time to stop lying about where it came from.
DHCPv6 RFCs require the DUID to be constant over time and to
be used as a permanent identifiers of the machine. This precludes
using a network interface MAC address since the MAC address may
change, and there may be more than one network interface installed.
Storing the DUID causes problems when an OS image is cloned between
virtual or physical machines because then the saved DUID is no longer
unique.
To fix all these issues, generate the DUID from the machine's hashed
machine-id, which is already a unique identifier of the machine and
will always be present because dbus requires it, and NM requires
dbus. It is assumed administrators will change the machine-id when
cloning an OS image; thus they only have to update one file, not
two (machine-id and the stored DUID).
Administrators may still override the machine-id-derived DUID by
setting a DUID in the default dhclient config file or the
interface-specific dhclient config files.
dhclient no longer saves a generated DUID to the config files,
because the default DUID will always be regenerated from
the machine-id on startup and thus always stable.
We avoid requesting to auto-start the service when the 'MMManager' is created,
so that we can use it to follow name-owner changes (when auto-starting
requested the 'MMManager' creation may fail).
We still handle the periodic poking to the service, but instead of re-creating
the 'MMManager', we just call org.freedesktop.DBus.Peer.Ping().
Like we do when the user sets the Wireless Enabled property at
runtime, ensure the kernel's softblock state is synced with the
user's WiFi enable preference at startup. This helps compensate
for BIOSes that don't save rfkill state over reboots and ensures
consistency of between startup and runtime Wireless Enabled
property behavior.
Suggested by John G.
Some devices (namely PPPoE (pppX), ADSL (nasX, pppX), and
mobile broadband (pppX, bnepX)) create a kernel netdevice for IP
communication (called the "IP interface" in NM) as part of the
connection process and thus the IP interface lifetime does not
correspond to the NMDevice lifetime. For these devices we must
ignore removal events for the IP interface name otherwise the
NMDevice would be removed.
Caused by 8cce42f2.
For example, this bug caused the NMDeviceBt to be removed when
a PAN connection's bnepX interface went down in response to a
terminated Bluetooth connection, which of course means that
you can't restart the PAN connection as your phone is no longer
in the NM device list.
Until we handle bridges non-destructively, only manage bridges
created by NM. When quitting write out a file listing all
bridges created by NM and a timestamp, and when starting read
that file and if the timestamp is within 30 minutes, manage
any bridge that was listed in that file. This scheme, while
not foolproof (eg, if NM crashes), should ensure that NM can
recognize bridges it created if it's restarted. The file
is stored in /run or /var/run, which is cleaned each restart,
ensuring that the state does not persist across reboots.
If an automatic or user-initiated activation request for
a bridge NM does not manage is received, that request is
denied. Only if the bridge interface does not yet exist, or
was present in the managed bridges file, will an
NMDeviceBridge be created and activation be possible.
If the IP configuration requires slaves/ports, starting IP configuration
before the master device has a carrier (which means at least one slave
or port has a carrier and the device is initialized) is pointless, and
will just take longer or fail. Recent kernels have cleaned up carrier
handling on bridge/bond devices and the carrier is now a reliable
indication of whether or not the master device is ready to send/receive
traffic. Thus, if we don't have a carrier, obviously no IP configuration
that depends on connectivity is going to work.
