Until we handle bridges non-destructively, only manage bridges
created by NM. When quitting write out a file listing all
bridges created by NM and a timestamp, and when starting read
that file and if the timestamp is within 30 minutes, manage
any bridge that was listed in that file. This scheme, while
not foolproof (eg, if NM crashes), should ensure that NM can
recognize bridges it created if it's restarted. The file
is stored in /run or /var/run, which is cleaned each restart,
ensuring that the state does not persist across reboots.
If an automatic or user-initiated activation request for
a bridge NM does not manage is received, that request is
denied. Only if the bridge interface does not yet exist, or
was present in the managed bridges file, will an
NMDeviceBridge be created and activation be possible.
Since the manager now tracks active connections, it needs to hold
a reference to the active connection objects too. The active
connection teardown code was changed to release that reference
(_active_connection_cleanup()) but the creation code was never
changed to remove the bits that pass ownership over the initial
reference to the NMDevice. Fix that.
Will replace the VPN manager's activated/deactivated signals; listeners
can attach to the active connection's 'state' property and listen
for the changes to ACTIVATED and DEACTIVATED. Works for all connections,
not just VPN ones.
Instead of using devices as a proxy for active connections, and
then also asking the VPN manager for the active connections it's
tracking, just track *all* active connections in the manager.
We'll want to use NMActiveConnection more in the manager and also fold
the PendingActivation functionality into it. All this functionality
applies to the VPN connections too, so it makes sense to have it all
in the base class instead of both NMActRequest and NMVPNConnection.
We don't need to check device state here because the manager, which
is the only thing that calls nm_device_activate() in
internal_activate_device() ensures that the device is deactivated
before starting a new activation request.
The new `MMManager' object takes care of notifying modems added or removed from
the ModemManager1 interface.
We will listen to both the old and new ModemManager implementations, but as soon
as the first ModemManager implementation is found, the other one gets cleared,
so that we don't wait forever to appear.
Previously, when a new bond or VLAN connection was created, NM would
always create the virtual device right away. But on startup, it only
creates virtual devices for connections that can autoconnect. Fix
connection_added() to make that check as well.
The logic behind the `iface' property (which actually is removed) gets split
into three new properties, as follows::
* `uid': Just defines a new string property which must contain a unique ID of
the modem, mainly for logging.
* `control-port': a string property defining which is the control port the
modem uses. This property is actually optional and may be specified as NULL.
The main purpose of this property is to allow the easy integration of the
new ModemManager into the `NMDeviceBt' object. The bluetooth device needs
to know the port used by the modem; and we cannot use the Data port
information as that is only available until the bearer is created. Instead,
for the new ModemManager we will use the control port information exposed.
* `data-port': a string property defining which is the data port to use in the
connection. This property is always defined in the `NMModemGsm' and
`NMModemCdma' objects.
Introduced in 64fd8eea7706038e5d38c8463a1c765ed9331db2; but honestly
I also thought GObject lower-cased signal names since it munges them
for - and _ too. Apparently not.
VLANs are only supported on certain kinds of devices, so don't try to
create them on other devices. (In fact, NM currently assumes that
VLANs are only created on Ethernet devices, so we need to be even more
picky than that.)
PPP interfaces are transient and created by their master interface
(usually for PPPoE or WWAN) and thus we don't want their removal
to affect their master device. Unfortunately, that was happening
when a manual 'killall -TERM pppd' was run, which caused the
udev device removal signal, which caused NM to remove the master
WWAN device when udev signaled that the 'ppp' interface was gone.
Allows devices to generically request authorization from the manager
for whatever operation they want, and allows us to keep the devices
from including the auth code directly.
It is bound to autoconnect_inhibit private variable (has opposite meaning).
While 'Autoconnect' is TRUE (default value) the device can automatically
activate a connection. If it is changed to FALSE, the device will not
auto-activate until 'Autoconnect' is TRUE again.
Disconnect() method sets 'Autoconnect' to FALSE. NMPolicy monitors the property
and schedules auto activation when FALSE->TRUE transition is made.
This patch adds the settings code (NMSettingAdsl) and the initial
"scaffolding" i.e., a tiny stub version of NMDeviceAdsl and the
udev handler code to get the device detected.
With this patch you should be able to see an atm device being detected
by networkmanager in the logs, although of course it doesn't
do anything useful yet.
Extract from the logs:
[1304668252.341354] [nm-udev-manager.c:562] adsl_add(): adsl_add: ATM Device detected from udev. Adding ..
(ueagle-atm0): failed to look up interface index
(ueagle-atm0): new ADSL device (driver: 'ueagle-atm' ifindex: -1)
(ueagle-atm0): exported as /org/freedesktop/NetworkManager/Devices/2
(ueagle-atm0): now managed
(ueagle-atm0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
(ueagle-atm0): deactivating device (reason: 2).
[1304668252.345102] [nm-system.c:1349] flush_routes(): (ueagle-atm0) failed to lookup interface index
[1304668252.347821] [nm-device.c:3912] nm_device_state_changed(): (ueagle-atm0): device is available,
In this version, we hack the nm-device.c:nm_device_get_priority() to get better priority
instead of changing the DeviceType enum.
Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com>
To simplify NMManager and to make use of the new connection provider
functionality, move the logic for when a paired Bluetooth device
is actually usable for network connections or not into the bluez
manager and out of NMManager. The general direction should be towards
moving this sort of logic out of the manager and into the device
specific stuff, like we did with the WiMAX bits, so we can make
stuff into plugins.
Kernel ifindexes are always greater than zero (see dev_new_index()
in net/core/dev.c). Also don't bother warning about ifindex
lookup failures for devices we know aren't kernel network interfaces.
"InfiniBand" has a capital "B". Fix that everywhere it's being used as
a human-readable string.
In particular, the RH initscripts recognize "TYPE=infiniband" and
"TYPE=InfiniBand", but not "TYPE=Infiniband", which is what we were
writing before.
For virtual interfaces and other cases we won't necessarily have
a device path, which means clients will be passing "/" instead.
Fix that up the same way we fix up the specific object.
We can't guarantee the ordering of devices that udev sends to us
on startup. Thus, a VLAN interface could be sent before its
parent is, and we won't be able to find the parent in the device
list. But that's fine; all parents will be detected during the
first pass, and we silently fail the VLAN interface. Then we
do a second pass where any remaining VLAN interfaces will be
created because we found the parents during the first pass.
They are the basic class that tracks active connections, and we're
going to use them for connection dependencies. So use the fact that
both NMVPNConnection and NMActRequest have the same base class
instead of using object paths.
Many different interface types can support VLANs, including
Infiniband, WiFi, etc. So we have to create a new device class
for them instead of keeping the support in NMDeviceEthernet.
We'll want to eventually match (for VLAN) a given hardware address
that's not the device's hardware address. Only the device itself
knows which NMSetting should contain it's hardware address (ie
the 'wired' setting for NMDeviceEthernet, 'infiniband' for
NMDeviceInfiniband, etc) and VLANs take their hardware address
from the parent interface. So eventually we'll have VLAN
interfaces use these new arguments to ask their parent interface
to match the VLAN hardware address in a connection, since the
VLAN doesn't know (or need to know) what kind of interface it
really is underneath.
We want to start the connectivity checks when any device gets
activated, and stop them when all devices get deactivated. We
also want to make sure it's running if a device gets deactivated
but other devices are still active. If multiple devices are
activated and if the default device gets deactivated, the other
device may become the default device and we'll need a connectivity
check for that device since we can't do per-device checks yet.
Also, if connectivity checking is enabled at compile-time but
not enabled at runtime, the connectivity bits should always
report "connected" to preserve previous behavior, and this code
makes it clearer how that is handled.
We can just use property notifications instead of having
a separate connected signal. Also clean up some formatting
and make some private variable names shorter.
