For the factory, the only public symbols should be the factory functions.
For the WWAN library, the only public symbols should be those that
NMDeviceModem and NMDeviceBt use.
Instead of having a GObject property and a factory function to get
the plugin's device type, just use the factory function, since it
always has to be around.
The mesh and Wi-Fi companion share radio hardware and firmware resources
and you need both to exist for the mesh to function properly and to
ensure that the Wi-Fi and mesh sides cooperate correctly for scanning
and activation.
If the supplicant interface object never successfully initialized, remove
the pending action to prevent warnings about "pending action already added"
when supplicant_interface_acquire() adds the pending action again.
Just listen to manager signals all the time, but only respond to
them when necessary. Clean up companion detection to be a bit
clearer, and use nm_device_queue_state() so that we don't need
an idle handler when detecting the companion from a state change
handler.
There used to be many more members of the Supplicant struct, but now
that there are only three, collapse the struct into the NMDeviceWifiPrivate
struct, renaming them slightly at the same time to shorten the names.
Second, consolidate timeout cleanup since the two remaining timeouts
don't need their own cleanup functions.
Third, start_supplicant_connection_timeout() doesn't need its own
function since g_timeout_add() never returns 0, so we don't need to
check for it.
The only reason for the small struct was the idle handler, and the
only reason for the idle handler was to ensure that state was changed
from an idle handler. We've got nm_device_queue_state() to do that
for us now, so use it.
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>
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
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.
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>
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>
At a later point, we will have to make a copy of @dhcp_anycast_addr to start
the client asynchronously. Although the length of the guint8 array *should*
always be 6 byte (being a MAC address), it's nicer to just pass on the
GByteArray instance instead, which knows how many byte are actually
set.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Clients such as gnome-control-center or nm-applet show
at some places only one (IPv6) address. They most likely
just pick the first address from the list of addresses,
so we should order them.
Sorting has the advantage to make the order deterministic --
contrary to before where the order depended on run time conditions.
Note, that it might be desirable to show the address that the kernel
will use as source address for new connections. However, this depends
on routing and cannot be easily determined in general. Still, the
ordering tries to account for this and sorts the addresses accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=726525
Signed-off-by: Thomas Haller <thaller@redhat.com>
We'll want to track internal management separately in the future, so split out
user management (eg, whether the device has been explicitly marked unmanaged
by the user).
Instead of tracking unmanaged-ness in a couple variables (and because
I'd like to add one for user-unmanaged later) let's do it in a single
flags variable, and consolidate setting of the unmanaged states in one
place.
