There's no real need for a custom Gobi plugin any more. All the vendor-specific
Gobi-powered modems should be handled by vendor-provided plugins supporting QMI
modems; or otherwise, as a last resort, by the generic plugin.
For Dell-branded Novatel, Sierra and Ericsson modems.
The Novatel plugin will no longer accept every Dell-branded modem, which was
the current situation. Instead, a new Dell plugin will take care of probing for
the correct vendor string, and based on the results create a specific Novatel,
Sierra or Ericsson modem.
In order to properly support this, the Novatel, Sierra and MBM plugins now
export their implementations into non-inst libraries that the Dell plugin will
import.
Also, for now, the Dell plugin doesn't make any difference between e.g. Sierra
or Ericsson MBIM implementations, just a generic MBIM modem is created in both
cases, as that is anyway what the Ericsson MBM and Sierra plugins do already.
https://bugs.freedesktop.org/show_bug.cgi?id=86713
In short:
* The 'sierra-legacy' plugin will handle all the old AT based modems,
including the DirectIP ones. This plugin is filtered by driver ('sierra' or
'sierra_net') and forbidden-drivers ('qmi_wwan' and 'cdc_mbim'). This plugin
should also grab HP and AT&T branded models if they are handled by the
proper kernel driver.
* The 'sierra' plugin will only handle QMI or MBIM based Sierra modems, which
are really all the new ones. This plugin is filtered by VID (0x1199) and
driver (qmi_wwan and cdc_mbim).
For this separation to work, the 'sierra' and 'sierra_net' plugins need to be
complementary to each other.
Build all targets, except for CLI tools (mmcli, uml290), with special
flags needed for collecting code coverage information when the build has
been configured with --enable-code-coverage.
Three new targets are available in the top build directory:
- `check-code-coverage' runs the test suite and generates a code
coverage report,
- `code-coverage-capture' generates a code coverage report from already
collected data, which can come in handy when one wants to see code
paths touched by a particular test,
- `code-coverage-clean' removes the collected coverage data and the
generated reports.
This patch increases the response timeout for the probe AT commands for
altair modems.
We've been noticing some altair modems taking upto 6 seconds to respond to the
initial probe command after a reset which results in modem-manager
timing out and sending a second probe command. The modem sends a response
after about 6 seconds for the initial probe command which modem-manager
treats as response to second probe command and this results in the
modem-manager and modem going out of sync because the modem's second
probe response is treated as response to the next initialization AT command
sent by modem-manager and so on.
Change-Id: Iad8b0786327b153fd95c8ee4516f352325a42cf7
Newer huawei modems, like the E3372, use the following ^GETPORTMODE response
format:
^GETPORTMODE: TYPE: WCDMA: ,pcui:1,modem:2,ncm:3,mass:4,mass_two:5,
This patch updates the parser that looks for the control TTY (pcui) and data TTY
(modem).
https://bugs.freedesktop.org/show_bug.cgi?id=86658
The timeout for starting ModemManager on the test bus was 3s, which is
sufficient under normal conditions. However, when running ModemManager
tests on a build infrastructure under a heavy load, we've observed that
the timeout isn't always sufficient and that becomes the source of false
test failures. This patch increases the timeout to 30s, which shouldn't
introduce any unexpected behavior under normnal conditions while
addressing the timeout issue on heavily loaded systems.
The MF60 exposes a QMI+net pair, but they are unusable as the WDS service
returns error when e.g. launching a connection.
So, fallback to AT+PPP in this device.
Third revision of Huawei nwtime support. Takes on feedback from the
mailing list including helpers, some basic tests and use of the ^NTCT
command to determine network time support (^NWTIME). Expanded test cases,
more use of g_assert and more logical helper return values/errors.
Signed-off-by: David McCullough <david.mccullough@accelecon.com>
Implement GPS support on the MU609 and MU090 Huawei modules.
Its highly likely the commands are the same for other Huawei modems
and it just needs to be activated via udev rules that flag the GPS port
with ID_MM_HUAWEI_GPS_PORT=1.
There are a lot of options that can be tweaked on the Huawei GPS setup,
this code just chooses a simple default for unassisted, standalone GPS
operation.
Signed-off-by: David McCullough <david.mccullough@accelecon.com>
The PHS8 in QMI-mode doesn't support GPS location retrieval via QMI, so we will
fallback to use the AT-based setup and the TTY for reading NMEA traces.
The MU609 modems from Huawei have a bug (confirmed by Huawei) that causes
the modem to reset if AT^GETPORTMODE is issued.
I have provided and example udev rule I use to disable this command as a
patch, feel free to drop that if its not acceptable. Since I cannot tell
the modem type from within the udev rules this is less specific than my
previous code based patch, but much simpler ;-)
I have two modems that share the same USB ID, however, neither supports the
^GETPORTMODE command (and one of them crashes when it is issued). Perhaps
someone with a Huawei that supports ^GETPORTMODE can check their USB ID's
and see if they clash.
Here is a comment from the Huawei devs:
> We confirmed this is a issue. This is Qualcomm baseband command at Data
> Card. We didn’t delete and block it. We will fix this issue in next FW.
> Thank you very much.
Sign-off-by: David McCullough <david.mccullough@accelecon.com>
The setup in Cinterion modems goes as follows:
AT+CNMI=<mode>[, <mt>[, <bm>[, <ds>[, <bfr>]]]]
For each field, several setups are available, so we could use a default value,
as we were doing until now (+CNMI=2,1,2,2,1).
BUT, not every Cinterion modem allows the same set of settings. For example, the
new PHS8 only allows '0' for the <ds> value:
AT+CNMI=?
+CNMI: (0,1,2),(0,1),(0,2),(0),(1)
So, instead of hardcoding the setup, try to find the best suitable one for each
modem. We'll parse the +CNMI=? test response to know which values are supported
during the messaging support check, which is run once during initialization.
With the new 'huawei-cdc-ncm' driver in the kernel, we now may get a
/dev/cdc-wdm AT-capable port exposed by the Huawei device. If so, we must use
this port for NDISDUP dialling in order to get the network interface connected.
Devices with Icera chipsets (USB305) don't support the Qualcomm
proprietary $QCPDPP command, and we must use the Icera command
instead. Otherwise authenticated bearer creation will fail.
Split out the %IPDPADDR parsing into a helper and add testcases for it,
and add support for IPv6 handling. If the returned IPv6 is link-local,
the address should be assigned to the interface and SLAAC performed to
retrieve the actual IPv6 prefix and RDNSS/DNSSD information.
Subclasses may need to know which IP families were used for the setup
so they can return the correct IP configuration. We can't just use
the MMBearer default_ip_family becuase that isn't the family that
was actually used during the connection.
