The MMPortProbe object is already referenced by the GTask object for
custom init. Instead of keeping another reference of MMPortProbe in the
CustomInitContext, this patch changes the code to simply obtain it from
the source object of GTask.
See https://lists.freedesktop.org/archives/modemmanager-devel/2017-April/004420.html
Looks like a C&P error from the AT#PSNT codepath; all the docs
I can find indicate that AT+SERVICE returns only an integer and
no commas:
<debug> (ttyUSB2): --> 'AT+SERVICE?<CR>'
<debug> (ttyUSB2): <-- '<CR><LF>+SERVICE: 3<CR><LF><CR><LF>OK<CR><LF>'
<debug> Couldn't refresh access technologies: 'Failed to parse +SERVICE response: '+SERVICE: 3''
Commit f9c63bfa0 "build,plugins: update build rules" accidentally
changed the Novatel LTE plugin from 'libmm-plugins-novatel-lte.so' to
'libmm-plugins-novatel_lte.so'. The name becomes inconsistent with other
plugin names.
The operator code (MCCMNC) may also be given encoded in the current
charset (e.g. UCS2).
Based on a patch from Colin Helliwell <colin.helliwell@ln-systems.com>
The method doing the operator name normalization takes as input the
current configured modem charset. If this is UCS2, we will now just
assume this is a hint: the string may or may not come in hex/UCS2.
This logic makes the custom operator name loading in Huawei unneeded,
if the modem is configured in UCS2, we still properly process operator
names coming in plain ASCII.
g_free and g_object_unref are in form of `void (*)(gpointer)`, which
matches the GDestroyNotify signature. An explicit GDestroyNotify cast on
g_free and g_object_unref is thus not needed.
Vendor specific plugins that support QMI or MBIM based devices need to
handle the creation of these modems themselves.
https://bugs.freedesktop.org/show_bug.cgi?id=100372
Original patch by Aleksander Morgado.
The vendor id/string based rules should already be enough to get the
telit plugin bind telit devices.
This simplifies support for future Telit devices, as we wouldn't need
any additional change in the plugin. It also helps when working with
RS232 devices as the user wouldn't need to add the explicit tag to get
the devices bound to this plugin.
https://bugs.freedesktop.org/show_bug.cgi?id=100373
There are 2 main types of udev properties: device-specific and
port-specific.
The port-specific properties are set independently per port (e.g. port
type hints set per interface number for a given vid:pid).
The device-specific properties apply to all ports in the device. Some
of these properties are currently expected in the physical device
(e.g. ID_MM_PLATFORM_DRIVER_PROBE) while some others are expected in
each port (e.g. the plugin udev tag filters).
This patch tries to simplify the logic and just assume that the device
specific tags may be given in either the physical device or the port
device, by providing separate APIs to retrieve port-specific or
device-specific (global) properties. If the same tag is given in both
the device and the port, the one in the device takes preference.
For the generic backend, these new APIs are really useless, as all
device-specific and port-specific properties are always stored in the
port object themselves (there is no 'tree' of devices in the generic
backend, no 'physdev' device).
For the udev backend, though, there really is a difference, as the
tags may be set in port or device.
https://bugs.freedesktop.org/show_bug.cgi?id=100156
Adding the vendor string match allows us to support RS232 devices in
the Telit plugin: the USB vendor id check may now be ignored and
instead we probe for the vendor string via AT commands, which works
even if the device is behind a USB<->RS232 adapter.
https://bugs.freedesktop.org/show_bug.cgi?id=100171
The telit plugin is based on two main ways of checking the purpose of
each port: udev tags flagging specific interfaces (with info taken
from Windows .inf drivers), or otherwise using AT#PORTCFG? to query
the modem about that information. If none of those applies, the port
is ignored by default.
In order to support devices that are not explicitly tagged, the plugin
shouldn't flag as ignored the AT-capable TTYs, instead they are now
grabbed as 'secondary': ports grabbed as secondary will never be used
for either primary/data IF there is another port flagged explicitly
for primary/data.
This fixes the support for modems with a single TTY and no explicit
port type hint tag, e.g. RS232 modems with just one single TTY where
there's no point in specifying port type hints: the port will be
grabbed as secondary, and then automatically promoted to primary/data
as there is no other port grabbed.
https://bugs.freedesktop.org/show_bug.cgi?id=100159
Two main changes in the regex:
* Ignore double quotes around interval numbers.
* Ignore second set of values (i.e. the one after the comma), as it
may not even be given).
We now support at least these two formats:
^SCFG: "Radio/Band",("1-511","0-1")
^SCFG: "Radio/Band\",("1"-"147")
Reported-by: Colin Helliwell <colin.helliwell@ln-systems.com>
* Allow whitespaces prefixing the values row.
* Allow more than one \r\n between the title and the table header.
Reported-by: Colin Helliwell <colin.helliwell@ln-systems.com>
g_type_init() has been deprecated (and also marked with the attribute
'deprecated') since glib 2.36 as the type system is automatically
initialized. Since the minimum version of glib required by ModemManager
is 2.36, calling g_type_init() isn't necessarily in the ModemManager
code.
This patch fixes an uninitialized variable issue in
mm_ublox_parse_ugcntrd_response_for_cid(), which uses an uninitialized
`match_info' when `in_cid' is invalid.
`g_assert_true' and `g_assert_false' are defined in glib 2.38 or later.
The minimum glib version currently required by ModemMamanger is 2.36.
While `g_assert_true' and `g_assert_false' may be preferred over the
more generic `g_assert', it seems like overkill to bump the minimum glib
version requirement just for that. When more code in ModemManager later
requires newer versions of glib, we can migrate all existing code to use
`g_assert_true' and `g_assert_false' when appropriate.
The suggestion to use specific PDP context CIDs was given by Cinterion
for the special case of the Verizon operator, which 'reserves' specific
CIDs for specific purposes.
We don't want to impose that at the Cinterion plugin level, so remove
the PDP context mapping we had.
Therefore, simplify the connection procedure by just overriding the
'dialing' step of the default 3GPP connection sequence, instead of
overriding the whole connection sequence.
Also, we don't need to override the step to gather IP config because
this is already handled by the generic plugin (for DHCP over a network
interface).
We port to GTask for both 3GPP dial and 3GPP disconnect at the same time.
Better check for ^SWWAN support during the first time a bearer is going
to be created.
The enabling phase isn't the correct one because this logic is only run
whenever a modem is detected but not hotplugged (i.e. this step is to
'reset' the modem to generic runtime settings).
We get as input the ^SWWAN index we're interested in, and we loop
through the list of ^SWWAN lines looking for the one we need.
This updated helper method allows working with multi-line ^SWWAN
responses, e.g. given when more than one PDP context is active.
Group together all connection related logic (e.g. context) and define
the context steps directly within the connection sequence processing.
Also, don't initially run a disconnection before the connection; if that
logic is ever needed we should likely have it in the generic modem, not
done per plugin.
And error out early if not asking for IPv4.
So that different concurrent runs of this same test don't clash with
each other:
TEST: test-service-generic... (pid=11124)
/MM/Service/Generic/enable-disable: Activating service name='org.freedesktop.ModemManager1'
Successfully activated service 'org.freedesktop.ModemManager1'
** (plugins/.libs/lt-test-service-generic>:11124): ERROR **: Cannot bind socket: Error binding to address: Address already in use
cleaning up pid 11144
FAIL
The original g_udev_device_get_property_as_int() uses strtol() without
an explicit base (i.e. 0) so that the base is autodetected from the
string whenever possible (e.g. if prefixes with '0x' it is treated as a
hexadecimal string).
But, for ID_USB_INTERFACE_NUM, we explicitly require reading the number
as an hex string, even if we don't have any '0x' prefix.
Reported-by: Matthew Stanger <stangerm2@gmail.com>
This is the value which we actually suggest in the manpage for the mmcli
operation, so just use the same one.
Scanning for 3GPP networks may really take a long time, so a specific timeout must be given:
$ mmcli -m 0 --3gpp-scan --timeout=300
Found 4 networks:
21404 - Yoigo (umts, available)
21407 - Movistar (umts, current)
21401 - vodafone ES (umts, forbidden)
21403 - Orange (umts, forbidden)
https://bugs.freedesktop.org/show_bug.cgi?id=98235
In place of two slightly different regexes for 2g/3g and 2g/3g/4g modems
we now use only one regex with conditional patterns for both supported
and current Bands detection.
Adding also minor fix in test code
When the device is reset, it needs some time before the newly exposed TTYs are
able to reply to our AT commands. We increase the default timeout of the AT
probing commands in order to cope with that, or we'll end up with TTYs of
'unknown' type that aren't used for anything.
The implementation uses +UGCNTRD=? to query whether the per-PDP context
statistics are supported by the device, and if they are, +UGCNTRD is used to
query them.
We only process the statistics for the specific CID we're using.
The parser returns only the results for the CID being specified as input. This
is so that we can just query the statistics of the CID currently in use by the
bearer.
