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.
In particular, g_regex_match() and g_regex_match_full() allocate a
match_info structure on both success and failure, so calling
g_match_info_free() only in the success case is insufficient.
BUG=None
TEST=Inspection
Change-Id: Iea76b5b5dc3ec48120e15601a5e2dd45322133d8
On a ZTE MF626, sometimes the aux port will respond only with
"ERROR" to probing commands (while the SIM is starting up) and
previously we'd lose the port because we were only looking for
valid probe responses. But if the port returns ERROR or CME ERROR
etc we know it's an AT port and that we can use it once we've
gotten the type response (CDMA or GSM) from the main port.
The F5521gw resets various port properties like echo when the port
is flashed, which was happening on disconnect. Since MM had already
turned of echo with ATE0, and the AT parser in-use expected no
echo, this confused MM when the port magically started echoing commands
back. We don't need flashing on the Ericsson devices because there
will always be a free AT port even if PPP is used for a secondary
PDP context, so we can just skip flashing entirely for these
devices.
During the explicit access technology check, the plugin would request
specific 2G (OCTI) and 3G (OWCTI) technologies explicitly. Some devices
(like Nozomi) don't support the AT_OWCTI command, which leaves us with
only AT_OSSYS for determining whether the device is registered with
the 3G network or the 2G network. So like the unsolicited mode change
handling code, when requesting access technology explicitly, ask for
generic 2G/3G tech first, and then get the specific tech. If the
device doesn't support explicit 3G tech then at least we have the
generic 3G tech from OSSYS to use.
The Nozomi cards were early CardBus devices that used a direct PCI
interface (instead of the more usual PCI<->USB controller) and the
'nozomi' kernel driver. They use the same command set as most other
early Option NV modems. Nozomi was always supposed to be driven
by the option plugin, but apparently that got broken when adding
some of the driver/vendor checks.