Need to suggest that it's QCDM since the MMPortProbe stuff
doesn't get passed through to mm_base_modem_grab_port() so
we can't detect QCDM ports automatically there.
We chain up the Generic plugin created MMBroadbandModem objects within the
GDBusObjectManagerServer in MMManager, so that they get properly exported in
DBus.
Also removed the MMSerialError implementation from `src/mm-errors.[h|c]', as it
is now included in the new `include/ModemManager-errors.h' header file. All the
other enums and errors without clashing names will be ported afterwards to the
new base code.
Make port roles more flexible. We have modems that do PPP
on interfaces other than the primary interface, and that
wasn't possible with the old code. So clean up all that
logic and move the port organization code into the core
so we can reduce code in the plugins.
In the new world order, the plugins say whether the port
is a QCDM port, an AT port, or ignored. If it's an AT
port the plugins get to tag it as primary, secondary, or
PPP, or any combination of the 3. This allows for modems
where PPP should really be done on the secondary port
(Huawei E220, Sierra devices) so that the primary port
stays open for command and status.
Modem subclasses no longer get asked to handle port grabbing
themselves. Instead, that's now done by the generic classes
(MMGenericCdma and MMGenericGsm) and the plugins are notified
when a port is grabbed so they can add unsolicited response
handlers for it. After all ports are grabbed by the generic
classes, they get "organized", which assigns various ports
to the roles of PRIMARY, SECONDARY, DATA, and QCDM based
on specific rules and hints that the plugin provided (which
are expressed as MMAtPortFlags). The plugins then have
a chance to perform fixups on the primary port if they choose.
The plugin code is responsible for determining the port
hints (ie MMAtPortFlags) at probe time, instead of having
a combination of the plugin and the modem class do the
job. This simplifies things greatly for the plugins at
the expense of more complicated logic in the core.
Seems that launching AT+CSQF when not registered ends up timing out. AT+CSQF
is meant to be the fast version to get the signal quality, and is expected to
return instantly with the last cached signal quality value. But if we never
got registered, there is no such cached value, so it probably waits to get the
first one.
We must send ATZ alone and once reply received, wait some time before sending
the next initialization commands. Otherwise, the next commands will receive
garbage as reply. The only way to handle this is to override the whole generic
initialization phase.
We will also avoid sending any power-up command, as not needed.
It seems that even though the firmware says it supports
specific CNMI notification values, it really doesn't. Also
set storage to the SIM until we support automatically
determining the right storage in MM. XU870 does not
support ME storage according to +CPMS=?.
USB interface 0 isn't a serial interface; it's probably a custom
Nokia PhoNet port or a custom Icera pseudo-ethernet port. But
it's not a CDC-ACM serial port, at least on the CS17.
Reported by Uwe Geuder.
Various bits of the code didn't check if response was valid
or not during error conditions, and when an error occurs
sometimes it'll be NULL (since not all errors are translated
errors from the modem, some are serial or general ones). We
have to make sure we don't try to use response->str when
response doesn't exist.
Found in the generic CDMA code likely as a result of
d5d9eec2b5 but was a bug long
before that commit happened anyway.
Added a PinRetryCounts property on org.freedesktop.ModemManager.Modem.
This is dictionary that records the number of PIN tries remaining
for each of the possible PIN code types for which the modem is
capable of reporting the count. Also, these counts are kept up
to date across ChangePin and EnablePin operations, not just when
an unlock is attempted.
ModemManager currently encodes the USSD command *141*0# (for MTN South
Africa) as "AA182DA6828D00".
While this works on some modems, for example the E1820, other modems,
for example the E160, require USSD commands that are a multiple of 7
characters long to be padded with 0x0d.
Huawei Mobile Partner dashboard software for Windows encodes *141*0#
as "AA182DA6828D1A" which works on both the E1820 and the E160.
The attached patch pads the USSD command with 0x0d before encoding if
it is a multiple of 7 characters long.
