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>
Makes the function working for link destinations longer then 127 bytes and
fixes a potential bug that the result of readlink() was not zero
terminated for long paths.
Probably this would be no problem, but better be save.
Related: https://bugzilla.redhat.com/attachment.cgi?id=885371
Signed-off-by: Thomas Haller <thaller@redhat.com>
Interpret the configuration option main.debug and the
environment variable NM_DEBUG as a comma separated list
of debugging options (parsed with g_parse_debug_string()).
Currently only the option "RLIMIT_CORE" is supported, to set
the core dump size to unlimited.
Signed-off-by: Thomas Haller <thaller@redhat.com>
In case of DHCP4, DHCP6 and/or SLAAC, delay "startup complete" until
both IPv4 and IPv6 are ready. This especially has an effect on
nm-online/NetworkManager-wait-online.service, which blocks until
configuration of both IPv4 and IPv6 is ready.
We queue a pending_action when automatic configuration starts and
remove it again, when we receive an address. Before, "startup complete"
was reached when either one of the two IP protocols was configured.
https://bugzilla.redhat.com/show_bug.cgi?id=1086906
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add a parameter to nm_device_add_pending_action() to silently
accept adding duplicate actions.
Same for nm_device_remove_pending_action(), to silently ignore
removing non-pending actions.
Signed-off-by: Thomas Haller <thaller@redhat.com>
dfe194ee made it so that we don't use "public suffixes" as resolv.conf
search domains (eg, we don't add "search com" if the hostname is
"example.com"). However, if this results in us writing a resolv.conf
with no "search" line at all, then the resolver will fall back to
using the parent domain of the hostname as a search domain anyway,
thwarting us.
To fix that, use the domain itself as a search domain in this case,
since that's likely to be the expected behavior anyway. (And even if
it's not, there doesn't appear to be any way to block the resolver
from using the hostname's parent domain as a search domain unless we
specify at least one search domain ourselves.)
https://bugzilla.gnome.org/show_bug.cgi?id=729137
resolv.conf(5) says:
The domain and search keywords are mutually exclusive. If more than
one instance of these keywords is present, the last instance wins.
NM always writes out a "search" line if it writes a "domain" line, so
the "domain" line is always a no-op. So drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=729137
NmtRouteTable's ip4-routes and ip6-routes properties have the
D-Bus-based route list types (like the corresponding NMSetting
properties) so we have to convert our GSList-of-NMIP[46]Route data
into those types when updating the property.
https://bugzilla.gnome.org/show_bug.cgi?id=728958
Tighten up with suggestions from Johannes Buchner and mention
his contribution.
Also fixes operation with current nmcli since it changed from
"802-3-ethernet" -> "ethernet" and thus the script was broken.
https://bugzilla.gnome.org/show_bug.cgi?id=513488
test_read_wired_aliases_bad() would succeed or fail depending on the
order that ifcfg-aliasem1:1 and ifcfg-aliasem1:2 got read from disk.
Fix this by splitting it into two separate tests, each with only a
single alias.
This results in some nice coloring. Only move the tests that are called
without arguments from check-local to TESTS.
Signed-off-by: Thomas Haller <thaller@redhat.com>
