| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
==6971== 52 (16 direct, 36 indirect) bytes in 1 blocks are definitely lost in loss record 3,764 of 6,140
==6971== at 0x4842839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==6971== by 0x4A1ADE8: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==6971== by 0x4A31FF1: g_slice_alloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==6971== by 0x4A3266D: g_slice_alloc0 (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==6971== by 0x49FD397: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==6971== by 0x49FD8B4: g_error_new_valist (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==6971== by 0x49FDACE: g_set_error (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==6971== by 0x187A4C: mm_base_modem_peek_best_at_port (mm-base-modem.c:1129)
==6971== by 0x184116: _at_command (mm-base-modem-at.c:634)
==6971== by 0x1841FE: mm_base_modem_at_command (mm-base-modem-at.c:660)
==6971== by 0x18F6F1: load_sim_identifier (mm-base-sim.c:2016)
==6971== by 0x18CA03: mm_base_sim_load_sim_identifier (mm-base-sim.c:820)
|
|
|
|
|
|
|
|
|
| |
Added a `--messaging-create-sms-with-text' command line option that works similar to
`--messaging-create-sms-with-data', except that it uses the content of the file as the
message text instead of data.
This allows creating mesasges containing both double and single quotes, which was not
possible with the existing `--messaging-create-sms' command line option.
|
|
|
|
| |
Fixes 470dff235c70683928ab0eb39c64151a8a4ceb7c
|
|
|
|
|
|
|
|
|
| |
On MBIM modems, when the SIM is ejected and re-inserted in a quick manner,
the state machine logic encounters a race condition and eventually, the
modem response for subscriber status is ignored. This change accounts
for that state transition without erroring out.
Fixes #672.
|
| |
|
|
|
| |
In some cases modem is taking 7 tries to detect an initialized SIM.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Fix bug in Fibocom FM350 modem where a non-zero signal strength
interval needs to be configured as part of threshold setup.
Fixes #733
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 17ed63637fea7ab7238880ec5eb75df910355dd2.
We were reusing the signal_state_query_ready() callback in the wrong
way.
|
|
|
|
|
| |
After the setup of threshold for signal state notifications, trigger a
query of the current signal state values.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the host is resuming from system suspend, QMI indications
sent by the modem at resume time can be lost. The exact reason why it
happens is still unknown. Until this is fixed, ModemManager currently
workarounds that in QMI mode by listening and reacting to AT URCs too,
which are being received reliably. In order to achieve that,
messaging_setup_unsolicited_events chains the parent's implementation
with its own, effectively setting up handlers for both AT and QMI
channels.
This worked fine on modems such as EG25 which enable SMS indications
by default. However, some modems, such as BM818, don't have these
indications enabled on boot and don't report incoming messages via AT
unless requested via AT+CNMI.
To make SMS handling on resume reliable on such modems, make sure
that MMBroadbandModemQmi also enables/disables unsolicited events
in the same way it already sets up handlers for them.
Signed-off-by: Sebastian Krzyszkowiak <dos@dosowisko.net>
|
|
|
|
|
|
| |
mm_location_3gpp_new_from_string_variant
Signed-off-by: Maxim Anisimov <maxim.anisimov.ua@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
registration wait
The cancellation_id will not be set if the cancellable is already
cancelled by the time g_cancellable_connect() is called.
|
|
|
|
|
|
|
| |
register_in_network_cancelled() may be called early if the given
cancellable is already cancelled, and if so, we want it to remove the
timeout and signal handler, which should have been configured before
setting up the cancellation signal handler.
|
|
|
|
| |
own struct
|
|
|
|
|
| |
So that the variable names in each context identify the action being
performed, to easier reading.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Returning an error in the registration set request completely breaks
the async operation requesting the explicit registration, even if the
modem may have already been registered via indications while waiting
for the set request to be completed.
We now ignore the registration set error if it returns a generic
failure with NwError=0, as in certain Qualcomm based devices. We
ignore unconditionally, without explicitly checking if we're
registered or not, because the upper logic will anyway do that.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/723
|
|
|
|
|
|
| |
So that it is reloaded fresh once re-enabled, otherwise we may be
using stale state values that are not in sync with the state reported
in the interface skeletons.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
E.g. we don't want to update the 3GPP registration state to "idle" if
the interface has already been disabled:
<msg> [1681814812.903723] [modem0] 3GPP registration state changed (idle -> unknown)
<inf> [1681814812.903842] [modem0] consolidated registration state: cs 'idle', ps 'idle', eps 'idle', 5gs 'unknown' --> 'unknown'
<dbg> [1681814812.906194] [modem0] disabling the Modem interface...
<inf> [1681814812.911148] [modem0] disabled modem
<dbg> [1681814812.913453] [ttyACM0/at] device open count is 0 (close)
<dbg> [1681814812.913629] [ttyACM0/at] closing serial port...
<dbg> [1681814812.915559] [ttyACM0/at] serial port closed
<msg> [1681814812.916569] [modem0] state changed (disabling -> disabled)
<dbg> [1681814868.945069] [/dev/cdc-wdm4] number of consecutive timeouts: 1
<msg> [1681814868.950724] [modem0] 3GPP registration state changed (unknown -> idle)
<inf> [1681814868.950885] [modem0] consolidated registration state: cs 'idle', ps 'idle', eps 'idle', 5gs 'unknown' --> 'idle'
<msg> [1681814868.951797] [modem0] state changed (disabled -> enabled)
<dbg> [1681814868.955740] [modem0] registration in network: cancelled
<wrn> [1681814868.958562] [modem0] registration in network failed: Operation was cancelled
|
| |
|
| |
|
|
|
|
| |
registration sequence
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a request to disable the modem arrives while the packet service
state wait is ongoing we were not correctly cancelling the operation.
The main reason for this is that this operation does not change the
modem state, and so the "wait for final state" logic in the disabling
sequence was not being considered.
We solve this by plugging in the Simple.Connect() operation
cancellable in the wait for packet service state operation. The
connection attempt will be cancelled during the disabling sequence as
well, and when that happens we will explicitly halt the packet service
state wait as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now support modem-reported packet service state, instead of
guessing it in the 3GPP interface logic.
The DSD system status reporting a valid access technology is an
indication that the packet service is ready. Instead of holding back
the registration status until the DSD system status reports a valid
value, we will now report the modem as registered, and bind the DSD
system status exclusively to the packet service status.
In the simple connection attempt we're already waiting first for being
registered, and then for being attached in PS.
|
| |
|
|
|
|
|
| |
Use the Packet Service messages to report the state of PS domain,
instead of guessing.
|
|
|
|
|
|
|
|
|
|
|
| |
In certain protocols like QMI or MBIM we may be able to report an
exact packet service state, so there is no need to guess it, as the
guess may not always be right.
The logic will track automatically whether modem-reported packet
service states are available, and use them if so. Otherwise, it'll try
to guess as we were doing before (e.g. if registered in EPS, packet
service is considered attached).
|
|
|
|
|
|
| |
This allows us to skip needing to include the non-existent
build_string_from_mask() or get_string() counterparts in the
documentation index.
|
| |
|
|
|
|
| |
We're going to use certain new features included in the custom tool.
|
|
|
|
|
|
|
|
|
| |
When a request to set a new eps bearer settings is received, ignore the
profile-name when comparing the previous configuration with the new one,
since the modem's profile might already have a name that won't match the
settings provided by the user. Profile names are used in QMI modems.
If the profile name does not match the existing one, the modem will
detach and reattach to the network.
|
|
|
|
|
|
| |
MbimDataClass is a flags bitmask, not an enumeration.
This logic was broken if the reported data class was e.g. 4G+5GNSA.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Users with QMI or MBIM capable modems may want to ensure that these
are never managed using plain AT commands, as that also involves using
PPP. This fallback to AT could happen if the QMI or MBIM port probing
fails for whatever reason.
The new `ID_MM_REQUIRED` udev tag allows specifying that a given port
MUST be successfully grabbed when creating a new modem object, or
otherwise the modem object will not be created at all (even if there
are other fallback control ports like AT that could have been used).
Use this tag with caution.
It is assumed that when this tag is used some other external process
may be monitoring the existence of the modem object in DBus as exposed
by ModemManager, and if it does not appear for any reason then the
modem would be reseted with some other mechanism (e.g. GPIOs, if
available). If no such mechanism to autorecover the modem is in place,
using this tag may leave the modem exposed in the kernel but ignored
by ModemManager.
This tag must be applied on the specific port for which the existence
and usability must be ensured.
E.g. flagging the MBIM port of the Fibocom L850 module as required:
$ vim /lib/udev/rules.d/78-mm-test.rules
ACTION!="add|change|move|bind", GOTO="mm_test_rules_end"
SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="?*", ENV{.MM_USBIFNUM}="$attr{bInterfaceNumber}"
ATTRS{idVendor}=="2cb7", ATTRS{idProduct}=="0007", ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_REQUIRED}="1"
LABEL="mm_test_rules_end"
$ sudo udevadm control --reload
$ sudo udevadm trigger
$ sudo udevadm info -p /sys/class/usbmisc/cdc-wdm0
...
E: ID_MM_REQUIRED=1
E: ID_MM_CANDIDATE=1
|
|
|
|
|
|
| |
To make it clearer that the initial list of flags must be the one
based on which ones are expected in the subsystem and which one the
plugin is requesting.
|
|
|
|
|
|
|
|
|
|
| |
We can remove the port type hint udev tags for the wwan subsystem, as
that logic is now incorporated in the port type hint processing logic
in the daemon itself.
This makes it clearer to know what exact hints are being used, as the
logic is in a single place and it has proper logging of all possible
cases.
|
|
|
|
|
|
| |
Do not do this in the plugin; instead, do it along with the logic that
looks for port type hints in udev, so that we can properly warn if
things don't match.
|
|
|
|
|
| |
Explicitly log when a tag is found, and also warn if too many por type
hints are provided in the same port.
|
|
|
|
|
| |
When processing the hints for port probing we don't care if the AT
port is flagged as primary or secondary.
|
|
|
|
| |
Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com>
|
| |
|