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.
This pulls in network.target from NetworkManager.service (and not the
other way round), as suggested and agreed on on the systemd ML:
http://lists.freedesktop.org/archives/systemd-devel/2011-March/001692.html
This also introduces an auxiliary service
NetworkManager-wait-online.service that can be used to order a unit
after the point where the network is available. When this is enabled
with "systemd enable NetworkManager-wait-online.service" the unit
network.target will be delayed until the network is up, which is
suitable for synchronizing NFS mounts and similar to it.
https://bugzilla.redhat.com/show_bug.cgi?id=692008
Instead of having two of these, just use the autoconnect retries as
the invalid tag. Make sure the auto-retries tag always exists by
secretly adding +1 behind the scenes (so the data we set is never NULL).
This should make the code clearer, and will enable the next commit
for authentication failures to decrease the auto retries count.
There's some confusion in the code about indexes; there's the SDK index
from the NS, and there's the internal device index. Of course we've
got to use the internal device index to remove it from our list, so we
need to convert the SDK index to an internal index before we can call
iwmx_sdk_dev_rm().
Second, the:
if (device_id_list_size < devid->deviceIndex) {
check is useless because by the time we get here, the device is already
gone from the SDK's device list, so this always triggers of the NS
quits. So just run this check when devices get added to ensure the
NS isn't lying to us. The, if we get a device removal event, match
up the SDK index with some internal device's SDK index and remove that.
If the user canceled a secrets request, or we simply can't get
secrets for the connection, invalidate it and make sure it doesn't
get tried automatically again right after it fails.
Because we can't ever know if we're the last user of NSS or gnutls
when nm_utils_deinit() is called, just don't bother deiniting
the crypto providers. And atexit handlers are generally frowned
upon for the exact same reason. You never know what library linked
into your process might be also using NSS or gnutls, so basically
if these libraries suck enough to use global data and not reference
count it, just let the data leak. If we do clean stuff up that
can lead to crashes when other libraries might try to use NSS or
gnutls after the atexit handler or nm_utils_deinit() has been run.
See also: https://bugzilla.mozilla.org/show_bug.cgi?id=54189#c1
