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).
