ModemManager locks the proxmark3 when it is connected. As it is not a modem,
ModemManager shouldn't be talking to it.
At present, the recommended action in the proxmark3 documentation is to
purge ModemManager to fix this issue.
Note that this vendor uses an unregistered USB device ID, so it is
instead matched by the manufacturer string.
References:
- http://store.ryscc.com/blogs/news/45802433
- http://www.proxmark.org/forum/viewtopic.php?id=1759
A Huawei E173 (with FW 11.126.15.00.445) seems to stop responding on the
primary port (ttyUSB2) when the CGACT is resent on the data port (ttyUSB0).
The CGACT-on-data-port was originally added as a fallback attempt to get
single-port modems to disconnect when all other methods failed.
For single-port modems, the primary port is also the data port so this
patch will have no effect.
For multi-port modems, this patch will retry the CGACT on the primary
port which has a higher chance of success because we already know
the primary port is talking to us, while the data port may still
be stuck in PPP mode.
The MMBroadbandModemQmi will not create a MMSimQmi until the unlock status has
been checked, and therefore this means that when the SIM object is being created
we already know whether the modem supports DMS UIM commands or not, so avoid
further fallbacks in the SIM object.
Newer modems like the MC7455 don't implement the "DMS UIM" commands in the
DMS service, and therefore these modems need to use the UIM service directly.
We include a new flag to detect whether any of the DMS UIM commands is flagged
as invalid, and if so, we'll fallback to the UIM specific implementations for
all.
libqmi version bump to 1.13.7, which includes the new required methods.
Newer modems like the MC7455 don't implement the "DMS UIM" commands in the
DMS service, and therefore these modems need to use the UIM service directly.
The port opening logic is changed completely.
Before this change, the logic would only try 802.3 setting via CTL when the
QmiDevice was being open.
With this new change, instead, we'll use WDA and the new libqmi APIs to query
the link layer protocol expected by both the device and the kernel. If the LLP
matches in both, we assume we're done; if they differ we'll try to update the
LLP expected by the kernel to the one setup in WDA. This change will allow us
to run with the modem using raw-ip if that is what WDA reports by default.
Also bumped the libqmi version to 1.13.6, which has support for the new required
APIs.
Response parsing was being done in different places for AT and QCDM subclasses;
in the case of AT it was being done early, before returning the byte array in
the mm_serial_port_command_finish() response. In the case of QCDM, it was being
done after mm_serial_port_command_finish(), and that was forcing every caller to
cleanup the response buffer once the response was processed.
With the new logic in this patch, the response is always parsed (i.e. looked for
a valid response or an error detected) before mm_serial_port_command_finish()
returns, and actually this method now returns a totally different GByteArray,
not the internal response buffer GByteArray, so there's no longer any need for
the caller to explicitly clean it up. The one doing the cleanup is the parser
method itself in every case.
This change also allows us to return serial port responses in idle, but that's
not changed for now as there's no immediate need.
When valid responses were returned to the caller of the serial command, the
caller itself was responsible for removing from the GByteArray the data that
it was successfully processed (all the data in AT, just 1 message in QCDM). But,
the same logic was missing for the case of errors; we were not explicitly
removing the response and therefore in some cases we would see it propagated
into the next command response. It was common to see this issue when the echo
removal was disabled in the serial port, as in Option/HSO modems:
<debug> (ttyHS3): --> 'AT+CNUM<CR>'
<debug> (ttyHS3): <-- '<CR><LF>+CME ERROR: 14<CR><LF>'
<debug> Got failure code 14: SIM busy
<debug> (ttyHS3) device open count is 1 (close)
<warn> couldn't load list of Own Numbers: 'Failed to parse NV MDN command result: -17'
<debug> (ttyHS3) device open count is 2 (open)
<debug> (ttyHS3): --> 'AT_OPSYS?<CR>'
<debug> (ttyHS3): <-- '<CR><LF>_OPSYS: 1,2<CR><LF><CR><LF>OK<CR><LF>'
<warn> couldn't load current allowed/preferred modes: 'Couldn't parse OPSYS response: '+CME ERROR: 14
_OPSYS: 1,2''
We were trying to load the generic modes supported reported by either *CNTI=2 or
AT+WS46=?, so that then we could filter out the MBM-specific modes unsupported.
But, this may not be ideal, as both these two commands may fail:
[mm-broadband-modem.c:1612] modem_load_supported_modes(): loading supported modes...
[mm-port-serial.c:1237] mm_port_serial_open(): (ttyACM1) device open count is 3 (open)
[mm-port-serial.c:1294] _close_internal(): (ttyACM1) device open count is 2 (close)
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): --> 'AT*CNTI=2<CR>'
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): <-- '<CR><LF>ERROR<CR><LF>'
[mm-serial-parsers.c:364] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error
[mm-broadband-modem.c:1546] supported_modes_cnti_ready(): Generic query of supported 3GPP networks with *CNTI failed: 'Unknown error'
[mm-port-serial.c:1237] mm_port_serial_open(): (ttyACM1) device open count is 3 (open)
[mm-port-serial.c:1294] _close_internal(): (ttyACM1) device open count is 2 (close)
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): --> 'AT+WS46=?<CR>'
[mm-port-serial-at.c:440] debug_log(): (ttyACM1): <-- '<CR><LF>ERROR<CR><LF>'
[mm-serial-parsers.c:364] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error
[mm-broadband-modem.c:1494] supported_modes_ws46_test_ready(): Generic query of supported 3GPP networks with WS46=? failed: 'Unknown error'
[mm-iface-modem.c:3974] load_supported_modes_ready(): couldn't load Supported Modes: 'Couldn't retrieve supported modes'
Instead, we'll ask the modem for the list of modes supported, and return that
directly.
The default setup uses a refresh time of 30s, which means that even if the GPS
location updates are received at a higher frequency, the DBus interface will
still expose at most one update every 30s.
This patch includes a new "SetGpsRefreshTime()" method in the Location
interface, which takes a single 'u' parameter, specifying the refresh rate to
use, in seconds. This method also allows 0 being passed, which will make the
implementation to publish the GPS location updates are soon as ModemManager
detects them.
Along with the new method, a "GpsRefreshTime" read-only property is exposed
to specify the refresh time in effect.
The new method and property will only be applicable if the device has GPS
capabilities.
https://bugs.freedesktop.org/show_bug.cgi?id=89924
Use the "WDS Get Packet Statistics" method to query for the ongoing number
of bytes transmitted or received. The QMI implementation uses different WDS
clients for IPv4 and IPv6; the stats reported are a combination of the values
retrieved from both WDS clients.
The CPMS test parser was expecting 3 groups (parenthesis enclosed lists) of
memory IDs, e.g.:
+CPMS: ("SM","ME"),("SM","ME"),("SM","ME")
But some modems like the Huawei MU609 may just report single elements, not
groups, e.g.:
+CPMS: "SM","SM","SM"
This patch avoids using g_strsplit() to split the groups, as that is unaware
of the possible replies without groups. Instead, a new helper method is
implemented which does the group/item split itself, considering also the
possibility of a reply with mixed groups and non-groups, like e.g.:
+CPMS: ("SM","ME"),"SM","SM"
Additionally, we also now support the case where the groups are empty, e.g.:
+CPMS: (),(),()
https://bugs.freedesktop.org/show_bug.cgi?id=92243
The XCASE terminal mode flag because is no longer specified by POSIX
and has no effect on linux. Because of the latter fact we can remove
it. This fixes a compilation error with musl libc.
. A shift has undefined behaviour if the mathematical result
(lhs * 2^{rhs}) doesn't fit in the range of the resulting type.
In other words, you can't left shift into the sign bit of a
signed integer type.
The error message is:
mm-broadband-modem.c:3308:15: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
SUMMARY: AddressSanitizer: undefined-behavior mm-broadband-modem.c:3308:15 in
Auth settings will be added in a QMI message only if at least one of these is
requested:
* An explicit auth preference is requested.
* User string is given and isn't empty.
* Password string is given and isn't empty.
Given that the Location interface requires 3GPP info reported by the 3GPP
interface, we should only trigger registration checks once the Location
interface has been already enabled and ready to be used. If we don't do this,
we'll end up e.g. getting initial MCCMNC values but never reaching the Location
interface properly.
So, fix this by triggering all registration checks (CDMA and 3GPP) only after
having enabled all interfaces.
LAC/CID may only be given in the serving system indications when the values
change, and therefore we shouldn't reset the values to 0 whenever they're not
reported.
This seems to happen in newer devices; older devices like the MC7710 did always
report the values in the indications.
This check makes no sense. We're converting from a ModemManager enum to a QMI
enum, nothing else; i.e. 'caps' is *not* the current capabilities of the modem.
Variability in the response style from certain modems causes the parsing
of the +CGMR response to fail. For example, the Telit HE910 inserts an
empty string ("") in the second field of the response, causing the
sscanf implementation to fail.
This patch converts the parsing of the CGMR response to a regex that
allows for more flexibility and robustness, and adds unit tests around
the parsing call.
Signed-off-by: Nick Stevens <Nick.Stevens@digi.com>
Michael Farrell
Aleksander Morgado
Thomas Sailer
Dan Williams
Tomas Jura
Felix Janda
Yunlian Jiang
Nick Stevens