The user or the packages can install custom dispatcher scripts that
will be run by the ModemManaer daemon itself upon bearer connection
status updates.
Scripts installed by users should go into the
/etc/ModemManager/connection.d directory.
Scripts installed by packages should go into the
/usr/lib/ModemManager/connection.d directory.
The name of the script will specify the order how it's run, so it's
suggested to name them with a numeric prefix, e.g. "99-something".
When the user provides the profile parameter, as per the MM documentation
profile-id is an optional parameter. So with the fix the profile-id
check in input is removed. apn-type is also optional when the user
provides the settings. This check is also removed as part of the fix.
The BUFFER_FULL signal handler is effectively working in the same way
as the response buffer processor, in both cases we may have scheduled
the completion of the serial command, and that in turn may end up
fully disposing the port object. We must make sure the port object is
valid for as long as we need it in this function, so we take a
reference while processing the response buffer.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/535
If no DMS capabilities are reported, we fall back to the capabilities
reported by NAS SSP or NAS TP.
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
MBIM and QMI fallback to CHAP when a username or password is present
but no authentication type was provided. Consider CHAP==UNKNOWN when
using loose comparison.
Some modems, like LE910C1-EUX, express the LTE part of #BND output in
HEX format, but currently the MM parser for such case is limited to
modems that have "ext_4g_bands". This commits use the new MMTelitModel
info to decide how to parse #BND command output.
Fixes#487
Telit revision string can be used to identify the specific model, which
in turn is useful to specialize the behavior of the plugin.
This change adds revision parsing to detect some telit modems. Initially
it adds the ones that have different behaviors in #BND output parsing
for example.
Currently, firmware revision string is obtained via AT+CGMR or AT+GMR
commands from the default mm-broadband-modem. For a class of Telit
modems however this command does not return the actual Telit Software
Package version, but the "Modem FW Version", which is only a component
of the whole firmware. For this class of modems, the correct string is
obtained with "AT#SWPKGV" command.
This change overrides load_revision* functions to add the ability to
parse "AT#SWPKGV" command for the modems that support it, and falls back
to the same logic that was implemented in mm-broadband-modem otherwise.
Alignment padding is not accounted for in the netlink attribute
length. Fix to avoid warnings later if we add shorter fixed
length attributes, even though it currently makes no difference
since we only add a 4 byte attribute
Signed-off-by: Bjørn Mork <bjorn@mork.no>
This fixes the missing NOARP flag on the second and following VLAN
sub-interfaces when multiplexing over the cdc_mbim driver.
ifi_change specifies all the flags we want to change. Any listed
flag which isn't set in ifi_flags will be cleared by the kernel:
if (ifm->ifi_change)
flags = (flags & ifm->ifi_change) |
(rtnl_dev_get_flags(dev) & ~ifm->ifi_change);
Drivers like cdc_mbim set some netdev flags by default, indicating
supported or unsupported features. The driver emulates an ethernet
netdev but it doesn't implement ARP. Clearing NOARP on cdc_mbim
netdevs will block IP transmissions, waiting for an ARP reply we
never will receive.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
foxconn modules get firmware version:
Try with the new FOX service first. If FOX service failed, try with DMS service.
T99W175(vid:105b) ; T77W968(0489:e0b4 ; 0489:e0b5):
qmi service: dms
T99W265(0489:e0da ; 0489:e0db):
qmi service: fox
The port to the meson build system a set of defines were lost, that
made the udev rules and the keyfiles tests to not run properly.
This has been changed so defines are now in their proper place and
tests are run properly.
Fixes#537
Recent ModemManager versions no longer work on the Samsung A5 (Qualcomm
MSM8916) smartphone: MM ends up in an infinite loop trying to probe the
modem over and over again.
Looking at the debug log it seems to be related to a "Slot Status"
indication that comes in during probe time and causes MM to restart
the probing process:
[/dev/wwan0qmi0] Sent generic request (translated)...
<< QMUX: service = "uim"
<< QMI: message = "Register Events" (0x002E)
<< TLV: translated = physical-slot-status
[/dev/wwan0qmi0] Received generic indication (translated)...
<< QMUX: service = "uim"
<< QMI: message = "Slot Status" (0x0048)
<< TLV: translated = { [0] = '[ physical_card_status = 'present', ...
[/dev/wwan0qmi0] Received generic response (translated)...
<< QMUX: service = "uim"
<< QMI: message = "Register Events" (0x002E)
<< TLV: translated = SUCCESS
[modem42] registered for slot status indications
[/dev/wwan0qmi0] Sent generic request (translated)...
<< QMUX: service = "uim"
<< QMI: message = "Get Slot Status" (0x0047)
[modem42] received slot status indication
[modem42] An active slot had a status change, will reprobe the modem
<infinite loop>
The "Slot Status" indication (uim_slot_status_indication_cb) arrives
immediately after starting to listen for the event, which is before
ModemManager has actually loaded the initial slot status in
uim_get_slot_status_ready. In this situation !slot_array_status_equal()
will always cause the modem to reprobe, even though it is not necessary
during the probe phase.
To fix this add a simple check to uim_slot_status_indication_cb() that
ignores the indication if the initial slot status was not loaded yet.
The numeric fields in the +COPS=? response were relying on a very weak
parsing logic, assuming that they were single-digit numeric values and
not using the common string to integer conversion utilities.
This commit improves the conversion from the 3GPP/ETSI defined network
availability and access technology values to the MM defined ones,
providing enum-based matches even if the numeric values are the same.
The commit also fixes the parsing of access technology values > 10,
required to report 5G related values.
This assumes the needed modem hardware is typically not available
inside containers. If however, the local admin configures the container
to get access to the hardware in question, ModemManager can be
instructed to run in that specific container by doing:
`sudo systemctl edit ModemManager.service`
Then entering the following text in the editor:
[Unit]
# Remove condition of "not container"
ConditionVirtualization=
Upon saving/exiting, ModemManager can then be started with:
`sudo systemctl start ModemManager.service`
Signed-off-by: Simon Deziel <simon@sdeziel.info>
+CGDCONT? may list profiles with IDs that are illegal to write, i.e.
+CGDCONT=? returns a minimum ID larger than some of the existing
profiles. E.g. for Fibocom L610-EU, +CGDCONT=? returns
+CGDCONT: (1-7),"IP",,,(0-3),(0-4)
+CGDCONT: (1-7),"IPV6",,,(0-3),(0-4)
+CGDCONT: (1-7),"IPV4V6",,,(0-3),(0-4)
+CGDCONT: (1-7),"PPP",,,(0-3),(0-4)
+CGDCONT: (1-7),"Non-IP",,,(0-3),(0-4)
while the default EPS bearer is established at profile 0:
+CGDCONT: 0,"IP","xxx","xxx.xxx.xxx.xxx",0,0
[...]
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
The set_initial_eps_bearer_settings() operation is the same in XMM
capable and generic MBIM modem objects. Place it in a common shared
interface so that we don't duplicate code.
Use the same logic always to decide which is the best GPS control/data
port, and then perform the initial port setup (GNSS engine off) only
that single port.
We're not going to implement all XMM shared operations from the shared
utils, as the newer Intel modems support the new operations in the
Microsoft MBIM Extensions.
Just inherit the GNSS management capabilities.
