Got the logic wrong in that commit. Fix it. Network registration
should always be run since it handles polling for registration
state if needed before continuing.
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.
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.
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.
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.
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).
Some cards (Novatel S720 for example) can take a long time to start
a data call if the device isn't activated on the network or the
signal strength is low.
Some modems key the AT+CSS? response off their 1X state, so if the
modem has EVDO service but no 1X service, AT+CSS? will provide incorrect
registration state information and the registration checking will
end too early. Allow modems that can handle more specific registration
checking to skip the AT+CSS? part.
There are more places to handle, but these are the most critical. If
the modem is removed while a command is in-progress, the mm-callback-info
code will set info->modem to NULL. Make sure we check for that in
callbacks and return a reasonable error. Previous code would just
blindly forge ahead and die on a null dereference.
Some devices (ZTE MF628) respond to everything except CPIN? with
ERROR unless the PIN has been sent. Since no known CDMA devices
support AT+CPIN, assume that devices that return a CPIN response
are GSM devices.
MM would appear to hang sometimes when writing to serial devices but
in reality was just retrying the write too many times. Make the
retry limit time-based so MM doesn't hang but times the attempt out
instead.
This implements the same fixes that NetworkManager's 0.7 branch
implemented in commits f38ad328acfdc6ce29dd1380602c546b064161ae and
1235f71b20c92cded4abd976ccc5010649aae1a0. Many ZTE devices will
spam the port with messages about waiting voicemail/SMS which buffer
up and cause the device to eventually crash if not suppressed.
Dan Williams
Martin Pitt
Norbert Frese