Make Wi-Fi support a plugin using the new device factory interface.
Provides a 7% size reduction in the core NM binary.
Before After
NM: 1154104 1071992 (-7%)
Wi-Fi: 0 110464
(all results from stripped files)
Older Intel "ipw" devices (ipw2100, ipw2200, and ipw2915) only gained
kernel rfkill subsystem integration with 2.6.33. Before then their
custom rfkill functionality had to be polled via sysfs. Since we now
require at least a 3.x kernel, remove this old code.
The domain LOGD_OLPC_MESH is known as "OLPC". This is the only case where
the internal name LOGD_X does not correspond to the external name X.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This reverts commit 8f44bf047f.
This spec file is not intended to be passed directly to rpmbuild,
because it contains placeholders that are substituted by the build.sh
script.
As such, the version we want to get is
NetworkManager-0.9.9.1-7922.66eb52b53d.fc20.src.rpm
instead of
NetworkManager-0.9.9.1-792266eb52b53d.fc20.src.rpm
Signed-off-by: Thomas Haller <thaller@redhat.com>
It happens when one selected private key, but didn't provide the password yet
in nm-connection-editor.
(nm-connection-editor:11080): libnm-util-CRITICAL **: crypto_md5_hash: assertion `password_len > 0' failed
It's only used to keep the DHCPManager up-to-date with hostname changes,
and that can be accomplished in much less code by just having NMManager
set a hostname on the DHCPManager itself.
If IPv6 completes first it would emit the "up" dispatcher event with IPv6
details and move the device to ACTIVATED state. But if DHCPv4 was still
running, no dispatcher event would be emitted with the DHCPv4 information
until the first lease renew. Thus dispatcher scripts would not receive
DHCPv4 information for quite some time.
Ensure that if the other IP version completes first, that when the slower
method's DHCP completes, that it emits the appropriate dhcp4-change
or dhcp6-change event so that dispatcher scripts get the information
as soon as it's available.
https://bugzilla.gnome.org/show_bug.cgi?id=729284
By default pppd will suicide if there are 600s without traffic going through:
pppd[30575]: Terminating connection due to lack of activity.
pppd[30575]: Connect time 10.0 minutes.
pppd[30575]: Sent 0 bytes, received 0 bytes.
This is likely to happen when e.g. the system has both a mobile broadband
connection and an ethernet connection, as the ethernet will take the default
route.
So, avoid this behaviour by explicitly telling pppd not to exit if idle.
NetworkManager stopped touching /etc/hosts in late 2010 before the
NetworkManager 0.8.1 release. The code in nm-policy-hosts.c's only
purpose is to remove any of the entries that NetworkManager added long
ago.
I think we're at the point where people have already upgraded to
NetworkManager 0.8.1 or later and thus this code would be a NOP. The
only risk is that some stale /etc/hosts entries will be left if you
upgrade from NM 0.8 or lower to anything higher than that.
FWIW, Ubuntu Lucid (10.04) ships NM 0.8.0 and SLES11 ships NM 0.7.0, so
if users of these distros upgraded to a later NetworkManager they might
run into the stale entries issue if we remove this code from NM. But
given how old these distros are, it seems unlikely that users will do a
direct upgrade to something 4+ years newer...
https://bugzilla.gnome.org/show_bug.cgi?id=729689
This one spec file is intended to build packages for F18, F19, F20, and
rhel-7.0.
The build script can be tweaked by setting environment variables, but it
is supposed to choose the right default values on it's own.
Signed-off-by: Thomas Haller <thaller@redhat.com>
When WWAN airplane mode is enabled, set modems to low power state to
ensure they are in airplane mode if either (a) the machine does not
have an rfkill switch, or (b) the modem is not tied to any rfkill
switch (eg, external USB/SDIO/etc).
If the given PIN was wrong, we really don't want to try that PIN
again automatically because it might lock the SIM. To ensure that
doesn't happen, disable autoconnect so that the user must manually
request reconnection.
(this doesn't fix auto-connect-with-a-wrong-PIN completely, as
autoconnect is reset when resuming from sleep, but it's a start)
Determining when the NMDeviceModem is available and when different
connections are available is easier if the modem's state is tracked,
instead of using the separate Enabled and Connected properties.
These properties could not accurately represent the SIM lock state
and prevented NetworkManager from making the modem available for
auto-activation when locked, even if a PIN was available.
In this new scheme, the NMDeviceModem is UNAVAILABLE when the
ModemManager modem state is FAILED, UNKNOWN, or INITIALIZING. It
transitions to the NM DISCONNECTED state when the modem has finished
initializing and has not failed.
Once the NMDeviceModem is in DISCONNECTED state it can be activated
even if the SIM is locked and a PIN is required; the PIN will be
requested when starting activation, either from the connection itself
or via a secrets request. This makes auto-activation of WWAN
connections possible.
This also allows us to consolidate code dealing with modem enable/disable
into the base NMModem class using the modem state, and to log more modem
information for debugging purposes.
Since the ModemManager enabled/disabled state is a user-changable
one, and since NM can enable the modem when starting a connection,
allow modems to be available for activation whenever they are not
in airplane mode. This makes WWAN autoconnect=true connections
actually autoconnect.
If the first connection fails during ModemManager setup for fatal
reasons (missing SIM, bad PIN, not registered), autoconnect will
be blocked for that connection until activation is manually
requested and succeeds.
rfkill handling should only pay attention to actual rfkill, since
rfkill is global but the modem management service state is per-device.
Thus calculating a global state from multiple devices is very
likely to get things wrong.
Remove all of the code that used to handle that sort of thing,
which means removing the 'enable-changed' signal from the Modem
device, since now nothing external to the modem device should
need to care whether it's enabled internally or not.
Poke the kernel's WWAN rfkill state when the user changes our
WWANEnabled property, the same as we do for WiFi. Also restore
saved WWAN state on startup, as we do for WiFi. No good reason
why WWAN should be different here.
When adding the same addresses from different sources, we want to
preserve the times with the later expiry . If the new address comes
from the kernel itself, we treat it specially and prefer the times
from other sources.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This compares two addresses and returns which one has a longer
remaining life (i.e. a later expiry timestamp).
Signed-off-by: Thomas Haller <thaller@redhat.com>
Especially the calculation of timestamps is identicall for addresses.
By creating a "base struct", we can use the same code for that, because
NMPlatformIP4Address and NMPlatformIP6Address can now both be treated as
NMPlatformIPAddress (and the same for routes).
Signed-off-by: Thomas Haller <thaller@redhat.com>
Before platform raised 3 signals for each object type. Combine
them into one and add a new parameter @change_type to distinguish
between the change type.
Signed-off-by: Thomas Haller <thaller@redhat.com>
