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.
First, -Wstrict-prototypes wasn't actually getting used because
-Werror was already in CFLAGS and AC_TRY_COMPILE doesn't produce
main() functions with valid strict prototypes. Suck. But even
fixing that, the WiMAX SDK won't build with the flag, so just rip
it out.
Like the *_filter_connections() functions, but for just one connection,
and now the *_filter_connections() functions call these new ones so
it's really just moving code around and not anything new.
These new functions more closely match the usage I've seen from
gnome-shell's network.js and elsewhere.
AC_PROG_CXX should be unconditionally run, as it doesn't fail out
if a C++ compiler is not found, which is fine. It'll check for
one, but we only use it if --enable-qt=yes is given at configure
time. If --enable-qt=no is set, we do not want to do anything
C++ related, which is why it was conditionalized (incorrectly)
the first time around.
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.
At some point we'll be passing other info like whether we need
the 802.1x identity too, or unknown CA certificate data for the
Agent to accept, etc. Basically state that instead of only
hints from the setting, we can pass other stuff as well.
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.
