If a class implements init_async, it should implement init_finish too,
rather than assuming the default implementation will do the right
thing (which it briefly didn't in glib 2.33).
The whole callout is pure dbus, not dbus-glib, so there's really no need
for glib code there. Even so, DBUS_LIBS contains dbus-glib and gobject,
so we're still linking to glib/gobject.
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...
Core D-Bus VpnStateChanged signal changed. In order to receive the signal,
the parameters was fixed. This commit also adjusts libnm-glib's vpn-state-changed
signal to match the D-Bus one.
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.
