If the hostname is "foo.example.com" then we want to add
"search example.com" to resolv.conf, but if it's just "example.com",
we don't want to add "search com" (rh #812394).
So if NetworkManager is being built with recent libsoup, use
soup_tld_domain_is_public_suffix() to double-check the domain before
adding it. (If it is not being built with libsoup, or is being built
with too old a version, we just skip that test, keeping the old
behavior.)
NMPolicy only updates the NMDnsManager's hostname when it changes,
which previously did not include at startup. Meaning if your hostname
never changed, NMDnsManager would never learn it (and so would never
add an appropriate "search" line to resolv.conf). Fix that.
If NM is not explicitly managing resolv.conf (either due to the "dns"
NetworkManager.conf setting, or because resolv.conf is immutable),
then don't try to parse nameservers out of it when capturing a
connection, since there's no reason to believe that the name servers
there are related to any particular connection.
If /etc/resolv.conf has the immutable flag set, then behave as though
"dns=none" was specified (rather than repeatedly trying and failing to
update it).
Add a property indicating whether NMDnsManager is ignoring
resolv.conf, managing it by explicitly putting nameservers into it, or
managing it by proxying to another service (eg, dnsmasq) with
"nameserver 127.0.0.1".
NM bounces devices on suspend/resume, since some buggy drivers require
it. However, there's no need to take down virtual devices. (In
particular, we don't want to take down libvirt's virbr0, since it
won't get automatically brought back up afterward.)
A lifetime of 0 means that the domain or server should no longer
be used, so if we get an RA with a zero-lifetime DNS server or
domain that we haven't seen before, don't bother adding it to the
list.
DNS servers and domains that are already known and become zero
lifetime in the next RA are already correctly handled by
clean_dns_servers() and clean_domains().
The DNS server and domain timestamps and lifetimes weren't updated
when a new RA was received. When half the lifetime for either of
them had passed, clean_dns_servers() and clean_domains() request a
Router Solicitation to ensure the DNS information does not expire.
This obviously results in a new Router Advertisement, but since the
timestamps don't get updated, clean_dns_servers() and clean_domains()
simply request another solicitation because 'now' is still greater
than half the old lifetime. This casues another solicit request,
which causes another RA, which... etc.
https://bugzilla.redhat.com/show_bug.cgi?id=1044757https://bugzilla.gnome.org/show_bug.cgi?id=720760
Add IP and DHCP config properties to the D-Bus ActiveConnection
objects.
For device connections, this is redundant with the properties already
on the Device object, but for VPN connections, this information was
not previously available.
When a new activation request is received, NetworkManager creates a new
NMActiveConnection to track that request. The device may already be activated,
in which case NetworkManager stops the old activation and starts the new one,
but both exist in parallel for a short period of time. If the old
NMActiveConnection is activating and already has a pending 'activation'
action, when the new NMActiveConnection adds its own 'activating' action,
they will clash. This is fixed by making each NMActiveConnection's activation
pending action uniquely named.
This fixes a g_warning with the following back trace:
#0 0x000000328224edfd in g_logv () from /lib64/libglib-2.0.so.0
#1 0x000000328224efe2 in g_log () from /lib64/libglib-2.0.so.0
#2 0x000000328224f2e6 in g_warn_message () from /lib64/libglib-2.0.so.0
#3 0x0000000000440aee in nm_device_add_pending_action (device=0x14002e0, action=0x50704a "activation") at devices/nm-device.c:7172
#4 0x000000000047525c in nm_active_connection_set_device (self=0x141b3c0, device=0x14002e0) at nm-active-connection.c:364
#5 0x0000000000475ec1 in set_property (object=0x141b3c0, prop_id=11, value=0x7fff7ff36c20, pspec=0x1405f70) at nm-active-connection.c:647
#6 0x0000003282615d3e in g_object_newv () from /lib64/libgobject-2.0.so.0
#7 0x00000032826162e6 in g_object_new_valist () from /lib64/libgobject-2.0.so.0
#8 0x0000003282616654 in g_object_new () from /lib64/libgobject-2.0.so.0
#9 0x0000000000474193 in nm_act_request_new (connection=0x13bb0e0, specific_object=0x0, subject=0x1447740, device=0x14002e0) at nm-activation-request.c:376
#10 0x000000000048e477 in _new_active_connection (self=0x13e8060, connection=0x13bb0e0, specific_object=0x0, device=0x14002e0, subject=0x1447740, error=0x7fff7ff36f90) at nm-manager.c:2947
#11 0x000000000048ed77 in impl_manager_activate_connection (self=0x13e8060, connection_path=0x134d590 "/org/freedesktop/NetworkManager/Settings/9", device_path=0x134d550 "/org/freedesktop/NetworkManager/Devices/1",
specific_object_path=0x0, context=0x143a9b0) at nm-manager.c:3206
#12 0x00000000004876c8 in dbus_glib_marshal_nm_manager_VOID__BOXED_BOXED_BOXED_POINTER (closure=0x7fff7ff37220, return_value=0x0, n_param_values=5, param_values=0x1448830, invocation_hint=0x0,
marshal_data=0x48e9dd <impl_manager_activate_connection>) at nm-manager-glue.h:189
#13 0x0000003284a0d6a9 in object_registration_message () from /lib64/libdbus-glib-1.so.2
#14 0x000000348ea1ce66 in _dbus_object_tree_dispatch_and_unlock () from /lib64/libdbus-1.so.3
#15 0x000000348ea0fa31 in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#16 0x0000003284a0acc5 in message_queue_dispatch () from /lib64/libdbus-glib-1.so.2
#17 0x0000003282247df6 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#18 0x0000003282248148 in g_main_context_iterate.isra.22 () from /lib64/libglib-2.0.so.0
#19 0x000000328224854a in g_main_loop_run () from /lib64/libglib-2.0.so.0
#20 0x000000000042c6c0 in main (argc=1, argv=0x7fff7ff379b8) at main.c:629
Signed-off-by: Thomas Haller <thaller@redhat.com>
Use a GSList of the string values, instead of an array of GQuarks.
Using GQuarks does not allow to add arbitrary strings, because they
would leak the internalized strings. The next patch will begin
using unique, non-const action strings.
Given the rather small number of expected pending states, a singly
linked list seems appropriate.
Signed-off-by: Thomas Haller <thaller@redhat.com>
(some fixes and simplifications by dcbw based on patch reviews)
deviceid_to_index returns -1 when the deviceid was not found.
Assiging it to an unsigned variable is wrong and would result
in printing an error message when trying to remove the non existing
index.
Signed-off-by: Thomas Haller <thaller@redhat.com>
A fake AP should be the current access point. The code in act_stage1_prepare
violated this invariant for a short time by emitting signals before
setting current_ap. Reorder statements, so that
- fake AP gets created and added to ap_list
- fake AP gets set as current_ap (suppressing notify signals)
- emit ACCESS_POINT_ADDED signal
- thaw notify::NM_DEVICE_WIFI_ACTIVE_ACCESS_POINT signal
When performing a series of actions that emit several signals, it is
often difficult to emit them in an order, so that listeners get a
consistent view. With this change, listeners will get ACCESS_POINT_ADDED
signal, and the current ap already being set to the fake_ap. Next they
get notify::NM_DEVICE_WIFI_ACTIVE_ACCESS_POINT. There is no perfect
solution, but this way it makes slightly more sense.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This fixes automatic activation after changes in
commit ff7e47a418.
When a connection is deactivated impl_manager_deactivate_connection() is called
and the device goes to NM_DEVICE_STATE_DISCONNECTED. nm_device_state_changed()
then issues "state-changed" signal. The signal is connected to by various
listeners. The most interesting ones for this case are NMPolicy and
NMActiveConnection.
The problem is that NMPolicy's device_state_changed() is processed first and
thus in schedule_activate_check() we still have the old active connection
present (in ACTIVATED state).
This commit fixes the issue by connecting to "state-changed" signal using
g_signal_connect_after() in NMPolicy. This ensures NMPolicy's state-changed
handler is called after active connections are processed.
https://bugzilla.redhat.com/show_bug.cgi?id=1033187
The NMActiveConnection class tracks the full activation request, and internal
activation requests go through the same process as external ones, including
some authentication. Sometimes that means activation is scheduled, control
returns to the mainloop, and then the activation proceeds from an idle
handler.
Unfortunately, that means that adding a pending "activation" action from
nm-device.c doesn't always work, since there is a short window between when
the activation is started in nm-manager.c (in nm_manager_activate_connection())
and when the device actually changes state. Inside that window, the pending
actions may drop to zero, and startup will be declared complete before the
device actually starts activating.
Instead, ensure that the pending action is added when the internal activation
is actually started (eg, when NMActiveConnection receives the NMDevice object).
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>
