We don't thoroughly log the pointer values of our libnl objects,
so the logging in check_cache_items() is not usefull, it only
clutters the logfile.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add a generic signal that devices can use to indicate that something
material in the network situation changed, and that auto-activation
may now be possible. This reduces specific knowledge of device types
in the policy.
Make WWAN support a plugin using the new device factory interface.
Provides a 5% size reduction in the core NM binary.
Before After
NM: 1187224 1125208 (-5%)
MM: 0 100576
(all results from stripped files)
Make Bluetooth support a plugin using the new device factory interface.
Provides a 5% size reduction in the core NM binary.
Before After
NM: 1253016 1187224 (-5%)
BT: 0 85752
(all results from stripped files)
Make ADSL support a plugin using the new device factory interface.
Provides a 1% size reduction in the core NM binary.
Before After
NM: 1265336 1253016 (-1%)
ATM: 0 27360
(all results from stripped files)
In preparation for making WWAN and Bluetooth plugins, rework
the device plugin interface to meet those plugins' needs and
port WiMAX over in the process.
Instead of having NMManager listen directly to the ModemManager
for modem removal signals, have the NMDeviceModem and NMDeviceBt
listen for them (since they obviously have a pointer to the backing
NMModem object) and then re-emit any necessary device removal
signals to the manager.
In reality the connection provider (NMSettings) is always the same
object, and some device plugins need access to it. Instead of
cluttering up the device plugin API by passing the provider into
every plugin regardless of whether the plugin needs it, create
a getter function.
The OLPC mesh code did rely on nm_manager_get() referencing the
singleton when returning it, but all other callers of nm_manager_get()
did not. Thus the manager's refcount would always increase and
almost never decrease. Fix the refcounting so that the manager
always has only one ref, and it's lifetime is controlled by
main() and nothing else.
We don't want the kernel to do IPv6 addrconf, but we do want it to
notice the non-router-related fields in the RA (eg, Retrans Timer) and
update the interface state to reflect them. So instead of turning off
accept_ra, we leave it turned on, and turn off accept_ra_defrtr,
accept_ra_rtr_pref, and accept_ra_pinfo instead.
Remove the "silent_on_error" flag from nm_platform_sysctl_get(), and
make both get() and set() log at debug level on ENOENT and error level
on all other errors, always.
Also ensure that we don't sometimes write "failed to set 'x' to 'y':
Success" when a partial write occurs.
get_best_ip4_device() and get_best_ip6_device() iterate over
the list of devices to find the device with the default route.
The order of iteration is arbitrarly choosen.
Before, if two devices had the same priority, it would choose
the first one. Change it so that the device which currently has
the default route keeps it -- until it gets deactivated or a higher
priorty device gets connected.
Signed-off-by: Thomas Haller <thaller@redhat.com>
e19f48ec was incomplete; it failed to handle device disconnections.
NMDevice will clear its internal activation request *before*
emitting the state change, which meant that when the
NMActRequest processes the DISCONNECTED state change, the:
if (NM_ACTIVE_CONNECTION (nm_device_get_act_request (device)) != active)
return;
statement triggered and the DISCONNECTED state change was not
processed.
Instead of having NMDevice keep the activation request alive over
the entire DISCONNECTED state transition, which may have much
greater implications, handle the special-case locally in the
NMActRequest code itself.
connection_parser.c: In function 'make_ip4_setting':
connection_parser.c:660:33: error: 'method' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!is_static_block && strstr (method, "dhcp")) {
connections.c: In function ‘load_cmd_line_edit_lib’:
connections.c:5744:17: error: ‘module’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
g_module_close (module);
Signed-off-by: Thomas Haller <thaller@redhat.com>
reader.c: In function 'parse_infiniband_p_key':
reader.c:3947:5: error: 'id' may be used uninitialized in this function [-Werror=maybe-uninitialized]
id = (id | 0x8000);
^
Signed-off-by: Thomas Haller <thaller@redhat.com>
When a new activation request comes in and the device is already
activated, two NMActRequests will exist for the device in parallel.
The old one handles de-activation of the device and is then disposed,
while the new one waits until the device is de-activated and then
takes over and starts the new activation.
Both requests are watching device state, and the new request may
mis-interpret the de-activation states and clean up its device pointer,
leading to assertion failures when the new activation starts.
To fix this (and because NMVPNConnection *does* always want to see
de-activation events from the device) remove the code that tries to
ignore de-activation from NMActiveConnection's device state handler.
Instead, have NMActRequest skip any reaction to device state changes
unless it is the current activation request on the device. The VPN
code always wants to see the device's state, so it doesn't need this
check.
If a device is already activated, queue the new activation to allow
the transition through the DEACTIVATING state.
---
Also remove the "HACK" bits in nm_device_deactivate(). This hack was
added on 2007-09-25 in commit 9c2848d. At the time, with user settings
services, if a client created a connection and requested that NM
activate it, NM may not have read the connection from the client over
D-Bus yet. So NM created a "deferred" activation request which waited
until the connection was read from the client, and then began activation.
The Policy watched for device state changes and other events (like
it does now) and activated a new device if the old one was no longer
valid. It specifically checked for deferred activations and then
did nothing. However, when the client's connection was read, then
nm-device.c cleared the deferred activation bit, leading to a short
period of time where the device was in DISCONNECTED state but there
was no deferred activation, because the device only changes state to
PREPARE from the idle handler for stage1. If other events happened
during this time, the policy would tear down the device that was
about to be activated. This early state transition to PREPARE
worked around that.
We need to remove it now though, because (a) the reason for its
existence is no longer valid, and (b) _device_activate() may now
be called from inside nm_device_state_changed() and thus it cannot
change to a new state inside the function.
If the firewall didn't know about the interface, don't log errors
about it because there's nothing NM can do. Also, sometimes NM
sends the not-IP interface, like when disconnecting WWAN when the
PPP interface is already gone.
Such a failure can happen easily, because we now request an initial dump
to get AF_INET6 addresses in order to check for extended ifa flags support.
This is not critical, so downgrade the error log.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Actually, get_ip_ifindex() should always return 0 or > 0. Just in case,
be extra careful and modify the conditions.
Signed-off-by: Thomas Haller <thaller@redhat.com>
This fixes a regression introduced in 5074898591.
The while loop did only refetch the cached value (because the glib main loop
was blocked and only the cached device flags were checked).
Also, instead on relying of g_usleep(), wait until a maximum time of waiting
is expired. The duration of g_usleep() might not be very accurate.
Also, do no longer check the cached device state before setting the
device flag. The cache might be out of date, so we just set the flag.
https://bugzilla.gnome.org/show_bug.cgi?id=724363
Signed-off-by: Thomas Haller <thaller@redhat.com>
Make sure NMPlatformGreProperties->path_mtu_discovery is always TRUE
or FALSE, even if the value from the kernel is "2" or "16" or
something. (This makes it consistent with what we do for other boolean
netlink properties.)
If the kernel doesn't tag a modem's ethernet interface with
DEVTYPE=wwan then NetworkManager has no idea that's a modem
(and cannot be used until connected via the control port).
Since DEVTYPE=wwan devices get ignored by NM, so should these
interfaces when NM knows they are modems.
That got broken at some point for ModemManager1, because the
data port isn't read until the modem is connected. NM only
looked for and removed the data-port-as-ethernet-device when
the modem was added, long before the MM1 data port was found.
ModemManager does provide a list of ports owned by the modem
though, which we can use at modem addition time to remove
an ethernet device that is controled by the modem.
Auth requests only happen during activation and there's no need to
request secrets at any other time. Ensure that the device state
won't change to NEED_AUTH except when activating.
(There's a case in NMModemBroadband where set_mm_enabled()
when the modem is locked may cause this, but we'll solve this
a different way later.)
https://bugzilla.redhat.com/show_bug.cgi?id=1058308
When c4fc72c7 began using the DEACTIVATING state, the modem code
wasn't updated to handle this. Because it only checked for
activating or ACTIVATED states to determine whether the modem was
previously connected, and thus when an MM disconnect was needed,
when the device enters the DISCONNECTED state it was no longer
considered previously active, and not disconnected.
Also, remove the NEED_AUTH handling from the modem code's device
state switch, because it does not appear to be needed. The
modem will only enter NEED_AUTH when it requires PAP/CHAP secrets
during the connection attempt or when a PIN is required before
enabling the modem. In both cases the modem won't yet be connected,
so this code will never be hit.
