For QCDM devices we want most of what MMSerialPort does, but not
the AT command handling stuff since the commands and responses
aren't AT commands nor are they even strings. So convert everything
that MMSerialPort does into a GByteArray, and let MMAtSerialPort
handle the conversion to strings when necessary.
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.
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.
Anything with vendor ID 0x1c9e really; like Alcatel X020, X030,
X060s, etc. Longcheer appears to make the actual hardware that all
the devices with vendor ID 0x1c9e use. You'll see it in .INF files
with "CMLONG" as part of the USB interface definition.
If the ports are not correctly detected, we need to get the driver's
.INF files to determine what the ports should be, and add them to
the udev rules file.
It turns out that "Modem is [NOT] registered" is not a good indicator
of whether the card has service or not; instead some of the AT!STATUS
response is needed to really determine registration state or not.
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.
at!pcstate is what Sierra CDMA modems use instead of AT+CFUN for
powering the radio on and off. It doesn't turn the modem off completely
like AT+CFUN=0 does for many GSM devices though, so it's quite a lot nicer.
This is the MM equivalent of NM commit 9d7f5b3d084eee2ccfff721c4beca3e3f34bdc50;
Genuine Option NV devices are always supposed to use USB interface 0 as
the modem/data port, per mail with Option engineers. Only this port
will emit responses to dialing commands.
If the modem wasn't connected when disable is called, the generic GSM
code doesn't need to shut anything down and thus closes the serial
port immediately. That means the mbm plugin's CREG=0 and CMER=0 won't
get sent because the port is closed. mbm needs to ensure that it's
commands actually get sent to the modem by really sending them and
waiting for the response before chaining up to the parent's disable.
Should have ignored errors when cleaning up old contexts that
may or may not exist. Rename hso_disable() to something more
appropriate since it's actually part of the enable/connect path,
not the disable path.
Some ZTE devices (MF626 for example) will emit the ZPASR unsolicited
response right after MM opens the port, and they will just throw the
init string away. So retry the init string once; the ZTE devices will
see it the second time and continue as normal.
This is the MM version of NM commit 861e9689c513cbd61fa75205a681a69d4ba8236c
