So, we may have modems with multiple /dev/cdc-wdm ports, like Ericsson modems,
where only 1 of them is MBIM. With the previous logic, we would probe all
/dev/cdc-wdm ports for MBIM as soon as one of the ports was handled by the
cdc_mbim driver. That is totally not optimal, as we are already know that they
are not MBIM (not handled by cdc_mbim).
Instead, fix the logic to just probe for MBIM or QMI if the actual driver
managing the port is MBIM or QMI.
It's been observed that some modems occasionally take a long time to
power down (which may be due to some shutdown sequence that involves
communicating with network). This patch increases the timeout for
powering modem up and down from 10s to 20s.
It's been observed that modems may take a long time to disconnect from
the network under certain network conditions. This patch increases the
timeout for the MBIM_CID_CONNECT set command in the disconnect sequence
from 10s to 30s.
VID/PID: 258d:e000
Instead of returning success and the PIN type + PIN status + Remaining attempts,
this modem returns a plain ERROR_PIN_REQUIRED error, so try to handle that...
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>
Standard GPS setup (raw/nmea) will both enable the GPS module and take full
control of the GPS port. This prevents other processes from reading the NMEA
traces from e.g. a tty. In order to handle this, a new 'unmanaged' GPS location
source is introduced, which will just enable/disable the GPS module, without
reading anything from the GPS port. Of course, both raw/nmea and unmanaged
setups cannot be enabled at the same time.
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.
The first case, with no error, needs to check that there was no original error.
Currently, if an error occurs and the resulting NwError is parsed correctly, the
case split treats it as a no-error case.
Commit 55e40ea b1ae81a in libmbim ("libmbim-glib: add additional GMM
cause codes to MbimNwError") added one more GMM cause code to
MbimNwError. This patch maps that to MMMobileEquipmentError.
This patch requires libmbim >= 1.9.0
When trying to disconnect bearer, if the modem responds with
MBIM_STATUS_ERROR_CONTEXT_NOT_ACTIVATED, take it to mean that the bearer has
already been disconnected.
Notable changes include reporting all available IP configruation
information in the bearer IP details, even if the method is DHCP,
in which case the client should apply the given configuration and
then proceed with DHCP/PPP/SLAAC/etc addressing mechanisms.
QMI, MBIM, and some other plugins have been switched to the "STATIC"
configuration method from DHCP when the firmware supplies all the
necessary details.
Even if the IPv6 bearer method is DHCP, the client should use SLAAC
(eg, IPv6 Router Solicitations, Router Adverisements, and possibly
DHCPv6) to determine the correct prefix and DNS information. In
some cases, even with the DHCP method, and IPv6 "address" will be
given which should be assigned to the data port before beginning
an IP addressing as the mobile network may expect this address
to be used.
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.
