Coverity: CID 59378 (#1 of 1): Nesting level does not match indentation
(NESTING_INDENT_MISMATCH) This statement is indented to column 41, as if
it were nested within the preceding parent statement, but it is not.
nm_supplicant_manager_iface_get() would cache and reuse the supplicant
interface. But no ref-counting was in place so that the first user returning
the interface via nm_supplicant_manager_iface_release() would destroy the
instance for others.
This is broken for a very long time. Which shows that we hardly ever
have a cache-hit and usually create a new instance. So, instead of
letting nm_supplicant_manager_create_interface() check for existing
supplicant interface, always create a new instance. This also makes
sense, because we would expect that per ifname only one instance is
requested at a time. Also add an assertion that we don't return
multiple supplicant interface instances for the same ifname.
Drop nm_supplicant_manager_iface_release() in favor of requiring users
to unref the returned instance.
Also, use a GSList instead of a GHashTable for the cache.
Also, previously callers would pass @is_wireless to nm_supplicant_manager_iface_get(),
but the cache lookup did not consider that value. That doesn't matter
now as we always create a new instance.
https://bugzilla.redhat.com/show_bug.cgi?id=1298007
Also, don't only consider the @die_count whether to start the supplicant,
but check for is_available() -- which already considers @die_count and
@running.
If the list is expected to be modified, it also means that possibly
instances will be unrefed. Probably, not yet visited instances will
not be unrefed so there is no real problem.
Just be extra cautious and take a reference to all instances first.
If dnsmasq (or another DNS plugin) exits immediately (for example due
to an already used port), the DNS manager keeps restarting it forever,
wasting system resources and filling logs.
Add a simple rate-limiting mechanism.
https://bugzilla.gnome.org/show_bug.cgi?id=760691
Add a new object which implements the logic for announcing IP
addresses and detecting duplicates using arping.
Based-on-patch-by: Jiří Klimeš <jklimes@redhat.com>
The function can now be called on unrealized devices before the
initial unmanaged flags are set and for those devices
nm_device_get_managed() will return TRUE. Since we only accept
states > UNMANAGED, return early when the condition is not met.
Fixes the following failed assertion:
carrier_changed: assertion 'priv->state >= NM_DEVICE_STATE_UNAVAILABLE' failed
https://bugzilla.gnome.org/show_bug.cgi?id=760844
The availability checks are called from places that don't assume the device
will be removed mid-air. Call the removal routine only when we're the very
last thing that's being done.
During nm_device_unrealize(), the connection might still
have some connections that only get removed later. We must
garbage collect unrealized devices when they loose their
available-connections, not during unrealize.
Fixes: 436ec5b8e3
We possibly need the unrealized device for connections that need
this. nm_device_unrealize() will check if there are still any
available-connections and possibly emit DEVICE_REMOVED signal.
Fixes: 7e5f27a21c
Adding a route via iproute2 with explicit gateway 0.0.0.0
sets the route scope to GLOBAL, contrary to a on-link device-route
which has scope LINK.
Add a test adding two such routes.
Apply MTU and hop limit when managed or other flag is set as well. This wasn't
the case for the first RA and the previous commit made it slightly worse by
always ignoring it.
Fixes: ad2584c375
When a new device gets added or when an existing one changes name,
virtual connections that refer to it as parent device may become
ready, so let's try to activate them.
Previously we tried to activate virtual connections only on startup
and, after commit d8e1590c50 ("manager: retry device creation for
connection that would use a newly created device"), also when a
connection was added/changed, but this doesn't cover the case in which
a parent device appears or changes name at runtime.
https://bugzilla.redhat.com/show_bug.cgi?id=1275875
