-1 = no APN set, so use modem default. We'll have to fix a few
more things up for modems like hso/mbm that don't use ATDT and
require CIDs, but this gets us halfway there for other devices.
Some devices (8775 specifically) get angry if you don't check for
a PS attach before dialing. The next time they try to connect,
they'll continuously report "searching" as the registration status
and return CME ERROR 30 (No Network Service) for lots of requests.
So initiate a PS attach (which should return OK if the modem is
already attached) before dialing, and if that fails cancel the
dial attempt.
See http://mail.gnome.org/archives/networkmanager-list/2010-October/msg00072.html
"I talked about this problem with a contact at SierraWireless. He said that
a firmware upgrade will not help in this case. But what can help is checking
for PS attach and dial only if PS attach status is attached. Dialing without
PS attach can bring modem into unwanted condition that sometimes restart is
needed to recover."
Depending on when the core requested the ICCID, the port may or may
not be open. Stuff that needs an open serial port needs to make sure
that the port gets opened itself.
An obfuscated SimIdentifier that may be available before the PIN has
been entered, for use in auto-unlocking a device. If this value is
present, it should be used in preference to DeviceIdentifier as it
is SIM-specific like the PIN code.
Pass the device's hardware IDs through modem creation and use them
when calculating the device's identifier. Add a bunch of testcases
for real hardware to ensure we don't break the device ID in the
future unless we really want to.
And possibly the X225 as well. Can't tell much about the modem and
what commands it supports other than AT+SYSSEL for mode selection.
The driver software and connection manager for Windows/Mac OS X are
written by JRD Communication in China, which is a subsidiary of
TCT, which makes Alcatel-branded phones and data sticks. But it
doesn't appear to be the same firmware as other Alcatel/T&A modems
like X060S and such which are supported by the Longcheer plugin.
For devices like the UMW190 that appear to be dual-mode without needing a
firmware reload (unlike Gobis, which are dual-mode but require a reboot with
different firwmare) prefer CDMA capabilities since that's where these devices
will most likely be used more often. In the end we'll need to change MM to
advertise a "capabilities" attribute on the modem class and modify devices
such that they can implement both GSM and CDMA semantics at the same time.
There were a few problems:
1) If SysMode is present, the registration state it reports should
be authoritative, but if there was a valid SID the plugin would
report 'registered' even if SysMode was NO SRV
2) Turns out that some devices report the roaming values as ERIs,
not plain yes/no as we thought; reported ERI was being mis-parsed
as a boolean value.
These are Longcheer-based devices, but the vendor ID is different.
We had tagged the X060s' ports in the rules but never updated the
plugin to handle the different vendor ID.
This specifically fixes a regression with Novatel GSM secondary
AT port enablement, where the inital pin check closed the port
before the Novatel plugin could send the command to flip secondary
ports to AT mode.
But it's useful elsewhere too, and simplifies a bunch of the PIN
checking code which had to use various ugly methods to track whether
to close the port or not after checking the PIN.
Instead of returning an unhelpful error when there isn't a second
AT port (which there never will be for Novatel CDMA devices) we should
let the superclass handle the request.
The generic CDMA superclass already checks minimal registration state,
and when some of the additional query_registration_state() subclass checks
were being performed, if the device returned an error (if it didn't support
the subclass' specific registration command like *STATE or ^SYSINFO) the
superclass' registration state checks would be thrown away.
Fix that by specifying the behavior of the subclass'
query_registration_state() methods to ignore most errors and leave the
superclass' registration state intact if a non-critical error occurs.
Previously there was an issue where if the probe failed, because
we can't really probe huawei secondary ports for various reasons,
the Generic plugin would eventually come around and try actively
probing the secondary port after the Huawei plugin said "I don't
support this port". Which resulted (potentially) in two MMModem
objects for the same device (one driven by Huawei, the other by
Generic).
Dan Williams
Torgny Johansson