Carrier state is only valid if the network interface is IFF_UP, because drivers
are not required to do carrier detection if the device is not up. Thus, if NM
is the first process to set the interface IFF_UP, there may be a short delay
while the driver performs carrier detection. NetworkManager must suppress
"startup complete" during this delay to ensure that the carrier state is known
before making startup property decisions.
Previously, when NetworkManager set the interface IFF_UP, the interface would
not have a carrier for a few seconds until the driver's carrier detection was
done. Since the interface had no carrier, NetworkManager could not begin
connection activation on the interface, and the interface would not suppress
the "startup complete" transition. Thus, NetworkManager would declare that
startup was complete prematurely and anything depending on startup network
connectivity would fail as no interfaces were active.
https://bugzilla.redhat.com/show_bug.cgi?id=1034921https://bugzilla.redhat.com/show_bug.cgi?id=1030583
This lets us do two things:
1) ensure that pending actions are unique and not doubly added/removed
2) we can (eventually) print out the pending action list for debugging
However, since we cannot have two pending actions with the same name at
the same time, we need to change the queued device state actions to
include the state name. But that makes debugging even more descriptive
so it's a bonus.
Simplify check in nm_ap_set_ssid(). Note that previously there was
no bug here in case of self assignment, this just makes it more
explicit.
Signed-off-by: Thomas Haller <thaller@redhat.com>
We should use ap_scan=1 *except* for AP/IBSS/AdHoc, where ap_scan=2 is
required. ap_scan for "infra" mode is all historical and was for old,
crappy, and proprietary drivers that we should really stop hacking stuff
for. Those drivers did not support probe-scanning for hidden APs and
thus the supplicant just had to send all the config to the driver and
hope things worked.
All relevant and non-crappy drivers these days support at least one SSID
probe and thus is_broadcast affecting ap_scan should no longer be
something we support. If you have an old, crappy
WEXT/proprietary/staging driver, and you use hidden APs, you're doing it
wrong.
So, in short, we must keep the ap_scan=2 logic for AP+AdHoc, but we can
remove the is_broadcast and has_scan_capa_ssid arguments and the code
where they change ap_scan.
https://bugzilla.redhat.com/show_bug.cgi?id=1025371#c18
Signed-off-by: Thomas Haller <thaller@redhat.com>
rh #1025371 reports a crash in handle_ip_config_timeout() because
nm_device_wifi_get_activation_ap() did not return any access point
(line nm-device-wifi.c:3105).
In order to fix this, the whole handling of get_activation_ap vs.
current_ap was reworked and cleaned up.
This also fixes a memory leak in line nm-device-wifi.c:2111.
Also rename the functions get_active_ap (to find_active_ap) and
set_active_ap (to set_current_ap), because these two functions were not
getter/setter for an 'active_ap' property (as would be expected from the
previous name).
Also ensure, that a fake AP is never in the list of valid APs without
also being the current_ap. Whenever we reset a fake current_ap, the AP
gets removed.
https://bugzilla.redhat.com/show_bug.cgi?id=1025371
Signed-off-by: Thomas Haller <thaller@redhat.com>
This reverts commit 788eed99de.
Revert the previous workaround for the crash before cleanup the handling
of AP in nm-device-wifi.c
Signed-off-by: Thomas Haller <thaller@redhat.com>
It is an extension compared to initscripts (not in sysconfig.txt). But it is
necessary for preserving dhcp-send-hostname. Missing DHCP_SEND_HOSTNAME is
treated as "yes", which matches dhcp-send-hostname default value being TRUE.
https://bugzilla.redhat.com/show_bug.cgi?id=1001529
Workaround a serious issue, that a connection that failed to activate
might retry to autoconnect indefinitly.
In NMPolicy, device_state_changed() decrements the retry count for
autoconnect. But immediatly it calls nm_connection_clear_secrets(),
which in turn triggers an NM_SETTINGS_SIGNAL_CONNECTION_UPDATED signal.
The problem is, that connection_updated() resets the try count again to
the default, and thus, the counter was effictivly not decremented.
For now, do not reset the retry count in connection_updated(). This
works arount the issue, but means, that when a user changes the
connection, it is not immediatly retried to autoconnect (as the intent
originally was). This will be fixed later.
https://bugzilla.redhat.com/show_bug.cgi?id=1040528
Signed-off-by: Thomas Haller <thaller@redhat.com>
Attempting an immediate reconnect if the peer terminates the connection
sometimes results in the peer not being ready to negotiate a new
connection, while a short delay allows the peer to correctly tear
down the old connection and get listen for a new one. Introduce
a short delay when activating a PPPoE connection if a PPPoE
connection was recently deactivated.
https://bugzilla.redhat.com/show_bug.cgi?id=1023503https://bugzilla.redhat.com/show_bug.cgi?id=602265
Rebased to master by jklimes.
Keyfile plugin writer had a bug, when writing IP6 routes with gateway
"::". Instead of writing "net/plen,,metric" it wrote "net/plen,metric".
- fix this bug and add test cases. Also, add a workaround to reader, to
accept such wrongly written IP6 routes as valid.
- change the writer for IP4 addresses, IP4 routes and IP6 routes to
omit the gateway and the metric, if it is 0.0.0.0/::/0, respectively.
Also change the reader, to accept such empty gateway as valid.
It only omits the gateway, if the metric is not 0, this means it would
write:
route1=1.2.3.4/24,0.0.0.0,1
instead of
route1=1.2.3.4/24,,1
Both representations are now supported by the reader, but older plugin
versions could only read the former (thus, we keep writing that
version).
With a metric of zero, it would instead write:
route1=1.2.3.4/24
- some refactoring and code cleanup. Fix a memory leak.
https://bugzilla.gnome.org/show_bug.cgi?id=719851
Signed-off-by: Thomas Haller <thaller@redhat.com>
ip6_addr_to_string did assume, that inet_ntop might write a scope id to
the result. But it does not (and cannot, because struct in6_addr does
not have any interface identifer).
Simplify and rework the function.
Also fix a memory leak.
https://bugzilla.gnome.org/show_bug.cgi?id=711684
Signed-off-by: Thomas Haller <thaller@redhat.com>
When a gateway is not in the prefix of any of the interface's IP addresses,
NetworkManager adds a static host route to the gateway through the
interface to ensure the gateway can be reached. That route will not
be part of the persistent connection (since it was added automatically)
but would normally be picked up by connection generation. This would
cause the generated connection not to match with the persistent
connection, because the persistent connection does not have the host
route. Ignore the gateway host route when capturing the interface's
existing IP configuration.
When generating a connection, if the device has no non-link-local IPv6
address, then it's unclear whether (a) the connection was link-local
originally, or (b) the connection was 'auto' but IPv6 failed or timed
out.
In this case, if there is a persistent connection that is 'auto' but
the generated connection is 'link-local', the persistent connection
should be used.
Add a more-testable framework for doing the connection matching to
handle this.
INFERRABLE means the opposite of CANDIDATE; a property which NetworkManager
can read ("infer") from the system or the kernel when generating
connections. CANDIDATE isn't a great name and thus dies.
platform/nm-linux-platform.c: In function 'build_rtnl_addr':
platform/nm-linux-platform.c:116:15: error: 'bcaddr' may be used uninitialized in this function [-Werror=maybe-uninitialized]
nl_addr_put (*object);
^
platform/nm-linux-platform.c:2264:32: note: 'bcaddr' was declared here
auto_nl_addr struct nl_addr *bcaddr;
^
We can only create virtual interfaces when the connection has autoconnect
property *and* the device was not manually disconnected before.
Without this commit NetworkManager would auto-activate all virtual connections
when a change was done (e.g. new virtual connection was addded).
When a device is initialized to be managed, it will transition through states
unmanaged -> unavailable -> disconnected. We don't want to remove software
devices during this initial transition to disconnected, because it prevents
auto-activation.
Test case:
$ nmcli con add type vlan ifname myvlan dev eth0 id 123
NM should immediately create myvlan interface and automatically activate it.
https://bugzilla.redhat.com/show_bug.cgi?id=1035814
When an activation request requires secrets, if there is a secret
agent in the process that made the request, then prefer that to all
other secret agents.
Rather than explicitly passing around a UID and a flag saying whether
or not it's relevant.
(This also fixes a bug where the wrong UID was being recorded in
nm-settings-connection.c::auth_start(), which caused problems such as
agent-owned secrets not getting saved because of a perceived UID
mismatch.)
Slaves have no IP configuration and should not have any IP settings.
This fixes connection comparison between generated slave connections
and persistent slave connections, as persistent slave connections won't
have any IP configuration.
This reverts commit 9a019f1fb5.
Generic connections should be bound to their interface names in a more generic
way instead of in nm-device.c. The Generic device itself should set the
attributes it needs when generating the connection, like other device types do.
This will be done in a following commit.
If the connection describes a bridge/bond/team/etc slave, where the
slave setting (like NMSettingBridgePort or NMSettingTeamPort) has all
default values, the setting does not get written out because the
plugin does not write default values. But then when reading the
connection back in, we need to add that all-default slave type setting
since it's required for a valid connection.
Zero values are actually valid values for various bridge options
and should be written out. Otherwise, when reading the property
back in, it gets assigned the default value which is often not
zero, causing the wrong value to be set in the connection.
Only properties with default values should not be written out.
In the migration to NMPlatform, support for ptp/peer addresses was
accidentally dropped. This broke OpenVPN configurations using 'p2p'
topology, which send a different peer address than the local address
for tunX, plus the server may also push routes that use the peer
address as the next hop. NetworkManager was unable to add these
routes, because the kernel had no idea how to talk to the peer,
because the peer's address was not assigned to any interface or
reachable over any routes.
Partly based on a patch from Dan Williams.
dhcpcd v5.99 and later automatically enabled IPv6 behavior unless
specifically disabled. This is undesirable for two reason:
1) dhcpcd sends IPv4 Router Solicitations, which NetworkManager
handles itself, so there's no need to do it twice. NetworkManager
knows better than dhcpcd whether IPv6 is supposed to be used for
that interface or not.
2) Some devices don't react well to IPv6 when they aren't expecting
it. For example, older Qualcomm Gobi-based devices will listen
for Router Solicitations and attempt to set up IPv6, but if other
settings are not done correctly, or the firmware doesn't actually
support it, the firmware will then crash. So simply upgrading your
dhcpcd from 5.x to 6.x magically stops WWAN working for these
devices.
Previously, the device activation would stall in this case, because
the code wasn't expecting it to happen. In particular, this happens
when trying to assume a device that is up but has no IP config.
https://bugzilla.gnome.org/show_bug.cgi?id=715181
When request for getting secrets is being freed in request_free(),
cancel_callback is get_cancel_cb(). It uses parent->current as a secret agent
object. However, this object can be already freed and thus there is a problem
getting priv in nm_secret_agent_cancel_secrets:
g_return_if_fail (self != NULL);
priv = NM_SECRET_AGENT_GET_PRIVATE (self);
(gdb) p self
$66 = (NMSecretAgent *) 0x7fae9afd42e0
(gdb) p *self
$67 = {parent = {g_type_instance = {g_class = 0x0}, ref_count = 0, qdata = 0x0}}
#0 nm_secret_agent_cancel_secrets (self=0x7fae9afd42e0, call=0x1) at settings/nm-secret-agent.c:325
#1 0x00007fae9a774882 in request_free (req=0x7fae9afc48f0) at settings/nm-agent-manager.c:496
#2 0x00007fae967b251a in g_hash_table_remove_internal (hash_table=0x7fae9aefdf00, key=0x2, notify=1) at ghash.c:1276
#3 0x00007fae9a72b340 in dispose (object=0x7fae9af77200) at nm-activation-request.c:446
#4 0x00007fae96cbeee8 in g_object_unref (_object=0x7fae9af77200) at gobject.c:3160
#5 0x00007fae9a73d87c in _active_connection_cleanup (user_data=<optimized out>) at nm-manager.c:359
#6 0x00007fae967c32a6 in g_main_dispatch (context=0x7fae9aedb180) at gmain.c:3066
#7 g_main_context_dispatch (context=context@entry=0x7fae9aedb180) at gmain.c:3642
#8 0x00007fae967c3628 in g_main_context_iterate (context=0x7fae9aedb180, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713
#9 0x00007fae967c3a3a in g_main_loop_run (loop=0x7fae9aedb860) at gmain.c:3907
So we need to ref() 'agent' when adding it to pending list, so that the object
is not freed if the secret agent unregisters and is removed.
Test case:
1. run NM and nm-applet
2. activate a Wi-Fi network
3. nm-applet will ask for a password; ignore the popup window and kill nm-applet
4. start nm-applet again
5. click the same Wi-Fi network in nm-applet
6. NM will experience problems in nm_secret_agent_cancel_secrets() or crashes
(the procedure may not be 100%, but reproduces most of the time)
https://bugzilla.redhat.com/show_bug.cgi?id=922855
GLib-CRITICAL **: g_hash_table_iter_next: assertion 'ri->version == ri->hash_table->version' failed
It is not allowed to modify hash table while it is iterated. Unfortunately,
request_remove_agent() may remove the request from the 'requests' hash table,
making it not usable in the loop hash table looping.
We need to store the request into a temporary list and call request_next_agent()
on them later (after the hash loop).
Test case:
1. start NM and nm-applet
2. activate a Wi-Fi WPA connection
3. nm-applet displays a dialog asking for a password
4. kill nm-applet
5. NetworkManager removes the nm-applet's secret agent
and runs into removing the request from hash table in the
iterating loop (via get_complete_cb)
#0 get_complete_cb (parent=0x7f3f250f2970, secrets=0x0, agent_dbus_owner=0x0, agent_username=0x0, error=0x7f3f250f7830, user_data=0x7f3f25020e10)
at settings/nm-agent-manager.c:1111
#1 0x00007f3f23b46ea5 in req_complete_error (error=0x7f3f250f7830, req=0x7f3f250f2970) at settings/nm-agent-manager.c:509
#2 request_next_agent (req=0x7f3f250f2970) at settings/nm-agent-manager.c:615
#3 0x00007f3f23b48596 in request_remove_agent (agent=0x7f3f250f4a20, req=0x7f3f250f2970) at settings/nm-agent-manager.c:631
#4 remove_agent (self=<optimized out>, owner=0x7f3f250dbff0 ":1.275") at settings/nm-agent-manager.c:130
#5 0x00007f3f23b4868d in impl_agent_manager_unregister (self=0x7f3f25020e10, context=0x7f3f250f5480) at settings/nm-agent-manager.c:374
#0 0x00007f3f1fb9c4e9 in g_logv (log_domain=0x7f3f1fbfef4e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff156b77c0) at gmessages.c:989
#1 0x00007f3f1fb9c63f in g_log (log_domain=log_domain@entry=0x7f3f1fbfef4e "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL,
format=format@entry=0x7f3f1fc0889a "%s: assertion '%s' failed") at gmessages.c:1025
#2 0x00007f3f1fb9c679 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7f3f1fbfef4e "GLib",
pretty_function=pretty_function@entry=0x7f3f1fc03c30 <__PRETTY_FUNCTION__.4571> "g_hash_table_iter_next",
expression=expression@entry=0x7f3f1fc038f0 "ri->version == ri->hash_table->version") at gmessages.c:1034
#3 0x00007f3f1fb849c0 in g_hash_table_iter_next (iter=<optimized out>, key=<optimized out>, value=<optimized out>) at ghash.c:733
#4 0x00007f3f23b484e5 in remove_agent (self=<optimized out>, owner=0x7f3f250dbff0 ":1.275") at settings/nm-agent-manager.c:129
#5 0x00007f3f23b4868d in impl_agent_manager_unregister (self=0x7f3f25020e10, context=0x7f3f250f5480) at settings/nm-agent-manager.c:374
