This reverts commit 1e1bfbf1d8.
Aleksander says this might break RS232<->USB converter connected
Cinterion modems, so we'll need to handle this issue another way.
Caused a crash with the Sierra plugin due to an assertion failure;
the Cinterion plugin shouldn't claim to possibly support ports
it knows it won't support. In this case, it claimed to support
Sierra modems, so it would try to run probing after Sierra had
done so. Ideally this should work, but for now just make sure
the Cinterion plugin doesn't claim to support these ports when
it knows it doesn't.
AT+CFUN=4 will be used when available to go to standby mode. If not supported,
(as in EGS5) AT+CFUN=7 will be used instead, which enables a CYCLIC SLEEP mode.
Flow control setup was updated to RCS/CTS so that waking up from sleep mode
works properly.
Using AT+CFUN=1,0 so that we request to avoid resetting (<rst>=0). Works
properly when powering up after having put the modem in standby mode with
AT+CFUN=4.
Note that the power-up command will only be sent if the check to see if power-up
is needed requests it.
The NWSTATE field reports both available access technology and the
actual access technology in-use when a PS connection is active, so
report the actual access tech when it's available.
For connection failures, get additional error detail. Currently,
the only error codes that are mapped are the 3GPP TS 24.008 codes
for "Unknown or missing access point name" and "Requested service
option not subscribed" (which is sometimes returned for an invalid
APN).
(random fixes and cleanups by dcbw)
We need to ensure that the supports task always has the results of the probing,
no matter if the probing was just launched by the plugin grabbing the port, or
by a previous plugin. We do this during supports_port(), by propagating to the
supports task any possible previously cached probing results.
This is because the cinterion plugin can handle RS232 modes, and checking
support for them needs to have the vendor ID probed with AT commands, so
probing is almost always issued in this plugin. By sorting last, we let
other plugins check support first.
We try to look for 'psinfo' indication in AT^SIND? output (available in 3G
devices from Cinterion), and if that is not available, we try to use the
AT^SMONG GPRS monitor (available in 2G devices from Cinterion).
Same USB IDs as the X060s which is driven by Longcheer, but uses the
X22X command set so we have to do a little dance and make sure we
don't claim the X060s here.
The X200 shares the same USB VID and PID as the X060s but the X200
does not use the same AT command set; it uses the X22X plugin
instead. Since both modems also report the same +GMM and +GMI
responses, we have to fall back to using +GMR even though that's
a pretty sketchy way to tell them apart if the firmware ever changes.
Previously plugins could only stop probing, *or* stop probing and
indicate support for a device. For the Alcatel X200/X060s debacle
we need to stop probing and indicate that the plugin does not
support the device at all.
Implemented using a custom invoke method which doesn't call the callback, and
instead calls parent disable passing the callback as argument.
This fix ensures that if a modem gets removed, no invalid modem reference is
passed to the parent disable, as info->modem would be set to NULL and we can
detect it in the custom invoke method.
Split the Samsung initialization sequence from "ATZ E0 V1" to "ATZ"
and "ATE0 V1" - the modem is allowed to ignore the rest of the line
after Z, so echoing was not being turned off, leading to getting
"AT+CIMI\n\n" as part of the IMSI when it is retrieved at startup.
Chromium:
Change-Id: Icfd767174e779e472f8cde419acb163128e4715d
Other devices from the same vendor (x220) need to be handled by
the x22x plugin, so Longcheer can't just rely on the vendor ID
match to know whether it should handle the modem.
Long ago there were problems where certain Huawei devices would
stop responding on various ports, and sometimes would crash
randomly. The theory at the time was that touching the secondary
ports made the device angry, thus the plugin simply opened the
ports and listened for unsolicited messages. But if the device
didn't send any during that 7 second period, MM would not detect
and secondary ports at all. Plus, it was always a hack.
Instead, the new theory is that the device crashes if unsolicited
messages are enabled (^CURC=1), the secondary port gets touched,
*and* then closed and left for a while. Fix that by turning
unsolicited messages off at probe time, on when the device is
enabled, and off again when the device is disabled like happens
for other modems. Thus when MM first detects the modem, it turns
off unsolicited messages and the serial buffer on the secondary
port doesn't fill up and crash the modem.
Second, this allows us to simplify the probing logic quite a bit
so that we can probe all ports we find, but we still wait to probe
the first port so we can turn off unsolicited messages and get
hints about what port is the secondary.
Instead of having two places that custom init stuff got processed
(a hook in the MMPluginBase class itself and a callback too) just
use a callback, and simplify it somewhat so that the plugin tracks
how many tries it cares about and what to do based on the response
or error.
