Currently there's no way to differentiate between a connection that has
never been activated, and a connection that has never been *successfully*
activated. In both cases nm_settings_connection_get_timestamp() returns
zero. But it's useful to know whether a connection hasn't even been
tried yet, so enhance the timestamp code to return whether or not the
timestamp has been found in the timestamp cache or not, and make the
NMDevice core set an explict timestamp of 0 if the connection failed
on the first attempt.
We'll use this later to conditionally autoconnect WiFi connections
depending on whether they've ever successfully connected or not, but
still allow preloaded connections without a timestamp to autoconnect
as they always have.
If we mask signals before daemonizing, the daemon process will not be
able to handle them, and thus would be unkillable with anything other
than SIGKILL.
Helps when you need to grep the code to change a signal's signature.
Otherwise you're stuck grepping for "state" which a lot of objects
have as a signal name.
Remove unused args for the non-VPN cases to cut down on the NULL NULL NULL
stuff since we're also adding two more arguments. Add the ability for
callers to give a callback that should be called when the dispatcher is
done.
Buggy kernel drivers sometimes default the carrier to ON when they
are capable of link-detection but the carrier is actually off, and
they quickly switch the carrier OFF when they determine actual
carrier state (cdc-ether, for example).
The initial carrier ON event would trigger a queued state change
from UNAVAILABLE to DISCONNECTED, which may auto-activate the
device. But before that state change happens, if a carrier OFF
event comes in, that queued state was not getting cleared and
the device would transition to DISCONNECTED even though the
carrier was off.
To ensure that never happens, and that we don't enter states that
aren't valid when the carrier is off, we need to clear any queued
state changes that wouldn't be valid in the new carrier state.
The kernel periodically adds routes for specific operations, including
when pinging any host. These are temporary routes and aren't part of
the interface's permanent routing configuration, so we should ignore
them.
If ModemManager isn't running, don't put DUN connections into
AvailableConnections, and don't allow DUN connections to be started
either automatically or manually.
Because object-valued properties (like ip4-config) get reloaded
asynchronously when they change, we will still have out-of-date values
for them cached at the point when we get the StateChanged signal from
the daemon. Work around this by manually reloading all properties
before emitting the client-side signal.
Also, fix a dumb bug in NMObject...
The MM API defines the GetIP4Config method return as (uuuu) which
is [ IP, DNS1, DNS2, DNS3 ]. Unfortunately the for() loop in the
static_stage3_done() function started at index 0, which is the IP
address. This caused the IP address to be added to the DNS list.
It should start at index 1 instead.
This worked fine with PPP because PPP terminates, and NM watches
for that and handles it fine. But modems with pseudo-ethernet ports
don't have anything like that, so we have to watch the modem's state
property instead. This works only with MM 0.5.4 and later (including
0.6).
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.
Some rfkill drivers (sony-laptop, ideapad-laptop, classmate-laptop,
etc) register their rfkill drivers under the "acpi" subsystem instead
of the platform subsystem, but the semantics are the same.
