Age | Commit message (Collapse) | Author |
|
Since the modem states patch the delay for power-on wasn't honored
for Option devices. Fix that using the new power-on-done handler
and also fix the bug where if the modem was removed, the plugin
would crash because it wasn't handling the timeout removal.
Also remove the explicit PIN check since that's now handled by the
generic GSM code before the modem is even exported over DBus.
|
|
Since the modem states patch the delay for power-on wasn't honored
for Sierra devices. Fix that using the new power-on-done handler
and also fix the bug where if the modem was removed, the plugin
would crash because it wasn't handling the timeout removal.
Also remove the explicit PIN check since that's now handled by the
generic GSM code before the modem is even exported over DBus.
|
|
This lets subclasses handle errors when they know the device supports
the power-up command. Also will let us simplify a number of plugins.
|
|
|
|
First, short-circuit the Enable process if the device requires a PIN
or PUK since for many devices the enable is going to fail anyway
until the PIN is sent.
Second, send the PIN first during the simple state machine for the
same reason; we need the device unlocked before we want to try
to enable it. This also reworks the simple state machine to be a
bit clearer and make each state step correspond to the action it's
actually doing instead of being off-by-one visually (but not logically).
|
|
Don't return until we know what the updated lock status is. Fixes an
issue where callers that send the PIN before the modem is enabled
(remember, some modems can't be enabled until the PIN is entered, so
sometimes we have to send the PIN before it's enabled) would get
the reply too early and get failures from other operations.
|
|
|
|
If E2NAP:0 is received during a connection attempt the connection
attempt has failed or will fail. So stop polling for connection
success for another 50 seconds and abort the connection attempt
immediately. Also moves the E2NAP request call a bit earlier to
ensure that no E2NAP unsolicited messages are lost.
|
|
|
|
It's useful to let distros and admins set policy differently for device
information (for support, inventory, etc) than for actually controlling
the device like PIN/PUK unlocks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When the support is complete, use --with-polkit to enable
PolicyKit support. It's not there yet, but this commit adds an
authorization provider framework which will be extended to allow
hooking into PolicyKit.
|
|
|
|
|
|
|
|
|
|
|
|
Since CSS doesn't reliably determine EVDO-only registration state.
|
|
If the modem echoed commands by default (since we may not have
initialized the modem yet), the echoed command would confuse
the PIN check reply parser.
|
|
|
|
|
|
Normally this would get done by the prober, but if the device
has a PIN enabled it'll reject almost all commands so the +CPMS?
in the prober will fail. Thus we have to do it after we've unlocked
the device.
|
|
|
|
|
|
|
|
Even just walking sysfs for driver and parent devices takes
time for ports we know we'll never use, so take a short-cut
and save some startup time. This reduces the startup
overhead to some 15%.
|
|
|
|
Some devices won't get to the initialization stage where we send
CMEE=1 (for numeric error codes) before they return some errors,
so handle the string representation of CME error codes too.
|
|
Use the same error structure for parsing numeric and string-based errors.
|
|
|
|
|
|
|
|
And set UnlockRequired accordingly. Large cleanups and rework by
dcbw.
|
|
Clients can check the property to determine lock/unlock status and thus
unlock the modem before trying to connect if required.
Bits of the patch by dcbw (see the bug).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|