Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
The "Serving System" indications reported via QMI when the device is
moving may contain LAC/TAC+CID updates or just CID updates.
E.g. this one has "CID 3GPP" (0x1e):
Mon Aug 3 11:22:42 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received
generic indication (translated)... <<<<<< QMUX: <<<<<< length = 33
<<<<<< flags = 0x80 <<<<<< service = "nas" <<<<<< client = 3
<<<<<< QMI: <<<<<< flags = "indication" <<<<<< transaction =
4512 <<<<<< tlv_length = 21 <<<<<< message = "Serving System"
(0x0024) <<<<<< TLV: <<<<<< type = "Serving System" (0x01)
<<<<<< length = 6 <<<<<< value = 01:01:01:02:01:08 <<<<<<
translated = [ registration_state = 'registered' cs_attach_state =
'attached' ps_attach_state = 'attached' selected_network = '3gpp'
radio_interfaces = '{ [0] = 'lte '}' ] <<<<<< TLV: <<<<<< type
= "Data Service Capability" (0x11) <<<<<< length = 2 <<<<<<
value = 01:0B <<<<<< translated = { [0] = 'lte '} <<<<<< TLV:
<<<<<< type = "CID 3GPP" (0x1e) <<<<<< length = 4 <<<<<<
value = 14:C2:A8:00 <<<<<< translated = 11059732
And this one has both "CID 3GPP" (0x1e) and "LTE TAC" (0x25):
Mon Aug 3 11:23:05 2020 daemon.debug [1567]: [/dev/cdc-wdm0] received
generic indication (translated)... <<<<<< QMUX: <<<<<< length = 38
<<<<<< flags = 0x80 <<<<<< service = "nas" <<<<<< client = 3
<<<<<< QMI: <<<<<< flags = "indication" <<<<<< transaction =
4513 <<<<<< tlv_length = 26 <<<<<< message = "Serving System"
(0x0024) <<<<<< TLV: <<<<<< type = "Serving System" (0x01)
<<<<<< length = 6 <<<<<< value = 01:01:01:02:01:08 <<<<<<
translated = [ registration_state = 'registered' cs_attach_state =
'attached' ps_attach_state = 'attached' selected_network = '3gpp'
radio_interfaces = '{ [0] = 'lte '}' ] <<<<<< TLV: <<<<<< type
= "Data Service Capability" (0x11) <<<<<< length = 2 <<<<<<
value = 01:0B <<<<<< translated = { [0] = 'lte '} <<<<<< TLV:
<<<<<< type = "CID 3GPP" (0x1e) <<<<<< length = 4 <<<<<<
value = 32:36:BC:00 <<<<<< translated = 12334642 <<<<<< TLV:
<<<<<< type = "LTE TAC" (0x25) <<<<<< length = 2 <<<
We should therefore allow changes only in the CID, maintaining
whatever LAC/TAC value we had before.
|
|
|
|
According to QC, we should set the IP family in both the
Set IP Family and Start Network messages. After removing this
check the member is never read, only written; this means it's
effectively dead and can be removed.
|
|
Fixes a bug introduced in commit 7e386389, which caused user requested
disable operations to go to step
DISABLING_STEP_FIRST_AFTER_ENABLE_FAILED. For user requested disable,
the first step should be DISABLING_STEP_FIRST.
|
|
Telit FN980 requires more time for becoming responsive to
qmi requests after device appearance.
|
|
|
|
Add a polling mechanism for port responsiveness, since some modem
families require some time before being usable after the serial
ports have been exposed by the kernel.
|
|
|
|
|
|
Querying facility locks should return a FIXED_DIALING lock if PIN2 lock
is enabled.
|
|
Prior to this CL, failure to get pin status while probing facility locks
would not flag an error. Failure to read a pin lock is a critical error
and we return it to higher layers.
|
|
DMS_UIM messages have been deprecated, and have been replaced by
equivalent UIM messages. Use UIM_GET_CARD_STATUS while querying for facility
locks if dms_uim messages were found to be deprecated.
|
|
|
|
The cleanup was missing in one of the steps.
|
|
|
|
So that e.g. in QMI-based devices we have both things, not just one.
|
|
On QMI-capable MBIM devices, also setup the SIM hot swap logic using
QMI over MBIM, so that profile changes are detected.
|
|
The SIM hot swap setup is run during initialization and if it succeeds
it must be available throughout the whole execution of this modem
object.
So, do not cleanup the SUBSCRIBER_INFO flag on 3GPP interface disable,
which is completely unrelated to the SIM hot swap setup logic.
|
|
If enabling the subscriber info notifications fails, we should no
longer have the setup for those notifications, so make sure it's
cleaned up on error.
|
|
Implement eUICC change detection for QMI based modems using one of the
following mechanisms (in order of preference):
1. If the modem supports "get slot status" operation, we monitor
physical slot status indications from the modem for the active
slot to detect when ICCID changes.
2. Use "refresh register all" to subscribe refresh indications when
the eUICC triggers REFRESH operation following the enablement of
a new profile.
3. Use "refresh register" to subscribe refresh indications (file
path of EF_ICCID is used) in a similar way. This is used with
older modems that do not support "refresh register all".
If ICCID change is detected, the already existing SIM hot swap
mechanism in MM is triggered.
|
|
This reverts commit e91f2ef315526a1a8a1b451acb5a190686b05225.
This was wrongly merged squashing multiple commits together. Reverting
to merge separate commits.
|
|
Implement eUICC change detection for QMI based modems using one of the
following mechanisms (in order of preference):
1. If the modem supports "get slot status" operation, we monitor
physical slot status indications from the modem for the active
slot to detect when ICCID changes.
2. Use "refresh register all" to subscribe refresh indications when
the eUICC triggers REFRESH operation following the enablement of
a new profile.
3. Use "refresh register" to subscribe refresh indications (file
path of EF_ICCID is used) in a similar way. This is used with
older modems that do not support "refresh register all".
If ICCID change is detected, the already existing SIM hot swap
mechanism in MM is triggered.
|
|
|
|
For now, just with port type hints for the GM800 in MBIM mode.
|
|
|
|
If the device goes away while we are listing SMS messages, it may
happen that we ask the messaging interface to take a part and the
sms list object has already been disposed. Make sure the part is freed
in that case, so that we avoid memory leaks.
==19138== 6,914 (1,232 direct, 5,682 indirect) bytes in 11 blocks are definitely lost in loss record 5,282 of 5,287
==19138== at 0x483A77F: malloc (vg_replace_malloc.c:307)
==19138== by 0x5023349: g_malloc (in /usr/lib/libglib-2.0.so.0.6600.0)
==19138== by 0x50446FF: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6600.0)
==19138== by 0x5044D6A: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.6600.0)
==19138== by 0x2577FC: mm_sms_part_new (mm-sms-part.c:180)
==19138== by 0x2504D0: mm_sms_part_3gpp_new_from_binary_pdu (mm-sms-part-3gpp.c:385)
==19138== by 0x21A15C: add_sms_part (mm-broadband-modem-mbim.c:5169)
==19138== by 0x21A31F: sms_read_query_ready (mm-broadband-modem-mbim.c:5215)
==19138== by 0x4E600F3: ??? (in /usr/lib/libgio-2.0.so.0.6600.0)
==19138== by 0x4E64638: ??? (in /usr/lib/libgio-2.0.so.0.6600.0)
==19138== by 0x4D3870D: transaction_task_complete_and_free (mbim-device.c:236)
==19138== by 0x4D396B9: process_message (mbim-device.c:616)
|
|
|
|
|
|
|
|
|
|
Enable the SCKS Unsolicited Result Code (URC) to detect SIM hot
swap, and trigger SIM redetection.
|
|
The PLS8 and PLAS9 modems (and likely many others modems supported by
this driver) have two AT capable serial ports: The 'MODEM' AT port
(default for PPP) and the 'APPLICATION' AT port (used for general
control).
The PLS8 modem sends URCs to the APPLICATION port by default, while he
PLAS9 defaults sending URCs to the MODEM port. To get URCs to behave
on both modems, it is necessary to explicitly set the URC reporting
port to APPLICATION.
|
|
If we had already successfully run the sim hot swap context setup
during the initial initialization, make sure we don't re-run on SIM
PIN unlock, because we may be re-creating signal handlers and such.
|
|
|
|
The function shall be needed for profile switch checking.
|
|
If we're asking for IPv4v6 and we get IPv4-only connected, we
shouldn't attempt to provide IPv6 addressing details in the bearer
object, because we would fallback to say DHCP is needed if we were not
able to load any IPv6 details from the modem.
This is, instead of provinding both IPv4 and IPv6 details:
------------------------------------
Properties | apn: internet
| roaming: allowed
| ip type: ipv4v6
| allowed-auth: none, pap, chap, mschap, mschapv2, eap
------------------------------------
IPv4 configuration | method: static
| address: 10.182.100.233
| prefix: 24
| gateway: 10.182.100.1
| dns: 80.58.61.250, 80.58.61.254
------------------------------------
IPv6 configuration | method: dhcp
| prefix: 0
We should report only IPv4 details:
----------------------------------
Properties | apn: internet
| roaming: allowed
| ip type: ipv4v6
| allowed-auth: none, pap, chap, mschap, mschapv2, eap
----------------------------------
IPv4 configuration | method: static
| address: 10.182.100.233
| prefix: 24
| gateway: 10.182.100.1
| dns: 80.58.61.250, 80.58.61.254
|
|
If we ask for IPv4v6 is requested but the network only grants IPv4, we
end up receiving the 'Connect Set' response with nw_error set to
'pdp-type-ipv4-only-allowed'. In this case, we should still succeed
the connection attempt and only report the IPv4 info.
We therefore change the logic to skip processing the nw_error unless
the activation state is reported as ACTIVATED or ACTIVATING.
|
|
If the new iccid is already available, reading the iccid from the
card can be skipped.
|
|
Some quectel modems, like the EC25, require +CTZU=3 in order to have
CCLK? report localtime instead of UTC time.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/233
|
|
Some quectel devices, like the EC25 have a non-standard additional '3'
mode value:
0: Disable automatic time zone update via NITZ
1: Enable automatic time zone update via NITZ
3: Enable automatic time zone update via NITZ and update LOCAL time to RTC
|
|
These modules have 2 different USB layouts:
The default layout with PID 0x9205 (AT+CUSBSELNV=1) exposes 4 TTYs and
an ECM interface:
T: Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=1e0e ProdID=9205 Rev=00.00
S: Manufacturer=SimTech, Incorporated
S: Product=SimTech SIM7080
S: SerialNumber=1234567890ABCDEF
C: #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x4 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
I: If#=0x5 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
The purpose of each TTY is as follows:
* ttyUSB0: DIAG/QCDM port.
* ttyUSB1: GNSS data.
* ttyUSB2: AT-capable port (control).
* ttyUSB3: AT-capable port (data).
In the secondary layout with PID=0x9206 (AT+CUSBSELNV=86) the module
exposes 6 TTY ports:
T: Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 8 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=02(commc) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1e0e ProdID=9206 Rev=00.00
S: Manufacturer=SimTech, Incorporated
S: Product=SimTech SIM7080
S: SerialNumber=1234567890ABCDEF
C: #Ifs= 6 Cfg#= 1 Atr=e0 MxPwr=500mA
I: If#=0x0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I: If#=0x5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
The purpose of each TTY is as follows:
* ttyUSB0: DIAG/QCDM port.
* ttyUSB1: GNSS data.
* ttyUSB2: AT-capable port (control).
* ttyUSB3: QFLOG interface.
* ttyUSB4: DAM interface.
* ttyUSB5: AT-capable port (data).
|
|
|
|
Using the 'UIM switch slot' operation, this commit introduces the
ability to change which SIM slot to be active at any given time in a
Multi-SIM Single-Standby setup.
There is no validation done on whether the selected SIM slot has a
valid SIM card inserted or not; if the user selects a slot without any
SIM card, the newly probed modem object will start in Failed state
right away.
|
|
This commit introduces Multi-SIM Single-Standby support in all QMI
capable devices that support multiple SIM slots.
The 'UIM Get Slot Status' method is used to list all available
physical slots as well as the availability of SIM cards in the
different slots. This method also provides UICC already, so the SIM
objects are created early and exposed early in DBus.
Once all slots are listed, the logic will briefly make each of the
available SIM cards active in order to read additional settings like
IMSI, MCCMNC or the Operator name. This brief switching is required
because in a Single-Standby setup only one SIM can be active at any
given time.
The last slot to probe is always the one that was active originally,
making sure that the modem initialization logic can go on with the
correct SIM slot.
|
|
During the base SIM initialization process, where we ask the modem for
the properties of the currently primary active SIM, we need to make
sure that the SIM is ready before attempting to query this
information.
This explicit wait is required when loading properties for non
active SIMs during the short period of time when they're made active.
|
|
The default SIM creation method will attempt to initialize the SIM
properties during the object creation.
This new method allows creating SIM objects with already known
property values, and therefore not explicitly running the
asynchronous initialization process.
Completely equivalent to mm_base_sim_new_initialized() but creating a
subclassed MMSimQmi instead of the generic MMBaseSim.
|
|
The original logic that parsed the 'UIM Get Card Status Output' did a
bit of guessing to decide what was the current lock status to consider
in the modem. This guessing was fine on systems with a single SIM
slot, but it was very wrong as soon as multiple SIMs had to be
considered.
In a Multi-SIM Multi-Standby setup, with multiple SIMs reported as
active, we should look for the one flagged as "GW primary" to consider
it the primary SIM card of the system,the one required to start a data
connection.
We explicitly ignore the ones flagged as "1X primary", as we don't
consider a SIM card required in CDMA/EVDO setups.
|