For VPN connections, the interface name would be that of the VPN's
IP interface, but the script environment would be the that of the
VPN's parent device. Enhance the environment by adding any VPN
specific details as additional environment variables prefixed by
"VPN_". Leave the existing environment setup intact for backwards
compatiblity.
Additionally, the dispatcher never got updated for IPv6 support,
so push IPv6 configuration and DHCPv6 configuration into the
environment too.
Even better, push everything the dispatcher needs to it instead
of making the dispatcher make D-Bus requests back to NM, which
sometimes fails if NM has already torn down the device or the
connection which the device was using.
And add some testcases to ensure that we don't break backwards compat,
the testcases here were grabbed from a 0.8.4 machine with a hacked up
dispatcher to dump everything it was given from NM.
Enable the supplicant's optimized background scanning functionality
for WPA Enterprise setups so that roaming works correctly. Otherwise
there are issues pingponging between APs and having an up-to-date
scan list for roaming, since NM only scans every 2 minutes. The
supplicant can trigger optimized scans based on signal quality
thresholds and such and make these roaming decisions much better
than NM can.
This commit changes rfkill state handling slightly in the following
ways:
- when checking whether a user toggle request can change radio state,
ignore states we can change in radio_enabled_for_rstate() as a result
of the toggle; this fixes WiMAX enable/disable because a softblock
can be changed by telling wimaxd to enable the radio. As a side-effect
this also fixes handling of WiFi when altering the rfkill state as well.
- make WiFi user toggle requests change wifi killswitch state; this has
been long requested and on the TODO list for a while and it turns out
to be a lot easier to do these days. This provides the expected
behavior when disabling wireless from user agent menus since there's
not an easy way to do this other than dropping to shell and running
rfkill.
Allow clients to get a device by its IP interface name instead
of having to get the device list and iterate through each one,
and read the interface name to get what they want.
If the client knows the UUID, add a convenience function to get
the connection path directly, instead of having to iterate the
whole connection list and get each connection's details and then
check the UUID.
A convenience so that clients which might key certain operations off
which connections are active (checking work mail only when on VPN for
example) can more easily get which connections are active. This would
allow those apps to store the UUID (which they would already be doing)
and not have to create a Connection proxy and then get the connection
properties just to retrieve the UUID of the connection. Instead they
can now get it from GetAll of the ActiveConnection object, which they
would already be doing.
The signal was emitted in case the removed connection was managed instead of
for unmanaged connection. Thus the signal had no effect.
That caused incorrect behaviour in case of changing NM_CONTROLLED=no to yes.
That didn't enable the device; only after the file was changed for the second time.
Make sure the dispose won't run twice for the same code and
make sure we never schedule a handler for monitor_cb() more
than once, though it's really hard to see how that could ever
happen anyway.
Another attempt to blindly fix lp:752143
While this should never happen while the PPP manager is alive, modems
can switch their IP method while alive, since the net port is sometimes
discovered after the serial ports have been. This happens for some
devices that have separate drivers for the net and serial sides, like
ZTE Icera-based devices (cdc-ether and cdc-acm) and newer Sierra
devices (sierra and sierra-net). Just be paranoid here and ensure
that the PPP manager gets cleaned up.
Partial attempt at fixing lp:752143
The default wired connection should own a reference to the device
it's made for, but that got dropped in
78df8c49a1, which used to use a
set_property handler with g_value_dup_object() which obviously
increments the reference count. But that ref got dropped when
the object initialization was simplified.
If any ethernet devices were left up (because we can assume control
over them seamlessly when NM starts up again) make sure we write
out a usable resolv.conf for the device on shutdown, otherwise the
users networking is broken with an empty resolv.conf. This only
happened when DNS plugins were active, in which case the user
would be left with a localhost-pointing resolv.conf but no
local caching nameserver running since NM shut it down when NM
terminated.
These interfaces are a proprietary USB-ethernet-style virtual interface
that of course does not have proper driver links. Given that it's so
easy to support, just do it.
Now that initscripts also support IPADDRn syntax, update the implementation
to match the intitscripts' one (see rh #633984)
Basically, writer produces IPADDR0 .. IPADDR255. reader is more tolerant and
supports older configs too: IPADDR, IPADDR0, IPADDR1 could be missing, from
IPADDR2 up the indexes have to be contiguous.
Since the user state stuff got committed in 0.8.2, WWAN enable
state has been somewhat broken. The problem is that we want two
things: (1) that the current modem enabled state is reflected
in the WwanEnabled property, and (2) that enabled state should not
affect the user's ability to enable the modem via the UI.
The code did not properly separate these two. For all automatic
decisions and properties (ie the WwanEnabled property, setting the
initial enabled state on startup or hotplug, etc) the ModemManager
enabled state should be respected. But the user should be able
to override that state by turn WWAN on.
This calls for a fourth enabled check that modems have, the 'daemon'
state, distinct from the hardware and software kernel rfkill states
and from the user's chosen enabled/disabled state. Add that new
check.
The actual problem was in manager_radio_user_toggled() where after
updating the user enabled state, new_enabled still equaled
old_enabled, because the kernel rfkill state was a combination of
both the kernel rfkill state *and* the ModemManager enabled state,
so the manager_update_radio_enabled() call would never happen and
the modem would never become enabled as a result of a user request.
Jan Schmidt noticed that things didn't work as expected with
multiple sessions of the same user, since when inserting the
new session the old one was forgotten. Thus bad things happened
if you were local in the old session but not in the new one
since only the new one would be considered.
Instead, make the actual data stored the aggregate of all
sessions for that user.
Jan Schmidt noticed that things didn't work as expected with
multiple sessions of the same user, since when inserting the
new session the old one was forgotten. Thus bad things happened
if you were local in the old session but not in the new one
since only the new one would be considered.
Instead, make the actual data stored the aggregate of all
sessions for that user.
In NMDeviceWifi's real_complete_connection() the wifi setting
was looked up at the start of the function, but if no wifi
setting was sent by the caller, it would be NULL. The wifi
setting would later get added by nm_ap_utils_complete_connection(),
but after calling that the new wifi setting would not be looked
up again. Make that clearer by moving the wifi setting add code
to the wifi device's real_complete_connection() and not burying
it in some other function. This is more like what other device
types do.
Besides not being technically reliable (although it mostly works)
we could get into situations where systemd would kill the cgroup
which resulted in NM getting a SIGCHLD for dhclient children before
the SIGTERM quit the mainloop. This caused NM to think that the
dhclient process died unexpectedly, and to tear down the connection
even though what NM really wanted to do was just leave everything
running so that the connection could be taken over on restart.
