Some rfkill drivers (sony-laptop, ideapad-laptop, classmate-laptop,
etc) register their rfkill drivers under the "acpi" subsystem instead
of the platform subsystem, but the semantics are the same.
Implements a new property that provides a list of currently
available connections a device could connect to. For example
if a connection for a particular wireless connection exists and
that wireless network appears in the scan list it would show in the
AvailableConnections property of the device.
(dcbw: found a slightly cleaner way to do this; it's a lot like the
check_connection_compatible class method, except it deals with
live network data too. So convert the subclass methods to
just check additional live network data, and have the base
device class handle adding the connection to the hash and all
the associated signalling. Also fix a bug where the available
connections were not updated when a device moved from UNAVAILABLE
to available, its available connections were not updated)
WiMAX failed distcheck if the iwmxsdk devel files were installed but
--enable-wimax=no was used, since the distcheck configure bits found
the iwmxsdk headers, defaulted WiMAX support to 'on', and then proceeded
to use the generated headers from the top srcdir, where of course
wimax was turned off (due to --enable-wimax=no). Instead, everything
should use the headers from the builddir, which reflects the options
that 'make distcheck' actually selects.
At the same time, re-order various includes everywhere to ensure that
the builddir paths come before the srcdir paths to prevent this from
happening in the future.
If the interface already exists, the compat code would fail. Fix that
and clean up the function. Also double-check that an existing VLAN
interface that has the name we expect also has the master and VLAN
ID we expect.
libnl2 and earlier do not implement rtnl_link_get_kernel() and
thus we need compat code to determine whether an interface is
a bond or a VLAN. Previously, the VLAN code would simply assert
and cause NM to exit when running with libnl2 or earlier because
the interface type could not be determined.
The enum generator stuff apparently includes any #include in source or
header files that it's given, which was causing nm-enum-types.c to
include files from the Intel WiMAX SDK even when WiMAX wasn't enabled.
We don't use the default dnsmasq directory because packages often drop files
there that don't take account of NM's specific use-case and end up conflicting
with the specific local caching nameserver functionality that NM uses dnsmasq
for. NM's private dnsmasq is orthogonal to whatever global dnsmasq
daemon may be running, and with that daemons configuration.
(dcbw: change directory to private one)
If bluez is started by systemd but for some reason is not set to
be D-Bus activated (as seems to be the case on Fedora 16 and later),
then don't emit a warning.
NM was requiring that bond slaves have either no IP config or an
explicit "none"/"disabled" config. But the system scripts just ignore
any IP config that is present on a slave, so change NM to do that too
(but warn about it).
https://bugzilla.redhat.com/show_bug.cgi?id=838907
The DNS change frequency reduction patches mistakenly changed the signature
of the VpnStateChanged signal. Fix that, since we try really really
hard not to break the D-Bus API in stable branches. My bad...
Allows agents to provide different behavior depending on whether the
secrets request was initiated by a user (eg by picking a connection
from a UI menu or by 'nmcli con up') or was automatically started by
NetworkManager.
See https://bugzilla.gnome.org/show_bug.cgi?id=660293
Move ra_flags modifications to a dedicated function that
logs the change (if any). Also improve device_set_state()
so that both functions return TRUE if the value actually
changes.
This patch lets pppd negotiate IPv6 parameters using IPV6CP. It allows
dual-stack mobile broadband to work correctly.
Due to the fact that ModemManager hard-codes use of IPv4-only PDP type,
the PDP context must manually be defined first using for example
AT+CGDCONT=1,"IPV4V6","apn". (ModemManager does not overwrite an
already-defined PDP context with the correct APN.)
IPV6CP is not considered essential, so when connecting using an IPv4-
only PDP context, pppd gives up after a retransmitting a few IPV6CP
ConfReqs. The retransmissions happen asynchronously, pppd nor NM waits
for them to finish before activating the IPv4 part of the connections.
The patch also makes pppd support IPv6-only connections (because IPCP
isn't considered essential by pppd either), however NM will currently
fail the entire connection if IPCP/IPv4 doesn't succeed.
If the plugin says the user-provided secrets are insufficient,
make sure we fail instead of potentially overrunning the secrets
counter (which triggered an assert).
When the last character of the PSK was a backslash and the whole PSK was
enclosed in single quotes, the unquoting/unescaping code mistakenly took
trailing \' as an escaped quote and thus changed \ to '.
See also 79757f10f3 (that introduced the code).
This commit includes Dan Winship's implementation of IPv6
router solicitation. It also uses it as a last resort
for RDNSS and DNSSL lifetime expiry. While using RS to prevent
lifetime expiry may be deprecated and removed in the future,
the RS implementation is useful in other places too.
It can be also viewed as a last resort if commit e1cfdd5 gets
reverted/modified or if it does not work under some weird
circumstances.
It also includes improvements by cyphermox and me.
RFC 6106 says, section 5.1 says:
In order to provide fixed hosts
with stable DNS service and allow mobile hosts to
prefer local RDNSSes to remote RDNSSes, the value of
Lifetime SHOULD be bounded as
MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval
I have reported and repeatedly confirmed that values in this interval
trigger frequent RDNSS expiration on unreliable links such as 802.11
wifi. Wireless links *do* have packet loss and actually have a *much*
worse multicast packet loss than unicast. And regular router
advertisements are sent as multicast packets (in multicast frames).
In case of RDNSS expiration, NetworkManager tears down the whole
connection. That of course affects IPv4 networking as well as IPv6.
In a typical wireless network with radvd serving RDNSS it leads to
dropping network connection every ~10 minutes.
This commit improves the previous hack in 0b8ee13 by enforcing a minimum
lifetime of two hours (7200 seconds), which is four times the maximum
allowed value for MaxRtrAdvInterval (see below). We could use
AdvDefaultLifetime instead (as suggested by tore_ on IRC) but it doesn't
seem to be accessible through netlink.
RFC 4861 Neighbor Discovery for IP version 6 (IPv6):
MaxRtrAdvInterval
The maximum time allowed between sending
unsolicited multicast Router Advertisements from
the interface, in seconds. MUST be no less than 4
seconds and no greater than 1800 seconds.
This solution is not recommended by any RFC (and is in fact against
RFC 6106) but it's the easiest hack to fix the problem until IETF
takes action.
My original posting to IETF can be found here:
http://www.ietf.org/mail-archive/web/ipv6/current/msg15816.html
1fd11bd8d1 consolidated VPN connection
state handling, but that had the effect of making vpn_cleanup() be
called after all other handlers had processed the VPN connection
state change. This meant that the code in vpn_cleanup() that
reapplies the parent device's IP configs ran last, and that code
flushes routes on the device before reapplying them. Since the
policy is a listener on the VPN state change signals, it was
running the default routing updates before vpn_cleanup() got run,
resulting in vpn_cleanup()'s calls to nm_system_apply_ip4_config()
and nm_system_apply_ip6_config() blowing the default route away
which the policy had just set.
Fix that by moving the VPN routing cleanups into the policy, where
most of the routing decisions currently live, causing them to be
run before the default route is fixed up.
The patches that reduced the frequency of changes to /etc/resolv.conf
failed to prefer the VPN DNS information. Even though a VPN may not
be allowed to receive the default route, its DNS information still
needs to be higher priority than interface DNS info, otherwise no
sites on the VPN will be accessible due to glibc's in-order querying
of entries in /etc/resolv.conf.
