Re: SIM PIN Unlock Error in MM 1.22.0
Thanks Aleksander!
The fix works.
Amol
From: Aleksander Morgado
Sent: Monday, April 22, 2024 2:35 PM
To: Amol Lad
Cc: ModemManager (development)
Subject: Re: SIM PIN Unlock Error in MM 1.22.0
Hey Amol,
>
> We are getting following error when trying to send pin to the SIM card. The
> problem is not observed in MM 1.20.4. However, please note that the SIM card
> does unlocks after the below command even though error is reported.
>
> # mmcli -i 0 --pin=1234
> error: couldn't send PIN code to the SIM:
> 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Couldn't get
> interface skeleton'
>
> Now, after looking through the code, following change is causing this issue.
> This change was not present in 1.20.4
>
> mm-broadband-modem-mbim.c:
> if ((self->priv->enabled_cache.last_ready_state !=
> MBIM_SUBSCRIBER_READY_STATE_DEVICE_LOCKED &&
> ready_state == MBIM_SUBSCRIBER_READY_STATE_DEVICE_LOCKED) ||
> (self->priv->enabled_cache.last_ready_state ==
> MBIM_SUBSCRIBER_READY_STATE_DEVICE_LOCKED &&
> ready_state != MBIM_SUBSCRIBER_READY_STATE_DEVICE_LOCKED)) {
> mm_obj_dbg (self, "Lock state change detected");
> active_sim_event = TRUE;
> }
>
> self->priv->enabled_cache.last_ready_state = ready_state;
>
> if (active_sim_event) {
> mm_iface_modem_process_sim_event (MM_IFACE_MODEM (self));
> }
>
> What is happening is when SIM PIN lock state changes then
> mm_iface_modem_process_sim_event () is called which eventually calls
> mm_base_modem_set_reprobe(). The reprobe, "unexports" the current modem
> instance (modem 0) and recreates a new modem instance (1). As a result, the
> above mmcli command is reporting error. I'm not sure why this should happen
> for SIM Lock state change.
I think this has been fixed in MM git main branch; is there any chance
you could test with that? See
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/19fd9c634b8f2876694d18a77a3b686a0c08bf34
--
Aleksander
SIM PIN Unlock Error in MM 1.22.0
Hi,
We are getting following error when trying to send pin to the SIM card. The
problem is not observed in MM 1.20.4. However, please note that the SIM card
does unlocks after the below command even though error is reported.
# mmcli -i 0 --pin=1234
error: couldn't send PIN code to the SIM:
'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Failed: Couldn't get
interface skeleton'
Now, after looking through the code, following change is causing this issue.
This change was not present in 1.20.4
mm-broadband-modem-mbim.c:
if ((self->priv->enabled_cache.last_ready_state !=
MBIM_SUBSCRIBER_READY_STATE_DEVICE_LOCKED &&
ready_state == MBIM_SUBSCRIBER_READY_STATE_DEVICE_LOCKED) ||
(self->priv->enabled_cache.last_ready_state ==
MBIM_SUBSCRIBER_READY_STATE_DEVICE_LOCKED &&
ready_state != MBIM_SUBSCRIBER_READY_STATE_DEVICE_LOCKED)) {
mm_obj_dbg (self, "Lock state change detected");
active_sim_event = TRUE;
}
self->priv->enabled_cache.last_ready_state = ready_state;
if (active_sim_event) {
mm_iface_modem_process_sim_event (MM_IFACE_MODEM (self));
}
What is happening is when SIM PIN lock state changes then
mm_iface_modem_process_sim_event () is called which eventually calls
mm_base_modem_set_reprobe(). The reprobe, "unexports" the current modem
instance (modem 0) and recreates a new modem instance (1). As a result, the
above mmcli command is reporting error. I'm not sure why this should happen for
SIM Lock state change.
The logs are below. As you can see at timestamp 1713774618.140486, the modem
is unexported and then it's all cleanup and creation of new modem instance.
Please advise.
[1713774617.896807] [modem0/sim0] sending PIN...
[1713774617.896908] [/dev/cdc-wdm0] sent message...
<< RAW:
<< length = 80
<< data = 03:00:00:00:50:00:00:00:17:00:00:00...
[1713774617.897063] [/dev/cdc-wdm0] sent message (translated)...
<< Header:
<< length = 80
<< type= command (0x0003)
<< transaction = 23
<< Fragment header:
<< total = 1
<< current = 0
<< Contents:
<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
<< cid = 'pin' (0x0004)
<< type= 'set' (0x0001)
<< Fields:
<< PinType = 'pin1'
<< PinOperation = 'enter'
<< Pin = '1234'
<< NewPin = '(NULL)'
[1713774618.139714] [/dev/cdc-wdm0] received message...
>> RAW:
>> length = 144
>> data = 07:00:00:80:90:00:00:00:00:00:00:00...
[1713774618.139908] [/dev/cdc-wdm0] received message (translated)...
>> Header:
>> length = 144
>> type= indicate-status (0x8007)
>> transaction = 0
>> Fragment header:
>> total = 1
>> current = 0
>> Contents:
>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df)
>> cid = 'subscriber-ready-status' (0x0002)
>> Fields:
>> ReadyState = 'not-initialized'
>> SubscriberId = '###'
>> SimIccId = '###'
>> ReadyInfo = 'none'
>> TelephoneNumbersCount = '0'
>> TelephoneNumbers = '###'
[1713774618.139979] [modem0] received notification (service
'basic-connect', command 'subscriber-ready-status')
[1713774618.140012] [modem0] processed subscriber ready status
notification
[1713774618.140033] [modem0] Lock state change detected
[1713774618.140052] [modem0] Processing SIM event
[1713774618.140486] [device
/sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb3/3-1] unexported
modem from path '/org/freedesktop/ModemManager1/Modem/0'
[1713774618.140532] [modem0] supported notifications: signal (no),
registration (no), sms (no), connect (no), subscriber (no), packet (no), pco
(no), ussd (no), lte attach info (no), provisioned contexts (no),
slot_info_status (no)
[1713774618.140585] [cdc-wdm0/mbim] Releasing client for service 'uim'...
[1713774618.140623] [/dev/cdc-wdm0] releasing 'uim' client with flags
'release-cid'...
[1713774618.140657] [/dev/cdc-wdm0] unregistered 'uim' client with ID '2'
[1713774618.140769] [/dev/cdc-wdm0] sent message...
<< RAW:
<< length = 17
<< data = 01:10:00:00:00:00:00:07:23:00:05:00...
[1713774618.140910] [/dev/cdc-wdm0] sent generic request (translated)...
<< QMUX:
<< length = 16
<< flags = 0x00
<< service = "ctl"
<< client = 0
<< QMI:
<< flags = "none"
<< transaction = 7
<< tlv_length = 5
<< message = "Release CID" (0x0023)
<< TLV:
<< type = "Release Info" (0x01)
<< length = 2
<< value = 0B:02
<< translated = [ service = 'uim' cid = '2' ]
[1713774618.140994] [/dev/cdc-wdm0] sent message...
<< RAW:
<< length = 65
<< data = 03:00:00:00:41:00:00:00:15:00:00:00...
[1713774618.141233] [/dev/cdc-wdm0] sent message (translated)...
<< Header:
<<
Bearer connection disconnect cause
Hi, We getting connection disconnect randomly with below log from MM. We do have a way to recover from it but is there a way to know the cause of disconnect? Such as whether it is "network initiated disconnection" or "modem initiated". Any pointers in this regard will be helpful (to find out the cause of disconnection) [modem0] state changed (connected -> registered) [modem0/bearer1] connection #1 finished: duration 129s, tx: 1159 bytes, rx: 112 bytes Thanks, Amol
Re: qmicli-firmware-update failure on a batch of EM7455
It seems the failure is occurring at the last chunk (#61). The status returned in "134". Please advise if any idea what this error status means? Bjørn, I saw one of your post in the mailing list regarding qmi-firmware-update failure? Any idea what is this error? Below is the log from qmi-firmware-update with "-v" option [08 Nov 2023, 03:56:49] [Debug] [qfu,qdl-message] sent write-unframed-req: [08 Nov 2023, 03:56:49] [Debug] [qfu,qdl-message] sequence: 60 [08 Nov 2023, 03:56:49] [Debug] [qfu,qdl-message] chunk size: 1048576 [08 Nov 2023, 03:56:49] [Debug] [qfu-qdl-device] >> 27:3C:00:00:00:00:00:00:00:10:00:7B:7F:1D:92:DB:39:68:AE:2D:CE:8D:08:A5:12:20:BD:78:DA:6B:6F:52:21:6 [08 Nov 2023, 03:56:49] [Debug] [qfu-qdl-device] << 7E:28:3C:00:00:00:00:00:00:00:FE:EF:7E [13] [08 Nov 2023, 03:56:49] [Debug] [qfu-qdl-device] << 28:3C:00:00:00:00:00:00:00 [9, unframed] [08 Nov 2023, 03:56:49] [Debug] [qfu,qdl-message] received write-unframed-rsp [08 Nov 2023, 03:56:49] [Debug] [qfu,qdl-message] status: 0 [08 Nov 2023, 03:56:49] [Debug] [qfu,qdl-message] sequence: 60 [08 Nov 2023, 03:56:49] [Debug] [qfu-image] reading chunk #61 [08 Nov 2023, 03:56:49] [Debug] [qfu-image] chunk #61 size: 462805 bytes [08 Nov 2023, 03:56:49] [Debug] [qfu-image] chunk #61 offset: 63963536 bytes [08 Nov 2023, 03:56:49] [Debug] [qfu-image] chunk #61 successfully read [08 Nov 2023, 03:56:49] [Debug] [qfu,qdl-message] sent write-unframed-req: [08 Nov 2023, 03:56:49] [Debug] [qfu,qdl-message] sequence: 61 [08 Nov 2023, 03:56:49] [Debug] [qfu,qdl-message] chunk size: 462805 [08 Nov 2023, 03:56:49] [Debug] [qfu-qdl-device] >> 27:3D:00:00:00:00:00:D5:0F:07:00:2D:57:CF:B7:2D:1D:13:00:53:55:E6:1A:B9:C1:9D:65:78:7F:02:5E:9F:85:7 error: error downloading image: couldn't write in session: operation returned an error status: 134 [08 Nov 2023, 03:56:49] [Debug] [qfu-qdl-device] << 7E:28:3D:00:00:00:00:00:86:00:5D:B6:7E [13] [08 Nov 2023, 03:56:49] [Debug] [qfu-qdl-device] << 28:3D:00:00:00:00:00:86:00 [9, unframed] [08 Nov 2023, 03:56:49] [Debug] [qfu,qdl-message] received write-unframed-rsp [08 Nov 2023, 03:56:49] [Debug] [qfu,qdl-message] status: 134 [08 Nov 2023, 03:56:49] [Debug] [qfu,qdl-message] sequence: 61 From: Amol Lad Sent: Tuesday, November 7, 2023 11:05 AM To: ModemManager (development) Subject: qmicli-firmware-update failure on a batch of EM7455 Hi Aleksander, I'm facing a strange issue. I've received a new batch of Sierra EM7455 modems and trying to update firmware in the modem and I get following error message: # qmi-firmware-update -t /dev/ttyUSB0 -U SWI9X30C_02.33.03.00.cwe SWI9X30C_02.33.03.00_VERIZON_002.079_001.nvu finalizing download... (may take more than one minute, be patient) error: error downloading image: couldn't write in session: operation returned an error status: 134 Any idea what error status 134 could mean? This is definitely something to do with the modem and I am able to update EM7455 from an older lot just fine.. How to enable more debugs in qmicli-firmware-update to understand what error modem is reporting? Thanks, Amol
qmicli-firmware-update failure on a batch of EM7455
Hi Aleksander, I'm facing a strange issue. I've received a new batch of Sierra EM7455 modems and trying to update firmware in the modem and I get following error message: # qmi-firmware-update -t /dev/ttyUSB0 -U SWI9X30C_02.33.03.00.cwe SWI9X30C_02.33.03.00_VERIZON_002.079_001.nvu finalizing download... (may take more than one minute, be patient) error: error downloading image: couldn't write in session: operation returned an error status: 134 Any idea what error status 134 could mean? This is definitely something to do with the modem and I am able to update EM7455 from an older lot just fine.. How to enable more debugs in qmicli-firmware-update to understand what error modem is reporting? Thanks, Amol
Re: SIM Application toolkit commands
>> The Twilio Super SIM will send a Proactive Command NAA Initialization and >> Full File Change Notification to the terminal on the IMSI change. Some >> modems, like the Quectel BG95 or EC25 will send a URC if >> +QUSIM: 1 >> if it is a USIM and >> +QUSIM: 0 >> if it's a regular SIM >> no idea about other modems however. >> > You mean the +QUSIM URC is sent to the host whenever the Full File > Change Notification is received by the terminal on the IMSI change? > i.e. no need to STK supported by the host in this case, right? >> I can arrange to get you a SIM for testing if needed as this is an area I'm >> interested in as well. I can also provide a SIMtrace2 pcap (or raw APDUs if >> preferred) capture of the communications between the terminal and the SIM if >> that would be helpful. >> > How do you instruct the SIM to switch IMSI? One way is mentioned here: https://www.twilio.com/docs/iot/supersim/super-sim-multi-imsi-applet#force-a-switch-to-the-next-imsi -- Aleksander
SIM Application toolkit commands
Hi, Does ModemManager support SIM application tool kit with proactive SIM commands? My assumption is most of these SIM application tool kit commands should be handled by the modem but I'm unclear what is the role of host CPU / ModemManager in these commands? For example, many SIMs support multi-IMSI i.e. depending on the location, a particular IMSI is used for network connection. When a SIM changes its IMSI, the SIM application tool kit applet sends a REFRESH proactive command to the host device (or modem). This instructs the device to re-read the data on the SIM, including the new IMSI. So how shall ModemManager know that IMSI has been changed and what it is supposed to do? What is the role of ModemManager in handling these commands? Following link gives an example of multi IMSI SIMs and SIM application tool kit commands https://www.twilio.com/docs/iot/supersim/super-sim-multi-imsi-applet (As per the specs, list of MANDATORY application toolkit features (from ETSI TS 102 223) :- * Poll Interval * Status * Timer * Provide local information (MCC, MNCsend sms command, IMEI, NMR) * Setup Menu * Terminal Profile * Events (timer expiration, location status) * Refresh * More time ) Any advise in this regard is highly appreciated. Thanks Amol
RE: initial bearer apn
Hi Aleksander, How is the initial-attach-ip-type decided in the NM MR you shared? I've seen in a network in New Zealand where initial-attach-iptype has to be IPV4 and then it can be changed to IPV4V6 during connection establishment. Also, modem might have already gone through registration process before "--3gpp-set-initial-eps-bearer-settings" is called. So when are we supposed to call "mmcli --3gpp-set-initial-eps-bearer-settings"? Thanks -Original Message- From: ModemManager-devel On Behalf Of Aleksander Morgado Sent: Friday, 17 March 2023 3:13 PM To: Juan A. Rubio Cc: modemmanager-devel@lists.freedesktop.org Subject: Re: initial bearer apn Hey! > > I'm using ModemManager version 1.18.12. I'm also using Network Manager > 1.22.16 > > I'm wondering what part of the system stores or configures the initial > bearer apn, since I'm not explicitly setting this value? > > $ mmcli -m 0 | grep 'bearer apn' >| initial bearer apn: Telstra.internet > > Is this a default value set by MM or NM, or is this something that is > stored in the SIM by the carrier? > In LTE there are always two different APN settings in use: * initial EPS default bearer settings (a.k.a. attach APN) * data connection settings (a.k.a. connection APN). The attach APN is the APN used during *registration* to the LTE network, it is LTE-specific. This APN is stored as a profile configured in the device, and is subject to change via different ways; e.g. it could have been preconfigured in the device via carrier settings, or it could be manually set by the user, or it could even be updated via OTA. In MM we have 2 different sets of attach APN info: the settings requested by the user (these are the ones you see in mmcli -m a output) and the settings agreed with the network (these are the ones you see in the bearer object reported as initial bearer in the mmcli -m a output). Some networks allow you to request any initial APN (even the blank "" APN) and then it will tell you which one to use (so requested and agreed may be different). Other networks are strict and if you don't request the correct one the registration will be rejected (very common in Japan for some reason). Also IP type is important here, if you request a IPv4-only initial attach APN, attempting to get a IPv6 connection later on won't work. The connection APN is the one that you're probably most familiar with. This is the APN that you need to get the modem connected to e.g. the Internet. This may or may not be the same as the initial APN! E.g. I recall some network in Germany where you required an initial APN just to get the service but it wouldn't give you internet connectivity; you then had to connect to a different APN in order to get the bearer to the Internet established correctly. In most cases, though, both initial and connection APNs are the same. In NetworkManager 1.42 the user will have explicit settings to configure the initial attach APN as part of the config profile, see https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1331 if you're using an older version, and you need to specify a custom attach APN, you can do it with mmcli. -- Aleksander
RE: +C5GREG? does not report any output from mmcli
Thanks Aleksander, Does "mmcli --get-cell-info" returns the cell info like tac, ci from the last URC received from the modem? Basically, if URC is not received from the modem then is it possible that --get-cell-info report stale cell information (if the device is moving)? Amol -Original Message- From: Aleksander Morgado Sent: Friday, 3 February 2023 3:01 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: +C5GREG? does not report any output from mmcli > > I'm trying on MM 1.20.4 and noticing that AT+C5GREG? (and also AT+CREG?) do > not report any output when called from mmcli. > > # mmcli -m 0 --command=AT+C5GREG? > response: '' > # mmcli -m 0 --command=AT+CREG? > response: '' > # mmcli -m 0 --command=AT+C5GREG=? > response: '+C5GREG: (0-2)' > > +C5GREG? (or +CREG?) is correctly reported using minicom so modem does > responding to these commands. > > Any idea what could be going wrong? I'm trying with Telit FN990 but looks > like this is a generic issue. > ModemManager has a mechanism to process URCs coming in the AT response flow. Your command response is being "eaten" by this mechanism, which ModemManager processes as a URC. This is a known limitation of --command; at the end ModemManager cannot ensure that a real valid +C5GREG URC is interleaved between your command and your response. I guess we could try to improve that, but I'd prefer to suggest not using +C5GREG? in --command, because attempting that would be tricky :D -- Aleksander
+C5GREG? does not report any output from mmcli
Hi Aleksander, I'm trying on MM 1.20.4 and noticing that AT+C5GREG? (and also AT+CREG?) do not report any output when called from mmcli. # mmcli -m 0 --command=AT+C5GREG? response: '' # mmcli -m 0 --command=AT+CREG? response: '' # mmcli -m 0 --command=AT+C5GREG=? response: '+C5GREG: (0-2)' +C5GREG? (or +CREG?) is correctly reported using minicom so modem does responding to these commands. Any idea what could be going wrong? I'm trying with Telit FN990 but looks like this is a generic issue. Thanks Amol
RE: mmcli "--timeout=[SECONDS]" does not work with --simple-connect
Hi Aleksander,
I think the reason is the "60" seconds timeouts configured in
register_in_3gpp_or_cdma_network() in mm-iface-modem-simple.c.
Now, how do we handle scenarios where network takes more than 60 seconds to
register? --simple-connect will always timeout..
Please advise.
Amol
-
static void
register_in_3gpp_or_cdma_network (MMIfaceModemSimple *self,
const gchar *operator_id,
GAsyncReadyCallback callback,
gpointer user_data)
{
RegisterInNetworkContext *ctx;
GTask *task;
ctx = g_new0 (RegisterInNetworkContext, 1);
ctx->operator_id = g_strdup (operator_id);
/* 3GPP-only modems... */
if (mm_iface_modem_is_3gpp_only (MM_IFACE_MODEM (self))) {
ctx->max_try_time = 60;
ctx->remaining_tries_cdma = 0;
ctx->remaining_tries_3gpp = 1;
}
/* CDMA-only modems... */
else if (mm_iface_modem_is_cdma_only (MM_IFACE_MODEM (self))) {
ctx->max_try_time = 60;
ctx->remaining_tries_cdma = 1;
ctx->remaining_tries_3gpp = 0;
}
/* Mixed 3GPP+CDMA modems... */
else {
ctx->max_try_time = 10;
ctx->remaining_tries_cdma = 6;
ctx->remaining_tries_3gpp = 6;
}
From: Amol Lad
Sent: Monday, 16 January 2023 10:30 AM
To: ModemManager (development)
Subject: mmcli "--timeout=[SECONDS]" does not work with --simple-connect
Hi Aleksander,
I've tried with MM 1.20.4 and also 1.18.8 but it seems the timeout is always
"60 seconds" even if a larger --timeout is provided to mmcli --simple-connect
Any suggestion will really help. I landed into this issue because here a
network on roaming is taking around 90 seconds to register and I found mmcli
--simple-connect is returning after 60 seconds wait even though I've provided
--timeout=175
# time mmcli -m 0 --timeout=175 --simple-connect="apn=vi" -v
[16 Jan 2023, 04:15:43] [Debug] Forcing request to be run asynchronously
[16 Jan 2023, 04:15:43] [Debug] Assuming '0' is the modem index
[16 Jan 2023, 04:15:43] [Debug] ModemManager process found at ':1.1765'
[16 Jan 2023, 04:15:43] [Debug] Modem found at
'/org/freedesktop/ModemManager1/Modem/0'
[16 Jan 2023, 04:15:43] [Debug] Asynchronously connecting the modem...
error: couldn't connect the modem:
'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.NetworkTimeout:
Network timeout'
Command exited with non-zero status 1
real1m 0.82s
user0m 0.01s
sys 0m 0.00s
Thanks
Amol
mmcli "--timeout=[SECONDS]" does not work with --simple-connect
Hi Aleksander, I've tried with MM 1.20.4 and also 1.18.8 but it seems the timeout is always "60 seconds" even if a larger --timeout is provided to mmcli --simple-connect Any suggestion will really help. I landed into this issue because here a network on roaming is taking around 90 seconds to register and I found mmcli --simple-connect is returning after 60 seconds wait even though I've provided --timeout=175 # time mmcli -m 0 --timeout=175 --simple-connect="apn=vi" -v [16 Jan 2023, 04:15:43] [Debug] Forcing request to be run asynchronously [16 Jan 2023, 04:15:43] [Debug] Assuming '0' is the modem index [16 Jan 2023, 04:15:43] [Debug] ModemManager process found at ':1.1765' [16 Jan 2023, 04:15:43] [Debug] Modem found at '/org/freedesktop/ModemManager1/Modem/0' [16 Jan 2023, 04:15:43] [Debug] Asynchronously connecting the modem... error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.NetworkTimeout: Network timeout' Command exited with non-zero status 1 real1m 0.82s user0m 0.01s sys 0m 0.00s Thanks Amol
Telit FN990: MM 1.20.4: mmcli --location-enable-gps-nmea reporting error
Hi, I get the following error when enabling NMEA in FN990 with MM 1.20.4 (It comes with 1.18.6 as well). I do not recall seeing this with Telit LN920 so looks like this is something FN990 specific. Please advise. (I'm using MBIM) # mmcli -m "$modem" --location-enable-gps-nmea error: couldn't setup location gathering: 'GDBus.Error:org.freedesktop.libqmi.Error.Protocol.GeneralError: Couldn't enable location 'gps-nmea' gathering: Couldn't start GPS engine: QMI protocol error (46): 'GeneralError'' # mmcli -m 0 --- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: d04794b2e195986e2087001f45f6a4b81d1e3f16 --- Hardware | manufacturer: Telit Wireless Solutions | model: FN990 | carrier config: default | h/w revision: FN990A40 | supported: gsm-umts, lte, 5gnr |current: gsm-umts, lte, 5gnr | equipment id: 35917239176 --- System| device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb3/3-1 |drivers: option1, cdc_mbim | plugin: telit | primary port: cdc-wdm0 | ports: cdc-wdm0 (mbim), ttyUSB0 (ignored), ttyUSB1 (gps), | ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 (ignored), wwan0 (net) --- Numbers |own: 918660286965 --- Status| lock: sim-pin2 | unlock retries: sim-pin2 (3) | state: connected |power state: on |access tech: lte, 5gnr | signal quality: 24% (recent) --- Modes | supported: allowed: 3g; preferred: none | allowed: 4g; preferred: none | allowed: 3g, 4g; preferred: none |current: allowed: any; preferred: none --- Bands | supported: utran-1, utran-4, utran-6, utran-5, utran-8, utran-2, | eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, eutran-8, | eutran-12, eutran-13, eutran-14, eutran-17, eutran-18, eutran-19, | eutran-20, eutran-25, eutran-26, eutran-28, eutran-29, eutran-30, | eutran-32, eutran-34, eutran-38, eutran-39, eutran-40, eutran-41, | eutran-42, eutran-43, eutran-46, eutran-48, eutran-66, eutran-71, | utran-19, ngran-1, ngran-2, ngran-3, ngran-5, ngran-7, ngran-8, | ngran-20, ngran-25, ngran-28, ngran-30, ngran-38, ngran-40, ngran-41, | ngran-48, ngran-66, ngran-71, ngran-75, ngran-77, ngran-78, ngran-79 |current: utran-1, utran-4, utran-6, utran-5, utran-8, utran-2, | eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, eutran-8, | eutran-12, eutran-13, eutran-14, eutran-17, eutran-18, eutran-19, | eutran-20, eutran-25, eutran-26, eutran-28, eutran-29, eutran-30, | eutran-32, eutran-34, eutran-38, eutran-39, eutran-40, eutran-41, | eutran-42, eutran-43, eutran-46, eutran-48, eutran-66, eutran-71, | utran-19, ngran-1, ngran-2, ngran-3, ngran-5, ngran-7, ngran-8, | ngran-20, ngran-25, ngran-28, ngran-30, ngran-38, ngran-40, ngran-41, | ngran-48, ngran-66, ngran-71, ngran-75, ngran-77, ngran-78, ngran-79 --- IP| supported: ipv4, ipv6, ipv4v6 --- 3GPP | imei: 35917239176 | enabled locks: fixed-dialing |operator id: 405861 | operator name: Jio | registration: home | packet service state: attached --- 3GPP EPS | ue mode of operation: csps-2 | initial bearer apn: jionet | initial bearer ip type: ipv4v6 --- 3GPP 5GNR | mico mode: unsupported | drx cycle: unsupported
RE: Telit FN990: All supported/current modes not reported (MM 1.20.2)
Thanks Daniele, I'll test the changes in first week of Jan when I'm back from holidays. Have a good break! -Original Message- From: ModemManager-devel On Behalf Of Daniele Palmas Sent: Wednesday, 28 December 2022 8:55 PM To: Aleksander Morgado Cc: ModemManager (development) ; Amol Lad Subject: Re: Telit FN990: All supported/current modes not reported (MM 1.20.2) Amol, Il giorno lun 28 nov 2022 alle ore 13:22 Aleksander Morgado ha scritto: > > > > Attaching full log and relevant portion seems below. No it's not > > > regression. I just loaded 1.20.2 mainly for 5g support. > > > > > > > I've got a bunch of changes fixing this and adding modes retrieval > > through QMI (which makes more sense than using AT commands when > > available), just need to find the time to polish and submit... > > > > Great! thanks for letting us know > I've pushed a few commits for FN990 support at https://gitlab.freedesktop.org/dnlplm/ModemManager/-/tree/dp/fn990 based on today's main. The qmi fallback is still not implemented, but they should solve the modes issue. The commits had very limited testing, so I haven't yet sent a MR: I'll try to finalize once I come back from holidays, but still wanted to share them with you. Regards, Daniele
Telit FN990: All supported/current modes not reported (MM 1.20.2)
Hi Daniele, I'm trying Telit FN990 with MM 1.20.2 release and "supported" and "current" modes always report "4g" in MBIM mode. I believe it's reported correctly in QMI. It seems not all +WS46 combinations are supported in MBIM. Modes | supported: allowed: 4g; preferred: none |current: allowed: 4g; preferred: none Any suggestions? Thanks Amol root@AprisaLTE:/opt/conf# mmcli -m 0 --- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: 7b4287e8b63ca38658b141592a754cc901670808 --- Hardware | manufacturer: Telit Wireless Solutions | model: FN990 | carrier config: default | h/w revision: FN990A40 | supported: gsm-umts, lte, 5gnr |current: gsm-umts, lte, 5gnr | equipment id: 35917239192 --- System| device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb3/3-1 |drivers: option1, cdc_mbim | plugin: telit | primary port: cdc-wdm0 | ports: cdc-wdm0 (mbim), ttyUSB0 (ignored), ttyUSB1 (ignored), | ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 (ignored), wwan0 (net) --- Status| lock: sim-pin2 | unlock retries: sim-pin2 (3) | state: connected |power state: on |access tech: lte, 5gnr | signal quality: 48% (recent) --- Modes | supported: allowed: 4g; preferred: none |current: allowed: 4g; preferred: none --- Bands | supported: utran-1, utran-4, utran-6, utran-5, utran-8, utran-2, | eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, eutran-8, | eutran-12, eutran-13, eutran-14, eutran-17, eutran-18, eutran-19, | eutran-20, eutran-25, eutran-26, eutran-28, eutran-29, eutran-30, | eutran-32, eutran-34, eutran-38, eutran-39, eutran-40, eutran-41, | eutran-42, eutran-43, eutran-46, eutran-48, eutran-66, eutran-71, | utran-19, ngran-1, ngran-2, ngran-3, ngran-5, ngran-7, ngran-8, | ngran-20, ngran-25, ngran-28, ngran-30, ngran-38, ngran-40, ngran-41, | ngran-48, ngran-66, ngran-71, ngran-75, ngran-77, ngran-78, ngran-79 |current: eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, | eutran-8, eutran-12, eutran-13, eutran-14, eutran-18, eutran-19, | eutran-20, eutran-25, eutran-26, eutran-28, eutran-29, eutran-30, | eutran-32, eutran-34, eutran-38, eutran-39, eutran-40, eutran-41, | eutran-42, eutran-43, eutran-46, eutran-48, eutran-66, eutran-71, | ngran-1, ngran-2, ngran-3, ngran-5, ngran-7, ngran-8, ngran-20, | ngran-25, ngran-28, ngran-30, ngran-38, ngran-40, ngran-41, ngran-48, | ngran-66, ngran-71, ngran-75, ngran-77, ngran-78, ngran-79 --- IP| supported: ipv4, ipv6, ipv4v6 --- 3GPP | imei: 35917239192 | enabled locks: fixed-dialing |operator id: 53001 | operator name: vodafone NZ | registration: home | packet service state: attached |pco: 0: (partial) '27048000' --- 3GPP EPS | ue mode of operation: csps-2 |initial bearer path: /org/freedesktop/ModemManager1/Bearer/0 | initial bearer apn: internet | initial bearer ip type: ipv4 --- 3GPP 5GNR | mico mode: unsupported | drx cycle: unsupported --- SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 | sim slot paths: slot 1: /org/freedesktop/ModemManager1/SIM/0 (active) | slot 2: none ---
Telit FN990 Support in ModemManager
Hi Daniele, Can we use latest MM 1.18.10 release to test Telit FN990 (USB 3.1 host interface) or we should use git main? Is this chip now fully supported in MM? Thanks Amol
RE: Linux system cannot use the data connection
Also, one thing I noticed in mmcli-all-log.info. It might not be related to your problem though. MTU from the carrier is 1360 but wwan0 MTU is set to 1500. It must be set to the MTU received from the carrier. -Original Message- From: Amol Lad Sent: Friday, 15 July 2022 6:39 PM To: Filip Kubicz Cc: modemmanager-devel@lists.freedesktop.org; Kamil Sroka Subject: RE: Linux system cannot use the data connection Please try below (skip dns resolution) wget http://193.63.62.31/sites/default/files/publications/civic_renewal_forms.zip From: Filip Kubicz Sent: Friday, 15 July 2022 6:29 PM To: Amol Lad Cc: modemmanager-devel@lists.freedesktop.org; Kamil Sroka Subject: Re: Linux system cannot use the data connection Hi Amol, # wget http://speedtest.ftp.otenet.gr/files/test10Mb.db --1970-01-04 01:06:40-- http://speedtest.ftp.otenet.gr/files/test10Mb.db Resolving speedtest.ftp.otenet.gr... failed: Temporary failure in name resolution. wget: unable to resolve host address 'speedtest.ftp.otenet.gr<http://speedtest.ftp.otenet.gr>' Filip On Fri, Jul 15, 2022 at 2:52 PM Amol Lad mailto:amol@4rf.com>> wrote: Please also try downloading a test file as below and see the result. Does it download any file at all? wget http://speedtest.ftp.otenet.gr/files/test10Mb.db From: Filip Kubicz mailto:filip.kub...@tier.app>> Sent: Friday, 15 July 2022 5:28 PM To: Amol Lad mailto:amol@4rf.com>> Cc: modemmanager-devel@lists.freedesktop.org<mailto:modemmanager-devel@lists.freedesktop.org>; Kamil Sroka mailto:kamil.sr...@tier.app>> Subject: Re: Linux system cannot use the data connection Hi Amol, thanks for the answer. I checked that the devices are not hitting the SIM data limit. Moreover, as I mentioned there is some small RX/TX occurring for the device from the operator point of view, but the "ping 8.8.8.8 -I wwan0" does not work. Filip On Fri, Jul 15, 2022 at 1:28 PM Amol Lad mailto:amol@4rf.com>> wrote: I generally run into similar situation when my SIM card runs out of money. Do you want to try topping-up SIM card and see if ping is successful? Amol From: ModemManager-devel mailto:modemmanager-devel-boun...@lists.freedesktop.org>> On Behalf Of Filip Kubicz Sent: Friday, 15 July 2022 4:14 PM To: modemmanager-devel@lists.freedesktop.org<mailto:modemmanager-devel@lists.freedesktop.org> Cc: Kamil Sroka mailto:kamil.sr...@tier.app>> Subject: Linux system cannot use the data connection Hi! I'm using ModemManager 1.18.6 with Quectel EG21-G modem and Twilio SuperSIM. This setup works ok on multiple devices. However, on a few devices, I see following situation: • Modem registered to operator network (e.g. Vodafone UK) • Modem reports connected state • wwan0 interface has IPv4 address • Network provider sees no issues • in Network provider console you can see the device exchanges a few hundred kB of data every hour • but ping doesn’t work • sending data fails This looks strange, as if ModemManager was not aware of the data session that is setup, or Linux system not being able to use it. The simplified flow of using the modem: - enable modem - wait until it auto-registers - create a bearer and connect - when bearer obtains IP address, configure the network interface I attached relevant mmcli information from the device (modem, bearer) and debug level logs from 2 situations: - device stable in connected state (but ping fails) - modem reset - sequence of enable, register, connect -> goes into the same state where ping does not work. I also attached the commands that are used for setting up the network interface when a new IP address is obtained. What should I check, or do you know how to avoid this situation? Kind regards, Filip The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).
RE: Linux system cannot use the data connection
Please also try downloading a test file as below and see the result. Does it download any file at all? wget http://speedtest.ftp.otenet.gr/files/test10Mb.db From: Filip Kubicz Sent: Friday, 15 July 2022 5:28 PM To: Amol Lad Cc: modemmanager-devel@lists.freedesktop.org; Kamil Sroka Subject: Re: Linux system cannot use the data connection Hi Amol, thanks for the answer. I checked that the devices are not hitting the SIM data limit. Moreover, as I mentioned there is some small RX/TX occurring for the device from the operator point of view, but the "ping 8.8.8.8 -I wwan0" does not work. Filip On Fri, Jul 15, 2022 at 1:28 PM Amol Lad mailto:amol@4rf.com>> wrote: I generally run into similar situation when my SIM card runs out of money. Do you want to try topping-up SIM card and see if ping is successful? Amol From: ModemManager-devel mailto:modemmanager-devel-boun...@lists.freedesktop.org>> On Behalf Of Filip Kubicz Sent: Friday, 15 July 2022 4:14 PM To: modemmanager-devel@lists.freedesktop.org<mailto:modemmanager-devel@lists.freedesktop.org> Cc: Kamil Sroka mailto:kamil.sr...@tier.app>> Subject: Linux system cannot use the data connection Hi! I'm using ModemManager 1.18.6 with Quectel EG21-G modem and Twilio SuperSIM. This setup works ok on multiple devices. However, on a few devices, I see following situation: ⢠Modem registered to operator network (e.g. Vodafone UK) ⢠Modem reports connected state ⢠wwan0 interface has IPv4 address ⢠Network provider sees no issues ⢠in Network provider console you can see the device exchanges a few hundred kB of data every hour ⢠but ping doesnât work ⢠sending data fails This looks strange, as if ModemManager was not aware of the data session that is setup, or Linux system not being able to use it. The simplified flow of using the modem: - enable modem - wait until it auto-registers - create a bearer and connect - when bearer obtains IP address, configure the network interface I attached relevant mmcli information from the device (modem, bearer) and debug level logs from 2 situations: - device stable in connected state (but ping fails) - modem reset - sequence of enable, register, connect -> goes into the same state where ping does not work. I also attached the commands that are used for setting up the network interface when a new IP address is obtained. What should I check, or do you know how to avoid this situation? Kind regards, Filip The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).
RE: Linux system cannot use the data connection
Please try below (skip dns resolution) wget http://193.63.62.31/sites/default/files/publications/civic_renewal_forms.zip From: Filip Kubicz Sent: Friday, 15 July 2022 6:29 PM To: Amol Lad Cc: modemmanager-devel@lists.freedesktop.org; Kamil Sroka Subject: Re: Linux system cannot use the data connection Hi Amol, # wget http://speedtest.ftp.otenet.gr/files/test10Mb.db --1970-01-04 01:06:40-- http://speedtest.ftp.otenet.gr/files/test10Mb.db Resolving speedtest.ftp.otenet.gr... failed: Temporary failure in name resolution. wget: unable to resolve host address 'speedtest.ftp.otenet.gr<http://speedtest.ftp.otenet.gr>' Filip On Fri, Jul 15, 2022 at 2:52 PM Amol Lad mailto:amol@4rf.com>> wrote: Please also try downloading a test file as below and see the result. Does it download any file at all? wget http://speedtest.ftp.otenet.gr/files/test10Mb.db From: Filip Kubicz mailto:filip.kub...@tier.app>> Sent: Friday, 15 July 2022 5:28 PM To: Amol Lad mailto:amol@4rf.com>> Cc: modemmanager-devel@lists.freedesktop.org<mailto:modemmanager-devel@lists.freedesktop.org>; Kamil Sroka mailto:kamil.sr...@tier.app>> Subject: Re: Linux system cannot use the data connection Hi Amol, thanks for the answer. I checked that the devices are not hitting the SIM data limit. Moreover, as I mentioned there is some small RX/TX occurring for the device from the operator point of view, but the "ping 8.8.8.8 -I wwan0" does not work. Filip On Fri, Jul 15, 2022 at 1:28 PM Amol Lad mailto:amol@4rf.com>> wrote: I generally run into similar situation when my SIM card runs out of money. Do you want to try topping-up SIM card and see if ping is successful? Amol From: ModemManager-devel mailto:modemmanager-devel-boun...@lists.freedesktop.org>> On Behalf Of Filip Kubicz Sent: Friday, 15 July 2022 4:14 PM To: modemmanager-devel@lists.freedesktop.org<mailto:modemmanager-devel@lists.freedesktop.org> Cc: Kamil Sroka mailto:kamil.sr...@tier.app>> Subject: Linux system cannot use the data connection Hi! I'm using ModemManager 1.18.6 with Quectel EG21-G modem and Twilio SuperSIM. This setup works ok on multiple devices. However, on a few devices, I see following situation: ⢠Modem registered to operator network (e.g. Vodafone UK) ⢠Modem reports connected state ⢠wwan0 interface has IPv4 address ⢠Network provider sees no issues ⢠in Network provider console you can see the device exchanges a few hundred kB of data every hour ⢠but ping doesnât work ⢠sending data fails This looks strange, as if ModemManager was not aware of the data session that is setup, or Linux system not being able to use it. The simplified flow of using the modem: - enable modem - wait until it auto-registers - create a bearer and connect - when bearer obtains IP address, configure the network interface I attached relevant mmcli information from the device (modem, bearer) and debug level logs from 2 situations: - device stable in connected state (but ping fails) - modem reset - sequence of enable, register, connect -> goes into the same state where ping does not work. I also attached the commands that are used for setting up the network interface when a new IP address is obtained. What should I check, or do you know how to avoid this situation? Kind regards, Filip The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).
RE: Linux system cannot use the data connection
I generally run into similar situation when my SIM card runs out of money. Do you want to try topping-up SIM card and see if ping is successful? Amol From: ModemManager-devel On Behalf Of Filip Kubicz Sent: Friday, 15 July 2022 4:14 PM To: modemmanager-devel@lists.freedesktop.org Cc: Kamil Sroka Subject: Linux system cannot use the data connection Hi! I'm using ModemManager 1.18.6 with Quectel EG21-G modem and Twilio SuperSIM. This setup works ok on multiple devices. However, on a few devices, I see following situation: · Modem registered to operator network (e.g. Vodafone UK) · Modem reports connected state · wwan0 interface has IPv4 address · Network provider sees no issues · in Network provider console you can see the device exchanges a few hundred kB of data every hour · but ping doesnât work · sending data fails This looks strange, as if ModemManager was not aware of the data session that is setup, or Linux system not being able to use it. The simplified flow of using the modem: - enable modem - wait until it auto-registers - create a bearer and connect - when bearer obtains IP address, configure the network interface I attached relevant mmcli information from the device (modem, bearer) and debug level logs from 2 situations: - device stable in connected state (but ping fails) - modem reset - sequence of enable, register, connect -> goes into the same state where ping does not work. I also attached the commands that are used for setting up the network interface when a new IP address is obtained. What should I check, or do you know how to avoid this situation? Kind regards, Filip
mmcli --simple-connect script issue when username/password contains special characters
Hi, Well, this sounds trivial but I'm having problem in using mmcli -simple-connect in a shell script when username or password contains "space" or double-quote --- #!/bin/sh apn="internet" username="abc 123" password="abc\" 456" cliauth="pap" iptype=IPv4 mmcli -m 0 --simple-connect="apn=$apn,ip-type=$iptype,allowed-auth=$cliauth,user=\"$username\",password=\"$password\"" --- I get below error when running the script: Error parsing connect string: 'Unexpected content (456") after value' I've tried many combinations but no success. Any suggestion will be helpful. (I've using MM 1.18.8) Thanks Amol
RE: APN Authentication: allowed-auth=pap|chap
Hi Aleksander, Please advise regarding this. From the logs I can see that if "allowed-auth=pap|chap" then CHAP is tried first. But if that fails then who will try PAP? Is this modemmanager's responsibility or modem shall do it internally? Basically, I'm finding that if APN supports "PAP Only" authentication then "allowed-auth=pap|chap" does not connect and returns error. It works fine if "allowed-auth=pap" (I'm trying with MM 1.18.8 & EM7565 in MBIM mode) Thanks Amol From: Amol Lad Sent: Wednesday, 29 June 2022 11:19 AM To: ModemManager (development) Subject: APN Authentication: allowed-auth=pap|chap Hi, An APN support "PAP" authentication with a username and password. In mmcli -simple-connect, we can specify "allowed-auth", key/value pair. I'm finding that if "allowed-auth=pap" then APN connects OK but if "allowed-auth=pap|chap", following error is returned: info 2022-06-29T03:51:34+00:00 : [modem0] state changed (registered -> connecting) warning 2022-06-29T03:51:36+00:00 : [modem0/bearer1] connection attempt #1 failed: InvalidUserNamePwd Please advise if "allowed-auth=pap|chap" is supposed to work or passing multiple authentication type has some other significance? I am under the impression that if APN supports PAP then allowed-auth=pap|chap should also work Amol
APN Authentication: allowed-auth=pap|chap
Hi, An APN support "PAP" authentication with a username and password. In mmcli -simple-connect, we can specify "allowed-auth", key/value pair. I'm finding that if "allowed-auth=pap" then APN connects OK but if "allowed-auth=pap|chap", following error is returned: info 2022-06-29T03:51:34+00:00 : [modem0] state changed (registered -> connecting) warning 2022-06-29T03:51:36+00:00 : [modem0/bearer1] connection attempt #1 failed: InvalidUserNamePwd Please advise if "allowed-auth=pap|chap" is supposed to work or passing multiple authentication type has some other significance? I am under the impression that if APN supports PAP then allowed-auth=pap|chap should also work Amol
5G Bands Configuration for Sierra EM919x modem
Hi, I recall there was some discussion about this here sometime back. Is there a way to see & configure NR5G bands in Sierra EM919x modems? We do not see these bands in below output. (I'm using MM 1.18.8) Thanks # mmcli -m 0 -- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: 6784036630561855589b4930599ad9d0c56444b5 -- Hardware | manufacturer: Sierra Wireless, Incorporated | model: Sierra Wireless EM9190 | firmware revision: 03.09.06.00_GENERIC | carrier config: default | h/w revision: EM9190 | supported: gsm-umts, lte, 5gnr |current: gsm-umts, lte, 5gnr | equipment id: 351735110127483 -- System | device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb3/3-1 |drivers: cdc_mbim, qcserial | plugin: sierra | primary port: cdc-wdm0 | ports: cdc-wdm0 (mbim), ttyUSB0 (at), ttyUSB1 (qcdm), wwan0 (net) -- Numbers |own: 9108813566 -- Status | unlock retries: sim-pin2 (1) | state: connected |power state: on |access tech: lte | signal quality: 41% (recent) -- Modes| supported: allowed: 3g; preferred: none | allowed: 4g; preferred: none | allowed: 3g, 4g; preferred: 4g | allowed: 3g, 4g; preferred: 3g | allowed: 5g; preferred: none | allowed: 4g, 5g; preferred: 5g | allowed: 4g, 5g; preferred: 4g | allowed: 3g, 5g; preferred: 5g | allowed: 3g, 5g; preferred: 3g | allowed: 3g, 4g, 5g; preferred: 5g | allowed: 3g, 4g, 5g; preferred: 4g | allowed: 3g, 4g, 5g; preferred: 3g |current: allowed: 4g, 5g; preferred: 5g -- Bands| supported: utran-1, utran-3, utran-4, utran-6, utran-5, utran-8, | utran-9, utran-2, eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, | eutran-7, eutran-8, eutran-12, eutran-13, eutran-14, eutran-17, | eutran-18, eutran-19, eutran-20, eutran-25, eutran-26, eutran-28, | eutran-29, eutran-30, eutran-32, eutran-34, eutran-38, eutran-39, | eutran-40, eutran-41, eutran-42, eutran-46, eutran-48, eutran-66, | eutran-71, utran-19 |current: eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, | eutran-8, eutran-12, eutran-13, eutran-14, eutran-17, eutran-18, | eutran-19, eutran-20, eutran-25, eutran-26, eutran-28, eutran-29, | eutran-30, eutran-32, eutran-34, eutran-38, eutran-39, eutran-40, | eutran-41, eutran-42, eutran-46, eutran-48, eutran-66, eutran-71 -- IP | supported: ipv4, ipv6, ipv4v6 -- 3GPP | imei: 351735110127483 | enabled locks: fixed-dialing |operator id: 40445 | operator name: airtel | registration: home -- 3GPP EPS | ue mode of operation: csps-2 |initial bearer path: /org/freedesktop/ModemManager1/Bearer/0 | initial bearer apn: internet | initial bearer ip type: ipv4v6 -- SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 -- Bearer | paths: /org/freedesktop/ModemManager1/Bearer/1 # mmcli -m 0 --command=AT!BAND? 0 - GW: 1 - LTE: A3E2BB0F38DF 0042 3 - NRNSA: 01000817 7042 4 - NRSA: 01000817 7042'
RE: Sent SMS not getting deleted from Modem
Hi Aleksander,
I'm trying to investigate this issue. My observation is "mm_sms_part_get_index
((MMSmsPart *)ctx->current->data)" returns SMS_PART_INVALID_INDEX in the
function delete_next_part () in the file mm-sms-mbim.c. As a result
delete_next_part() returns from inside if (!ctx->current) check.
However, when I restart modemmanager and all the "deleted" SMS are listed again
and then if I try to delete them then mm_sms_part_get_index() returns a valid
index in delete_next_part and finaly mbim_device_command is called.
So the problem seems mm_sms_part_get_index ((MMSmsPart *)ctx->current->data)
not returning correct idx during delete. Any suggestion how to proceed from
here?
Amol
===
mm-sms-mbim.c:
static void
delete_next_part (GTask *task)
{
SmsDeletePartsContext *ctx;
MbimMessage *message;
MMSmsMbim *self;
self = g_task_get_source_object (task);
ctx = g_task_get_task_data (task);
/* Skip non-stored parts */
while (ctx->current &&
mm_sms_part_get_index ((MMSmsPart *)ctx->current->data) ==
SMS_PART_INVALID_INDEX) < - - This returns SMS_PART_INVALID_INDEX
ctx->current = g_list_next (ctx->current);
/* If all removed, we're done */
if (!ctx->current) {
mm_obj_err(self, "Inside NULL... %d", ctx->n_failed);
if (ctx->n_failed > 0)
g_task_return_new_error (task,
MM_CORE_ERROR,
MM_CORE_ERROR_FAILED,
"Couldn't delete %u parts from this SMS",
ctx->n_failed);
else
g_task_return_boolean (task, TRUE);
g_object_unref (task); < - - Function returns from here
return;
}
message = mbim_message_sms_delete_set_new (MBIM_SMS_FLAG_INDEX,
(guint32)mm_sms_part_get_index
((MMSmsPart *)ctx->current->data),
NULL);
mbim_device_command (ctx->device,
message,
10,
NULL,
(GAsyncReadyCallback)sms_delete_set_ready,
task);
mbim_message_unref (message);
}
-Original Message-
From: Aleksander Morgado
Sent: Wednesday, 4 May 2022 1:16 PM
To: Amol Lad
Cc: ModemManager (development)
Subject: Re: Sent SMS not getting deleted from Modem
Hey,
On Wed, May 4, 2022 at 9:15 AM Amol Lad wrote:
>
> Hi,
>
> I've observed this issue in MM 1.18.6. If I create and send SMS from
> ModemManager and then delete the message, ModemManager reports message
> successfully deleted but actually no QMI command is sent to the modem to
> delete the message. As a result, if I restart ModemManager, then that
> "deleted" SMS is again listed in ModemManager. If I try to delete it now then
> delete is successful. Sorry for confusing statement :).
>
This deserves a new issue in gitlab, could you open it with the details?
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/new
> Please refer to below steps along with the logs for what I'm trying to
> explain.
>
> Please advise what is going wrong
>
> # mmcli -m 0
> --
> General | path: /org/freedesktop/ModemManager1/Modem/0
>| device id: c6ffa92f0ce17a12c39b4a5e5c8e53f67bac2be2
> --
> Hardware | manufacturer: Sierra Wireless, Incorporated
>| model: Sierra Wireless EM7565 Qualcomm(r)
> Snapdragon(tm) X16 LTE-A
>| firmware revision: SWI9X50C_01.08.04.00
>| carrier config: default
>| h/w revision: EM7565
>| supported: gsm-umts, lte
>|current: gsm-umts, lte
>| equipment id: 353533100762262
> --
> System | device:
> /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1
>|drivers: qcserial, cdc_mbim
>| plugin: sierra
>| primary port: cdc-wdm0
>| ports: cdc-wdm0 (mbim), ttyUSB0 (qcdm), ttyUSB1
> (gps),
>| ttyUSB2 (at), wwan0 (net)
> --
> Status | unlock retries: sim-pin2 (3)
>| state: connected
>|power state: on
>|access tech: lte
>| signal quality: 19% (re
RE: Sent SMS not getting deleted from Modem
I've created the issue. Just a note that I was testing with EM7565 in MBIM mode. Thanks -Original Message- From: Aleksander Morgado Sent: Wednesday, 4 May 2022 1:16 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: Sent SMS not getting deleted from Modem Hey, On Wed, May 4, 2022 at 9:15 AM Amol Lad wrote: > > Hi, > > I've observed this issue in MM 1.18.6. If I create and send SMS from > ModemManager and then delete the message, ModemManager reports message > successfully deleted but actually no QMI command is sent to the modem to > delete the message. As a result, if I restart ModemManager, then that > "deleted" SMS is again listed in ModemManager. If I try to delete it now then > delete is successful. Sorry for confusing statement :). > This deserves a new issue in gitlab, could you open it with the details? https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/new > Please refer to below steps along with the logs for what I'm trying to > explain. > > Please advise what is going wrong > > # mmcli -m 0 > -- > General | path: /org/freedesktop/ModemManager1/Modem/0 >| device id: c6ffa92f0ce17a12c39b4a5e5c8e53f67bac2be2 > -- > Hardware | manufacturer: Sierra Wireless, Incorporated >| model: Sierra Wireless EM7565 Qualcomm(r) > Snapdragon(tm) X16 LTE-A >| firmware revision: SWI9X50C_01.08.04.00 >| carrier config: default >| h/w revision: EM7565 >| supported: gsm-umts, lte >|current: gsm-umts, lte >| equipment id: 353533100762262 > -- > System | device: > /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1 >|drivers: qcserial, cdc_mbim >| plugin: sierra >| primary port: cdc-wdm0 >| ports: cdc-wdm0 (mbim), ttyUSB0 (qcdm), ttyUSB1 > (gps), >| ttyUSB2 (at), wwan0 (net) > -- > Status | unlock retries: sim-pin2 (3) >| state: connected >|power state: on >|access tech: lte >| signal quality: 19% (recent) > -- > Modes| supported: allowed: 3g; preferred: none >| allowed: 4g; preferred: none >| allowed: 3g, 4g; preferred: 4g >| allowed: 3g, 4g; preferred: 3g >|current: allowed: 4g; preferred: none > -- > Bands| supported: utran-1, utran-4, utran-6, utran-5, > utran-8, utran-9, >| utran-2, eutran-1, eutran-2, eutran-3, > eutran-4, eutran-5, eutran-7, >| eutran-8, eutran-9, eutran-12, > eutran-13, eutran-18, eutran-19, >| eutran-20, eutran-26, eutran-28, > eutran-29, eutran-30, eutran-32, >| eutran-41, eutran-42, eutran-43, > eutran-46, eutran-48, eutran-66, >| utran-19 >|current: eutran-1, eutran-2, eutran-3, eutran-4, > eutran-5, eutran-7, >| eutran-8, eutran-9, eutran-12, > eutran-13, eutran-18, eutran-19, >| eutran-20, eutran-26, eutran-28, > eutran-29, eutran-30, eutran-32, >| eutran-41, eutran-42, eutran-43, > eutran-46, eutran-48, eutran-66 > -- > IP | supported: ipv4, ipv6, ipv4v6 > -- > 3GPP | imei: 353533100762262 >| enabled locks: fixed-dialing >|operator id: 40445 >| operator name: airtel >| registration: home > -- > 3GPP EPS | ue mode of operation: csps-2 >|initial bearer path: /org/freedesktop/ModemManager1/Bearer/0 >| initial bearer apn: internet >| initial bearer ip type: ipv4 > -- > SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 >| sim slot pat
Sent SMS not getting deleted from Modem
Hi, I've observed this issue in MM 1.18.6. If I create and send SMS from ModemManager and then delete the message, ModemManager reports message successfully deleted but actually no QMI command is sent to the modem to delete the message. As a result, if I restart ModemManager, then that "deleted" SMS is again listed in ModemManager. If I try to delete it now then delete is successful. Sorry for confusing statement :). Please refer to below steps along with the logs for what I'm trying to explain. Please advise what is going wrong # mmcli -m 0 -- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: c6ffa92f0ce17a12c39b4a5e5c8e53f67bac2be2 -- Hardware | manufacturer: Sierra Wireless, Incorporated | model: Sierra Wireless EM7565 Qualcomm(r) Snapdragon(tm) X16 LTE-A | firmware revision: SWI9X50C_01.08.04.00 | carrier config: default | h/w revision: EM7565 | supported: gsm-umts, lte |current: gsm-umts, lte | equipment id: 353533100762262 -- System | device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1 |drivers: qcserial, cdc_mbim | plugin: sierra | primary port: cdc-wdm0 | ports: cdc-wdm0 (mbim), ttyUSB0 (qcdm), ttyUSB1 (gps), | ttyUSB2 (at), wwan0 (net) -- Status | unlock retries: sim-pin2 (3) | state: connected |power state: on |access tech: lte | signal quality: 19% (recent) -- Modes| supported: allowed: 3g; preferred: none | allowed: 4g; preferred: none | allowed: 3g, 4g; preferred: 4g | allowed: 3g, 4g; preferred: 3g |current: allowed: 4g; preferred: none -- Bands| supported: utran-1, utran-4, utran-6, utran-5, utran-8, utran-9, | utran-2, eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, | eutran-8, eutran-9, eutran-12, eutran-13, eutran-18, eutran-19, | eutran-20, eutran-26, eutran-28, eutran-29, eutran-30, eutran-32, | eutran-41, eutran-42, eutran-43, eutran-46, eutran-48, eutran-66, | utran-19 |current: eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, | eutran-8, eutran-9, eutran-12, eutran-13, eutran-18, eutran-19, | eutran-20, eutran-26, eutran-28, eutran-29, eutran-30, eutran-32, | eutran-41, eutran-42, eutran-43, eutran-46, eutran-48, eutran-66 -- IP | supported: ipv4, ipv6, ipv4v6 -- 3GPP | imei: 353533100762262 | enabled locks: fixed-dialing |operator id: 40445 | operator name: airtel | registration: home -- 3GPP EPS | ue mode of operation: csps-2 |initial bearer path: /org/freedesktop/ModemManager1/Bearer/0 | initial bearer apn: internet | initial bearer ip type: ipv4 -- SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 | sim slot paths: slot 1: /org/freedesktop/ModemManager1/SIM/0 (active) | slot 2: none -- Bearer | paths: /org/freedesktop/ModemManager1/Bearer/1 # mmcli -m 0 --messaging-create-sms="text='Hi',number='+919886559096'" Successfully created new SMS: /org/freedesktop/ModemManager1/SMS/0 # mmcli -s 0 --send successfully sent the SMS debug 2022-05-04T06:39:16+00:00 : [/dev/cdc-wdm0] Sent message... << RAW: << length = 76 << data = 03:00:00:00:4C:00:00:00:2B:00:00:00:01:00:00:00:00:00:00:00:53:3F:BE:EB:14:FE:44:67:9F:90:33:A2:23:E5:6C:3F:03:00:00:00:01:00:00:00:1C:00:00:00:00:00:00:00:08:00:00:00:10:00:00:00:00:01:00:0C:91:19:89:68:55:09:69:00:00:02:C8:34 debug 2022-05-04T06:39:16+00:00 : [/dev/cdc-wdm0] Sent message (translated)... << Header: << length = 76 << type= command (0x0003)
RE: messaging-list-sms issue
Yes, definitely!
-Original Message-
From: Aleksander Morgado
Sent: Thursday, 28 April 2022 1:46 PM
To: Amol Lad
Cc: ModemManager (development)
Subject: Re: messaging-list-sms issue
Hey!
>
> There seems a small issue in "mmcli -m 0 --messaging-list-sms -K" reporting
> (in MM 1.18.6). When the number of SMS is >= 100 then closing square bracket
> for the message index is missing in the output as shown below (see index 100
> and above, closing square bracket is missing). Please advise how this can be
> addressed.
>
Ouch! please open a new Issue in gitlab to track this problem.
The problem is in dump_output_list_keyvalue(), where this logic exists:
if (n > 0) {
key_length += ((strlen (KEY_ARRAY_VALUE_SUFFIX)) + 3);
if (n > 10)
key_length++;
}
That is extremely buggy, whoever wrote that should be punished! :)
Instead of checking for n > 10, it should have done something like:
while ((aux /= 10) > 0)
key_length++;
If you're up to fixing and testing that, please open a MR :)
--
Aleksander
https://aleksander.es
messaging-list-sms issue
Hi, There seems a small issue in "mmcli -m 0 --messaging-list-sms -K" reporting (in MM 1.18.6). When the number of SMS is >= 100 then closing square bracket for the message index is missing in the output as shown below (see index 100 and above, closing square bracket is missing). Please advise how this can be addressed. Thanks Amol root@AprisaLTE:/# mmcli -m 0 --messaging-list-sms -K modem.messaging.sms.length: 189 modem.messaging.sms.value[1] : /org/freedesktop/ModemManager1/SMS/188 modem.messaging.sms.value[2] : /org/freedesktop/ModemManager1/SMS/187 modem.messaging.sms.value[3] : /org/freedesktop/ModemManager1/SMS/186 ... ... modem.messaging.sms.value[8] : /org/freedesktop/ModemManager1/SMS/181 modem.messaging.sms.value[9] : /org/freedesktop/ModemManager1/SMS/180 modem.messaging.sms.value[10] : /org/freedesktop/ModemManager1/SMS/179 modem.messaging.sms.value[11] : /org/freedesktop/ModemManager1/SMS/178 modem.messaging.sms.value[12] : /org/freedesktop/ModemManager1/SMS/177 modem.messaging.sms.value[13] : /org/freedesktop/ModemManager1/SMS/176 modem.messaging.sms.value[14] : /org/freedesktop/ModemManager1/SMS/175 ... ... modem.messaging.sms.value[98] : /org/freedesktop/ModemManager1/SMS/91 modem.messaging.sms.value[99] : /org/freedesktop/ModemManager1/SMS/90 modem.messaging.sms.value[100 : /org/freedesktop/ModemManager1/SMS/89 < - - closing square bracket missing after 100 modem.messaging.sms.value[101 : /org/freedesktop/ModemManager1/SMS/88 modem.messaging.sms.value[102 : /org/freedesktop/ModemManager1/SMS/87 modem.messaging.sms.value[103 : /org/freedesktop/ModemManager1/SMS/86 modem.messaging.sms.value[104 : /org/freedesktop/ModemManager1/SMS/85
SMS ModemManager functionality
Hi, We're have mechanism to send a SMS using ModemManager APIs. I was sending SMS from ModemManager but the receiving end not receiving it. Everything looked good; no error reported. Finally, the issue was the network operator had SMS feature disabled for the SIM card I was using. Thus, no SMS was delivered to the receiver. So is there a way to detect if SMS is enabled or disabled by the network operator? We can then find a way to integrate it in MM so appropriate error can be reported if user tries to send SMS when SMS service is disabled by network operator. Please advise. Thanks Amol
Re: MM 1.18.8 release
Hi Aleksander, I can test it on 21st April as out of town at the moment. ( EM7565, Telit LN920 under openwrt platform) Amol From: ModemManager-devel on behalf of Aleksander Morgado Sent: Friday, April 15, 2022 6:26 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: MM 1.18.8 release Hey Amol As soon as I find some free time. I need to write the NEWS update and do proper testing of the release. If anyone wants to help with that, let me know! On Fri, Apr 15, 2022 at 6:29 AM Amol Lad wrote: > > Hi Aleksander, > > When you are planning to release 1.18.8? > > Thanks > Amol > -- Aleksander https://aleksander.es
MM 1.18.8 release
Hi Aleksander, When you are planning to release 1.18.8? Thanks Amol
RE: mmcli --simple-connect does not wait for timeout in all conditions in QMI [MM 1.18.2]
Hi Aleksander, Thanks for your reply. I don’t think this problem is due to need for delay after band change or explicit wait needed for band change to take into effect. I've applied Daniele's change to use "QMI over MBIM" for bands change on 1.18.2 so MBIM not using AT commands for bands update. Also, the same problem is observed in Sierra EM7565 also so this is not specific to Telit. It seems in QMI, immediate failure is returned in (registered -> connecting) without waiting for timeout info 2021-11-30T05:05:29+00:00 : [modem0] state changed (registered -> connecting) info 2021-11-30T05:05:29+00:00 : [modem0/bearer4] couldn't start network: QMI protocol error (14): 'CallFailed' However, in MBIM the state machine stays in (registered -> connecting) till timeout. As an experiment, in MBIM, I changed band again to a valid band when SM was in (registered->connecting) and it immediately went to connected info 2021-11-30T09:26:46+00:00 : [modem0] state changed (registered -> connecting) < change to a valid band in another shell> info 2021-11-30T09:27:01+00:00 : [modem0] state changed (connecting -> connected) Amol info 2021-11-30T09:27:01+00:00 : [modem0] state changed (connecting -> connected) -Original Message- From: Aleksander Morgado Sent: Tuesday, 30 November 2021 2:24 PM To: Amol Lad ; Daniele Palmas ; Carlo Lobrano Cc: ModemManager (development) Subject: Re: mmcli --simple-connect does not wait for timeout in all conditions in QMI [MM 1.18.2] Hey > > I'm observing that in few cases (MM 1.18.2) that --simple-connect returns > immediately in QMI mode without waiting for the timeout. No such premature > exit is observed in MBIM i.e. MBIM mode works fine. > > It's easily reproducible in my setup. > > 1] Successfully connect bearer first and then run following script > > #!/bin/bash > > mmcli -m 0 --simple-disconnect > mmcli -m 0 --set-current-bands=eutran-71 mmcli -m 0 > --simple-connect="apn=internet" --timeout=10 > > -- > > Here, I've used eutran-71 band to reproduce the issue. My network > provider does not support eutran-71. However, the problem is - if I > use some valid band and it takes a little longer for the device to > "latch" on the new band then -simple-connect immediately returns with > failure :( > > Logs are below when above script is run: > > info 2021-11-30T05:05:27+00:00 : [modem0] state changed > (connected -> disconnecting) info 2021-11-30T05:05:27+00:00 : > [modem0] state changed (disconnecting -> registered) info > 2021-11-30T05:05:27+00:00 : [modem0/bearer3] connection #1 finished: > duration 17s, tx: 48 bytes, rx: 88 bytes info 2021-11-30T05:05:29+00:00 : > [modem0] simple connect started... > info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state > (4/8): wait to get fully enabled info 2021-11-30T05:05:29+00:00 : > [modem0] simple connect state (5/8): register info > 2021-11-30T05:05:29+00:00 : [modem0] simple connect state > (6/8): bearer info 2021-11-30T05:05:29+00:00 : [modem0] simple > connect state (7/8): connect info 2021-11-30T05:05:29+00:00 : > [modem0] state changed (registered -> connecting) info > 2021-11-30T05:05:29+00:00 : [modem0/bearer4] couldn't start network: > QMI protocol error (14): 'CallFailed' > info 2021-11-30T05:05:29+00:00 : [modem0/bearer4] verbose call > end reason (3,2001): [cm] no-service warning 2021-11-30T05:05:29+00:00 > : [modem0/bearer4] connection attempt #1 failed: Call failed: > cm error: no-service So, you changed bands in between that disconnect and the new connection attempt, but we don't see any log for that operation (that could be normal, not an issue). The thing is, if you changed bands, the modem will go through a network unregistration, then attempt to register again in the new bands. Your connection attempt got in the middle of that process and so MM was able to go on with the start network operation because by the time you launched your attempt the modem was still registered in the network (the change bands operation is not immediately done by the modem). There are a few ways to solve this really. You could wait a bit after changing bands yourself, or we could improve MM so that it explicitly waits for the bands to be changed (and notified to MM via indications) once we have requested to change them. I think the latter should be preferred if possible. If this works for you in MBIM I guess it's because the AT commands to change bands using the Telit shared utils do wait for the band change to take effect before going on. Maybe @Daniele Palmas or @Carlo Lobrano can confirm if this is the case? -- Aleksander https://aleksander.es
mmcli --simple-connect does not wait for timeout in all conditions in QMI [MM 1.18.2]
Hi, I'm observing that in few cases (MM 1.18.2) that --simple-connect returns immediately in QMI mode without waiting for the timeout. No such premature exit is observed in MBIM i.e. MBIM mode works fine. It's easily reproducible in my setup. 1] Successfully connect bearer first and then run following script #!/bin/bash mmcli -m 0 --simple-disconnect mmcli -m 0 --set-current-bands=eutran-71 mmcli -m 0 --simple-connect="apn=internet" --timeout=10 -- Here, I've used eutran-71 band to reproduce the issue. My network provider does not support eutran-71. However, the problem is - if I use some valid band and it takes a little longer for the device to "latch" on the new band then -simple-connect immediately returns with failure :( Logs are below when above script is run: info 2021-11-30T05:05:27+00:00 : [modem0] state changed (connected -> disconnecting) info 2021-11-30T05:05:27+00:00 : [modem0] state changed (disconnecting -> registered) info 2021-11-30T05:05:27+00:00 : [modem0/bearer3] connection #1 finished: duration 17s, tx: 48 bytes, rx: 88 bytes info 2021-11-30T05:05:29+00:00 : [modem0] simple connect started... info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state (4/8): wait to get fully enabled info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state (5/8): register info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state (6/8): bearer info 2021-11-30T05:05:29+00:00 : [modem0] simple connect state (7/8): connect info 2021-11-30T05:05:29+00:00 : [modem0] state changed (registered -> connecting) info 2021-11-30T05:05:29+00:00 : [modem0/bearer4] couldn't start network: QMI protocol error (14): 'CallFailed' info 2021-11-30T05:05:29+00:00 : [modem0/bearer4] verbose call end reason (3,2001): [cm] no-service warning 2021-11-30T05:05:29+00:00 : [modem0/bearer4] connection attempt #1 failed: Call failed: cm error: no-service info 2021-11-30T05:05:29+00:00 : [modem0] state changed (connecting -> registered) info 2021-11-30T05:05:29+00:00 : [modem0/bearer4] connection #1 finished: duration 0s, tx: 0 bytes, rx: 0 bytes err 2021-11-30T05:05:39+00:00 LTEMGR: ltemon_func.c:986 ltemonUpdateSignalParams: Failed: exitcode = 0 ret = 2 info 2021-11-30T05:05:48+00:00 : [modem0] 3GPP registration state changed (home -> idle) info 2021-11-30T05:05:48+00:00 : [modem0] state changed (registered -> enabled) info 2021-11-30T05:05:48+00:00 : [modem0] 3GPP registration state changed (idle -> unknown) warning 2021-11-30T05:05:48+00:00 : [modem0] couldn't load operator code: Current operator MCC/MNC is still unknown warning 2021-11-30T05:05:48+00:00 : [modem0] couldn't load operator name: Current operator id is still unknown Any idea how this behaviour can be prevented? As I said before, in MBIM this problem is not observed and -simple-connect only exits after timeout (or successfully connects within timeout) Please advise. Amol # mmcli -m 0 -- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: c3e7a33989113dbfd81acfae3c4e31fdc86fcae6 -- Hardware | manufacturer: Telit | model: LN920A12-WW | firmware revision: M0L.00-B013 | carrier config: default | h/w revision: 0.10 | supported: gsm-umts, lte |current: gsm-umts, lte | equipment id: 354175759991310 -- System | device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb3/3-1 |drivers: option1, qmi_wwan | plugin: telit | primary port: cdc-wdm0 | ports: cdc-wdm0 (qmi), ttyUSB0 (ignored), ttyUSB1 (gps), | ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 (ignored), wwan0 (net) -- Numbers |own: 9108813566 -- Status | lock: sim-pin2 | unlock retries: sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10) | state: connected |power state: on |access tech: lte | signal quality: 96% (recent) -- Modes| supported: allowed: 3g; preferred: none | allowed: 4g; preferred: none | allowed: 3g, 4g; preferred: 4g | allowed: 3g, 4g; preferred: 3g |current: allowed: 4g; preferred: none -- Bands| supported: utran-1, utran-3, utran-4, utran-6, utran-5, utran-8,
RE: SIM Card PIN Change Timeout (MM 1.18.2)
The problem is coming in QMI also but logs are a bit different:
root@AprisaLTE:/# mmcli -i 1 --change-pin=1234 --pin=
error: couldn't change PIN code in the SIM: 'Timeout was reached'
Logs are below:
debug 2021-11-08T15:20:38+00:00 : [1636384838.121620] [modem0/sim1]
changing PIN...
debug 2021-11-08T15:20:38+00:00 : [/dev/cdc-wdm0] Sent message...
<< RAW:
<< length = 32
<< data =
01:1F:00:00:0B:02:00:0F:00:28:00:13:00:02:0B:00:01:04:30:30:30:30:04:31:32:33:34:01:02:00:06:00
debug 2021-11-08T15:20:38+00:00 : [/dev/cdc-wdm0] Sent generic request
(translated)...
<< QMUX:
<< length = 31
<< flags = 0x00
<< service = "uim"
<< client = 2
<< QMI:
<< flags = "none"
<< transaction = 15
<< tlv_length = 19
<< message = "Change PIN" (0x0028)
<< TLV:
<< type = "Info" (0x02)
<< length = 11
<< value = 01:04:30:30:30:30:04:31:32:33:34
<< translated = [ pin_id = 'pin1' old_pin = '' new_pin = '1234' ]
<< TLV:
<< type = "Session" (0x01)
<< length = 2
<< value = 06:00
<< translated = [ session_type = 'card-slot-1' application_identifier =
'{}' ]
debug 2021-11-08T15:20:38+00:00 : [/dev/cdc-wdm0] Received message...
<< RAW:
<< length = 93
<< data =
01:5C:00:80:0B:02:02:0F:00:28:00:50:00:02:04:00:00:00:00:00:13:02:00:63:C3:11:41:00:40:35:C7:A6:4F:93:0A:F0:9C:F1:13:65:9B:8C:E1:51:51:38:71:7A:0D:11:DC:04:4F:A0:29:01:07:13:0C:01:3F:19:A8:0E:95:29:0C:15:73:6F:10:9A:72:76:F1:5E:86:5D:77:CF:AC:00:00:00:00:00:00:00:00:00:00:00:00
debug 2021-11-08T15:20:38+00:00 : [/dev/cdc-wdm0] Received generic response
(translated)...
<< QMUX:
<< length = 92
<< flags = 0x80
<< service = "uim"
<< client = 2
<< QMI:
<< flags = "response"
<< transaction = 15
<< tlv_length = 80
<< message = "Change PIN" (0x0028)
<< TLV:
<< type = "Result" (0x02)
<< length = 4
<< value = 00:00:00:00
<< translated = SUCCESS
<< TLV:
<< type = "Card Result" (0x13)
<< length = 2
<< value = 63:C3
<< translated = [ sw1 = '99' sw2 = '195' ]
<< TLV:
<< type = 0x11
<< length = 65
<< value =
40:35:C7:A6:4F:93:0A:F0:9C:F1:13:65:9B:8C:E1:51:51:38:71:7A:0D:11:DC:04:4F:A0:29:01:07:13:0C:01:3F:19:A8:0E:95:29:0C:15:73:6F:10:9A:72:76:F1:5E:86:5D:77:CF:AC:00:00:00:00:00:00:00:00:00:00:00:00
debug 2021-11-08T15:20:38+00:00 : [1636384838.204934] [modem0] loading
unlock required (UIM)...
debug 2021-11-08T15:20:38+00:00 : [/dev/cdc-wdm0] Sent message...
<< RAW:
<< length = 13
<< data = 01:0C:00:00:0B:02:00:10:00:2F:00:00:00
debug 2021-11-08T15:20:38+00:00 : [/dev/cdc-wdm0] Sent generic request
(translated)...
<< QMUX:
<< length = 12
<< flags = 0x00
<< service = "uim"
<< client = 2
<< QMI:
<< flags = "none"
<< transaction = 16
<< tlv_length = 0
<< message = "Get Card Status" (0x002F)
debug 2021-11-08T15:20:38+00:00 : [/dev/cdc-wdm0] Received message...
<< RAW:
<< length = 86
<< data =
01:55:00:80:0B:02:02:10:00:2F:00:49:00:02:04:00:00:00:00:00:16:05:00:01:00:00:00:00:15:02:00:01:00:11:02:00:01:00:10:2D:00:00:00:FF:FF:FF:FF:FF:FF:01:01:00:00:00:00:01:02:04:00:0B:00:00:10:A0:00:00:00:87:10:02:FF:45:FF:01:89:06:03:00:00:00:02:03:0A:01:03:0A
debug 2021-11-08T15:20:38+00:00 : [/dev/cdc-wdm0] Received generic response
(translated)...
<< QMUX:
<< length = 85
<< flags = 0x80
<< service = "uim"
<< client = 2
<< QMI:
<< flags = "response"
<< transaction = 16
<< tlv_length = 73
<< message = "Get Card Status" (0x002F)
<< TLV:
<< type = "Result" (0x02)
<< length = 4
<< value = 00:00:00:00
<< translated = SUCCESS
<< TLV:
<< type = 0x16
<< length = 5
<< value = 01:00:00:00:00
<< TLV:
<< type = 0x15
<< length = 2
<< value = 01:00
<< TLV:
<< type = 0x11
<< length = 2
<< value = 01:00
<< TLV:
<< type = "Card Status" (0x10)
<< length = 45
<< value =
00:00:FF:FF:FF:FF:FF:FF:01:01:00:00:00:00:01:02:04:00:0B:00:00:10:A0:00:00:00:87:10:02:FF:45:FF:01:89:06:03:00:00:00:02:03:0A:01:03:0A
<< translated = [ index_gw_primary = '0' index_1x_primary
debug 2021-11-08T15:20:38+00:00 : [1636384838.237310] [modem0] GW
primary session index: 0
debug 2021-11-08T15:20:38+00:00 : [1636384838.237362] [modem0] GW
primary application index: 0
debug 2021-11-08T15:20:38+00:00 : [1636384838.237416] [modem0] couldn't
check if unlock required: QMI operation failed: Personalization check in
progress
debug 2021-11-08T15:20:38+00:00 : [1636384838.237459] [modem0] retrying
(1) unlock required check
debug
RE: SIM Card PIN Change Timeout (MM 1.18.2)
I've tried to fix it. Below is for review and if OK then I'll submit MR.
I think, we cannot make assumption that modem will be unlocked after sim pin
change. Hence, we should not wait for unlock?
diff --git a/src/mm-base-sim.c b/src/mm-base-sim.c
index 59af3a88..8a181970 100644
--- a/src/mm-base-sim.c
+++ b/src/mm-base-sim.c
@@ -201,20 +201,17 @@ handle_change_pin_ready (MMBaseSim *self,
GAsyncResult *res,
HandleChangePinContext *ctx)
{
-MMModemLock known_lock = MM_MODEM_LOCK_UNKNOWN;
+MM_BASE_SIM_GET_CLASS (self)->change_pin_finish (self, res,
>save_error);
-if (!MM_BASE_SIM_GET_CLASS (self)->change_pin_finish (self, res,
>save_error)) {
-if (g_error_matches (ctx->save_error,
- MM_MOBILE_EQUIPMENT_ERROR,
- MM_MOBILE_EQUIPMENT_ERROR_SIM_PUK))
-known_lock = MM_MODEM_LOCK_SIM_PUK;
+if (ctx->save_error) {
+g_dbus_method_invocation_return_gerror (ctx->invocation,
ctx->save_error);
+reprobe_if_puk_discovered (ctx->self, ctx->save_error);
+g_clear_error (>save_error);
+} else {
+mm_gdbus_sim_complete_change_pin (MM_GDBUS_SIM (ctx->self),
ctx->invocation);
}
-mm_iface_modem_update_lock_info (
-MM_IFACE_MODEM (self->priv->modem),
-known_lock,
-(GAsyncReadyCallback)after_change_update_lock_info_ready,
-ctx);
+handle_change_pin_context_free (ctx);
}
Thanks
Amol
-Original Message-
From: Aleksander Morgado
Sent: Monday, 8 November 2021 5:25 PM
To: Amol Lad
Cc: ModemManager (development)
Subject: Re: SIM Card PIN Change Timeout (MM 1.18.2)
Hey,
On Mon, Nov 8, 2021 at 11:36 AM Amol Lad wrote:
>
> # mmcli -i 1 --change-pin= --pin=1234
> error: couldn't change PIN code in the SIM: 'Timeout was reached'
>
> # mmcli -m 0 --command=AT+CPIN?
> response: '+CPIN: SIM PIN'
>
> So looks like modem is 'really' locked. Btw, which part of debug log showed
> modem went in searching?
>
Oh, interesting. Then I wouldn't know what to say :)
Here's the debug log that lead me to think the modem was unlocked already:
debug 2021-11-06T06:46:28+00:00 : [/dev/cdc-wdm0] Received message...
<<<<<< RAW:
<<<<<< length = 50
<<<<<< data =
01:31:00:80:03:04:04:02:00:24:00:25:00:01:06:00:02:02:02:02:01:08:11:01:00:00:12:05:00:94:01:2D:00:00:22:05:00:01:02:00:00:00:29:05:00:94:01:2D:00:00
debug 2021-11-06T06:46:28+00:00 : [/dev/cdc-wdm0] Received generic indication
(translated)...
<<<<<< QMUX:
<<<<<< length = 49
<<<<<< flags = 0x80
<<<<<< service = "nas"
<<<<<< client = 4
<<<<<< QMI:
<<<<<< flags = "indication"
<<<<<< transaction = 2
<<<<<< tlv_length = 37
<<<<<< message = "Serving System" (0x0024)
<<<<<< TLV:
<<<<<< type = "Serving System" (0x01)
<<<<<< length = 6
<<<<<< value = 02:02:02:02:01:08
<<<<<< translated = [ registration_state =
'not-registered-searching' cs_attach_state = 'detached'
ps_attach_state = 'detached' selected_network = '3gpp'
radio_interfaces = '{ [0] = 'lte '}' ]
<<<<<< TLV:
<<<<<< type = "Data Service Capability" (0x11)
<<<<<< length = 1
<<<<<< value = 00
<<<<<< translated = {}
<<<<<< TLV:
<<<<<< type = "Current PLMN" (0x12)
<<<<<< length = 5
<<<<<< value = 94:01:2D:00:00
<<<<<< translated = [ mcc = '404' mnc = '45' description = '' ]
--
Aleksander
https://aleksander.es
RE: SIM Card PIN Change Timeout (MM 1.18.2)
# mmcli -i 1 --change-pin= --pin=1234 error: couldn't change PIN code in the SIM: 'Timeout was reached' # mmcli -m 0 --command=AT+CPIN? response: '+CPIN: SIM PIN' So looks like modem is 'really' locked. Btw, which part of debug log showed modem went in searching? -Original Message- From: Aleksander Morgado Sent: Monday, 8 November 2021 3:51 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: SIM Card PIN Change Timeout (MM 1.18.2) Hey, > Same problem is observed with Telit LN920 also so I don't this it's a > firmware error. They're both Qualcomm modules, it may be an issue in the generic Qualcomm firmware implementation. I wouldn't think manufacturers touch the MBIM protocol handling much. > Also, please note that modem is still "locked" after changing the SIM-PIN > while locked. Please see below. So it seems changing SIM-PIN when modem is > locked does not unlock the modem but PIN is successfully changed. > > # mmcli -m 0 > - > General | path: /org/freedesktop/ModemManager1/Modem/0 >| device id: a4c570e8767a7f8ff295ad3ddf51293b18b8103a > - > Hardware | manufacturer: Telit Wireless Solutions >| model: LN920 >| firmware revision: SDX12.LE.1.0-00085-NBOOT.NEFS. >|carrier config: default >| h/w revision: LN920A12-WW >| supported: gsm-umts, lte >| current: gsm-umts, lte >| equipment id: 354175759991310 > - > System |device: > /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1 >| drivers: cdc_mbim, option1 >|plugin: telit >| primary port: cdc-wdm0 >| ports: cdc-wdm0 (mbim), ttyUSB0 (ignored), ttyUSB1 > (gps), >|ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 > (ignored), wwan0 (net) > - > Status | lock: sim-pin >|unlock retries: sim-pin (3) >| state: locked I would say that the "locked" report here after you changed the SIM-PIN is wrong. We're still saying "locked" because we failed to process the "Subscriber Ready Status" query correctly (as the modem kept returning "Failure"), but the modem switched to "Searching" state, at least per the MBIM indications in your original debug log. -- Aleksander https://aleksander.es
RE: SIM Card PIN Change Timeout (MM 1.18.2)
rred: none | current: allowed: 4g; preferred: none - Bands| supported: utran-1, utran-3, utran-4, utran-6, utran-5, utran-8, |utran-9, utran-2, eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, |eutran-7, eutran-8, eutran-12, eutran-13, eutran-14, eutran-17, |eutran-18, eutran-19, eutran-20, eutran-25, eutran-26, eutran-28, |eutran-29, eutran-30, eutran-38, eutran-39, eutran-40, eutran-41, |eutran-42, eutran-43, eutran-48, eutran-66, eutran-71, utran-19 | current: eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, |eutran-8, eutran-12, eutran-13, eutran-14, eutran-17, eutran-18, |eutran-19, eutran-20, eutran-25, eutran-26, eutran-28, eutran-29, |eutran-30, eutran-38, eutran-39, eutran-40, eutran-41, eutran-42, |eutran-43, eutran-48, eutran-66, eutran-71 - IP | supported: ipv4, ipv6, ipv4v6 - 3GPP | enabled locks: sim, fixed-dialing - SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/1 |sim slot paths: slot 1: /org/freedesktop/ModemManager1/SIM/0 |slot 2: /org/freedesktop/ModemManager1/SIM/1 (active) -Original Message- From: Aleksander Morgado Sent: Monday, 8 November 2021 3:04 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: SIM Card PIN Change Timeout (MM 1.18.2) Hey, > > > If we attempt to change SIM Card PIN when the SIM is in locked state then > "Timeout is reached" error is reported BUT the PIN is actually changed. Below > are some details. > > > > # mmcli -m 0 > > - > > General | path: /org/freedesktop/ModemManager1/Modem/0 > >| device id: 02c606168e3d349049dd25edafba09756e8ca26d > > - > > Hardware | manufacturer: Sierra Wireless, Incorporated > >| model: Sierra Wireless EM7455 Qualcomm(r) > Snapdragon(tm) X7 LTE-A > >| firmware revision: SWI9X30C_02.24.05.06 > >|carrier config: default > >| h/w revision: EM7455 > >| supported: gsm-umts, lte > >| current: gsm-umts, lte > >| equipment id: 359073061147272 > > - > > System |device: > /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1 > >| drivers: qcserial, cdc_mbim > >|plugin: sierra > >| primary port: cdc-wdm0 > >| ports: cdc-wdm0 (mbim), ttyUSB0 (qcdm), ttyUSB1 > (gps), > >|ttyUSB2 (at), wwan0 (net) > > - > > Status | state: locked > >| power state: on > >|signal quality: 0% (cached) > > - > > Modes| supported: allowed: 3g; preferred: none > >|allowed: 4g; preferred: none > >|allowed: 3g, 4g; preferred: 4g > >|allowed: 3g, 4g; preferred: 3g > >| current: allowed: 4g; preferred: none > > - > > Bands| supported: utran-1, utran-3, utran-4, utran-5, utran-8, > utran-2, > >|eutran-1, eutran-2, eutran-3, eutran-4, > eutran-5, eutran-7, eutran-8, > >|eutran-12, eutran-13, eutran-20, eutran-25, > eutran-26, eutran-29, > >|eutran-30, eutran-41 > >| current: eutran-1, eutran-2, eutran-3, eutran-4, > eutran-5, eutran-7, > >|eutran-8, eutran-12, eutran-13, eutran-20, > eutran-25, eutran-26, > >|eutran-29, eutran-30, eutran-41 > > - > > IP | supported: ipv4, ipv6, ipv4v6 > > - > > 3GPP | enabled locks: sim, fixed-dialing > > - > > SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 > > > > # mmcli -i 0 --change-pin=1234 --pin= > > error: couldn't change PI
RE: Telit LN920: Incorrect Network Time Reported
Hi Daniele, I'm using PID 1061 (MBIM). I did some investigation and found that if I set AT#NITZ=15,1 then times are correctly reported. I'm now not recalling what was #NITZ? before I changed it. Please let me know if this information is sufficient. If not, I'll get debug logs and send across Thanks Amol -Original Message- From: Daniele Palmas Sent: Saturday, 6 November 2021 12:12 AM To: Amol Lad Cc: ModemManager (development) Subject: Re: Telit LN920: Incorrect Network Time Reported Hi Amol, Il giorno ven 5 nov 2021 alle ore 04:12 Amol Lad ha scritto: > > Hi, > > We're not getting network time using mmcli -time command. I'm not sure if it > is something specific to my setup or an issue. However, I do get correct > network time when using Sierra modem with the same SIM card > > (I'm using MM 1.18.2 release) > > Please advise Which PID are you using? Can you please also provide MM debug logs? Regards, Daniele > Amol > > # mmcli -m 0 --time > --- > Time | current: 1980-01-06T05:46:43+05:30 > --- > Timezone | current: 330 >
Telit LN920: Incorrect Network Time Reported
Hi, We're not getting network time using mmcli -time command. I'm not sure if it is something specific to my setup or an issue. However, I do get correct network time when using Sierra modem with the same SIM card (I'm using MM 1.18.2 release) Please advise Amol # mmcli -m 0 --time --- Time | current: 1980-01-06T05:46:43+05:30 --- Timezone | current: 330
RE: LN920: MBIM Bands not shown (MM 1.18.2)
Hi, I've raised a MR: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/646 This fixes #BND=? For LN920. I've tested with LN920 and looks ok. -Original Message- From: Daniele Palmas Sent: Tuesday, 12 October 2021 2:50 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: LN920: MBIM Bands not shown (MM 1.18.2) Il giorno lun 11 ott 2021 alle ore 18:06 Amol Lad ha scritto: > > LIBQMI_WITH_MBIM_QMUX is enabled in libqmi and qmicli reports ok. It seems > for some reasons modemmanager is not able to read out the bands. Any input > regarding this will be helpful. > Currently Telit mbim plugin uses just AT commands for retrieving bands: maybe a possible improvement could be to use the qmi requests when supported by the modem and available in the build. Added on my TODO list... Anyway, it would be better also to fix #BND=? management for those setups where qmi is not used. Regards, Daniele > > > # qmicli -d /dev/cdc-wdm0 -p --dms-get-band-capabilities > > [/dev/cdc-wdm0] Device band capabilities retrieved: > > Bands: 'wcdma-2100, wcdma-pcs-1900, wcdma-dcs-1800, wcdma-1700-us, > wcdma-850-us, wcdma-800, wcdma-900, wcdma-1700-japan, wcdma-850-japan' > > LTE bands: '1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, > 28, 29, 30, 38, 39, 40, 41, 42, 43' > > LTE bands (extended): '1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, > 20, 25, 26, 28, 29, 30, 38, 39, 40, 41, 42, 43, 48, 66, 71' > > > > Thanks > > Amol > > > > From: Amol Lad > Sent: Monday, 11 October 2021 6:34 PM > To: 'Daniele Palmas' ; 'ModemManager (development)' > > Subject: LN920: MBIM Bands not shown (MM 1.18.2) > > > > Hi Daniele, > > > > I’m patched my MM 1.18.2 with your MR (LN920 Initial Support) and testing > LN920 in MBIM mode. I’m noticing that the “supported” and “current” bands are > not shown in “mmcli -m 0” output and below error is seen in the logs: > > > > [modem0] couldn't load supported bands: Could not find 4G band > flags from response > > > > Any suggestion what could be going wrong? > > > > mmcli -m 0 output in both MBIM and QMI is below: > > > > > > MBIM > > > > > > # mmcli -m 0 > > -- > > General | path: /org/freedesktop/ModemManager1/Modem/0 > >| device id: 168c2aa5755860bee3694899a635af0df25e7fcf > > -- > > Hardware | manufacturer: Telit Wireless Solutions > >| model: LN920 > >| firmware revision: SDX12.LE.1.0-00085-NBOOT.NEFS. > >| carrier config: default > >| h/w revision: LN920A12-WW > >| supported: gsm-umts, lte > >|current: gsm-umts, lte > >| equipment id: 354175759991229 > > -- > > System | device: > /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1 > >|drivers: cdc_mbim, option1 > >| plugin: telit > >| primary port: cdc-wdm0 > >| ports: cdc-wdm0 (mbim), ttyUSB0 (ignored), > ttyUSB1 (gps), > >| ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 > (ignored), wwan0 (net) > > -- > > Numbers |own: 9108813566 > > -- > > Status | unlock retries: sim-pin2 (3) > >| state: connected > >|power state: on > >|access tech: lte > >| signal quality: 12% (recent) > > -- > > Modes| supported: allowed: 3g; preferred: none > >| allowed: 4g; preferred: none > >| allowed: 3g, 4g; preferred: none > >|current: allowed: 4g; preferred: none > > -- > > IP | supported: ipv4, ipv6, ipv4v6 > > -- > > 3GPP | imei: 354175759991229 > >| enabled locks: fixed-dialing > >|operator id: 40445 > >| operator name: airtel > >| registration: home > > --
RE: LN920: MBIM Bands not shown (MM 1.18.2)
> Anyway, it would be better also to fix #BND=? management for those > setups where qmi is not used. > I've started on this and shall submit a MR in a day or two..
RE: LN920: MBIM Bands not shown (MM 1.18.2)
LIBQMI_WITH_MBIM_QMUX is enabled in libqmi and qmicli reports ok. It seems for some reasons modemmanager is not able to read out the bands. Any input regarding this will be helpful. # qmicli -d /dev/cdc-wdm0 -p --dms-get-band-capabilities [/dev/cdc-wdm0] Device band capabilities retrieved: Bands: 'wcdma-2100, wcdma-pcs-1900, wcdma-dcs-1800, wcdma-1700-us, wcdma-850-us, wcdma-800, wcdma-900, wcdma-1700-japan, wcdma-850-japan' LTE bands: '1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30, 38, 39, 40, 41, 42, 43' LTE bands (extended): '1, 2, 3, 4, 5, 7, 8, 12, 13, 14, 17, 18, 19, 20, 25, 26, 28, 29, 30, 38, 39, 40, 41, 42, 43, 48, 66, 71' Thanks Amol From: Amol Lad Sent: Monday, 11 October 2021 6:34 PM To: 'Daniele Palmas' ; 'ModemManager (development)' Subject: LN920: MBIM Bands not shown (MM 1.18.2) Hi Daniele, I'm patched my MM 1.18.2 with your MR (LN920 Initial Support) and testing LN920 in MBIM mode. I'm noticing that the "supported" and "current" bands are not shown in "mmcli -m 0" output and below error is seen in the logs: [modem0] couldn't load supported bands: Could not find 4G band flags from response Any suggestion what could be going wrong? mmcli -m 0 output in both MBIM and QMI is below: MBIM # mmcli -m 0 -- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: 168c2aa5755860bee3694899a635af0df25e7fcf -- Hardware | manufacturer: Telit Wireless Solutions | model: LN920 | firmware revision: SDX12.LE.1.0-00085-NBOOT.NEFS. | carrier config: default | h/w revision: LN920A12-WW | supported: gsm-umts, lte |current: gsm-umts, lte | equipment id: 354175759991229 -- System | device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1 |drivers: cdc_mbim, option1 | plugin: telit | primary port: cdc-wdm0 | ports: cdc-wdm0 (mbim), ttyUSB0 (ignored), ttyUSB1 (gps), | ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 (ignored), wwan0 (net) -- Numbers |own: 9108813566 -- Status | unlock retries: sim-pin2 (3) | state: connected |power state: on |access tech: lte | signal quality: 12% (recent) -- Modes| supported: allowed: 3g; preferred: none | allowed: 4g; preferred: none | allowed: 3g, 4g; preferred: none |current: allowed: 4g; preferred: none -- IP | supported: ipv4, ipv6, ipv4v6 -- 3GPP | imei: 354175759991229 | enabled locks: fixed-dialing |operator id: 40445 | operator name: airtel | registration: home -- 3GPP EPS | ue mode of operation: csps-2 |initial bearer path: /org/freedesktop/ModemManager1/Bearer/0 | initial bearer ip type: ipv4v6 -- SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 | sim slot paths: slot 1: /org/freedesktop/ModemManager1/SIM/0 (active) | slot 2: /org/freedesktop/ModemManager1/SIM/1 -- Bearer | paths: /org/freedesktop/ModemManager1/Bearer/1 QMI --- -- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: 5c1922b03727107842603eccdea2bb4cd26436f5 -- Hardware | manufacturer: Telit | model: LN920A12-WW | firmware revision: M0L.00-A006 | carrier config: default | h/w revision: 10001 | supported: gsm-umts, lte |current: gsm-umts, lte | equipment id: 354175759991229 -- System | device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1 |drivers: option1, qmi_wwan | plugin: telit | primary port: cdc-wdm0
LN920: MBIM Bands not shown (MM 1.18.2)
Hi Daniele, I'm patched my MM 1.18.2 with your MR (LN920 Initial Support) and testing LN920 in MBIM mode. I'm noticing that the "supported" and "current" bands are not shown in "mmcli -m 0" output and below error is seen in the logs: [modem0] couldn't load supported bands: Could not find 4G band flags from response Any suggestion what could be going wrong? mmcli -m 0 output in both MBIM and QMI is below: MBIM # mmcli -m 0 -- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: 168c2aa5755860bee3694899a635af0df25e7fcf -- Hardware | manufacturer: Telit Wireless Solutions | model: LN920 | firmware revision: SDX12.LE.1.0-00085-NBOOT.NEFS. | carrier config: default | h/w revision: LN920A12-WW | supported: gsm-umts, lte |current: gsm-umts, lte | equipment id: 354175759991229 -- System | device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1 |drivers: cdc_mbim, option1 | plugin: telit | primary port: cdc-wdm0 | ports: cdc-wdm0 (mbim), ttyUSB0 (ignored), ttyUSB1 (gps), | ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 (ignored), wwan0 (net) -- Numbers |own: 9108813566 -- Status | unlock retries: sim-pin2 (3) | state: connected |power state: on |access tech: lte | signal quality: 12% (recent) -- Modes| supported: allowed: 3g; preferred: none | allowed: 4g; preferred: none | allowed: 3g, 4g; preferred: none |current: allowed: 4g; preferred: none -- IP | supported: ipv4, ipv6, ipv4v6 -- 3GPP | imei: 354175759991229 | enabled locks: fixed-dialing |operator id: 40445 | operator name: airtel | registration: home -- 3GPP EPS | ue mode of operation: csps-2 |initial bearer path: /org/freedesktop/ModemManager1/Bearer/0 | initial bearer ip type: ipv4v6 -- SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 | sim slot paths: slot 1: /org/freedesktop/ModemManager1/SIM/0 (active) | slot 2: /org/freedesktop/ModemManager1/SIM/1 -- Bearer | paths: /org/freedesktop/ModemManager1/Bearer/1 QMI --- -- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: 5c1922b03727107842603eccdea2bb4cd26436f5 -- Hardware | manufacturer: Telit | model: LN920A12-WW | firmware revision: M0L.00-A006 | carrier config: default | h/w revision: 10001 | supported: gsm-umts, lte |current: gsm-umts, lte | equipment id: 354175759991229 -- System | device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1 |drivers: option1, qmi_wwan | plugin: telit | primary port: cdc-wdm0 | ports: cdc-wdm0 (qmi), ttyUSB0 (ignored), ttyUSB1 (gps), | ttyUSB2 (at), ttyUSB3 (at), ttyUSB4 (ignored), wwan0 (net) -- Numbers |own: 9108813566 -- Status | lock: sim-pin2 | unlock retries: sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10) | state: connected |power state: on |access tech: lte | signal quality: 42% (recent) -- Modes| supported: allowed: 3g; preferred: none | allowed: 4g; preferred: none | allowed: 3g, 4g; preferred: 4g |
ModemManager Crash (1.18.2) when ip-type is ipv4v6 (MBIM)
Hi,
I'm finding that ModemManager crashes when ip-type is ipv4v6 in -simple-connect
in MBIM mode. After investigation, I found that below seems to fix the crash
diff --git a/src/mm-bearer-mbim.c b/src/mm-bearer-mbim.c
index d509929..bf66c5d 100644
--- a/src/mm-bearer-mbim.c
+++ b/src/mm-bearer-mbim.c
@@ -406,7 +406,7 @@ ip_configuration_query_ready (MbimDevice *device,
str = g_inet_address_to_string (addr);
mm_obj_dbg (self, "DNS [%u]: '%s'", i, str);
}
-g_object_unref (addr);
+//g_object_unref (addr);
}
}
--
The original code is:
mm-bearer-mbin.c: ip_configuration_query_ready()
if ((ipv6configurationavailable &
MBIM_IP_CONFIGURATION_AVAILABLE_FLAG_DNS) && ipv6dnsservercount) {
guint i;
mm_obj_dbg (self, " DNS addresses (%u)", ipv6dnsservercount);
for (i = 0; i < ipv6dnsservercount; i++) {
g_autoptr(GInetAddress) addr = NULL;
addr = g_inet_address_new_from_bytes ((guint8
*)[i], G_SOCKET_FAMILY_IPV6);
if (!g_inet_address_get_is_any (addr)) {
g_autofree gchar *str = NULL;
str = g_inet_address_to_string (addr);
mm_obj_dbg (self, "DNS [%u]: '%s'", i, str);
}
g_object_unref (addr); <-- This seems to cause crash
}
}
Thanks
RE: MM 1.18.2 Supported Bands and Current Bands are empty
Hi Aleksander, My apologies. It seems my MM got built without QMI_MBIM_QMUX_SUPPORTED flag hence below issues. After re-building MM with this flag, I can see "Channel" and "Modes" sections correctly. Thanks -Original Message- From: Amol Lad Sent: Monday, 4 October 2021 9:34 AM To: 'Aleksander Morgado' Cc: 'ModemManager (development)' Subject: RE: MM 1.18.2 Supported Bands and Current Bands are empty Hi Aleksander, It seems the bands are missing in MBIM mode and QMI is fine. Please see below output with MBIM and QMI as well. You will notice that: 1) "Bands" section is missing in MBIM 2) "Modes" section not showing all "supported" options in MBIM Both of above are correctly shown in an older MM release (1.12.6) Thanks MBIM # mmcli -m 0 -- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: a0193c11c5ea6e80f76bf9e745d04925de2e0867 -- Hardware | manufacturer: Sierra Wireless, Incorporated | model: Sierra Wireless EM7511 Qualcomm® Snapdragon™ X16 LTE-A | firmware revision: SWI9X50C_01.07.00.00 | h/w revision: EM7511 | supported: gsm-umts, lte |current: gsm-umts, lte | equipment id: 354580090133029 -- System | device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1 |drivers: cdc_mbim, qcserial | plugin: sierra | primary port: cdc-wdm0 | ports: cdc-wdm0 (mbim), ttyUSB0 (qcdm), ttyUSB1 (gps), | ttyUSB2 (at), wwan0 (net) -- Numbers |own: 9108813566 -- Status | unlock retries: sim-pin2 (3) | state: connected |power state: on |access tech: lte | signal quality: 29% (recent) -- Modes| supported: allowed: 3g, 4g; preferred: none |current: allowed: 3g, 4g; preferred: none -- IP | supported: ipv4, ipv6, ipv4v6 -- 3GPP | imei: 354580090133029 | enabled locks: fixed-dialing |operator id: 40493 | operator name: airtel | registration: home -- 3GPP EPS | ue mode of operation: csps-2 |initial bearer path: /org/freedesktop/ModemManager1/Bearer/0 | initial bearer apn: internet | initial bearer ip type: ipv4 -- SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 -- Bearer | paths: /org/freedesktop/ModemManager1/Bearer/1 QMI MODE # mmcli -m 0 -- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: 5df03ee4cfccf8393694255f566466a3690f -- Hardware | manufacturer: Sierra Wireless, Incorporated | model: EM7511 | firmware revision: SWI9X50C_01.07.00.00 33959b jenkins 2018/05/12 15:46:52 | carrier config: default | h/w revision: 10001 | supported: gsm-umts, lte |current: gsm-umts, lte | equipment id: 354580090133029 -- System | device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1 |drivers: qmi_wwan, qcserial | plugin: sierra | primary port: cdc-wdm0 | ports: cdc-wdm0 (qmi), ttyUSB0 (qcdm), ttyUSB1 (gps), | ttyUSB2 (at), wwan0 (net) -- Numbers |own: 9108813566 -- Status | lock: sim-pin2 | unlock retries: sim-pin (3), sim-pin2 (3), sim-puk (10), sim-puk2 (10) | state: connected |power state: on |access tech: lte | signal quality: 81% (recent) -- Modes| supported: allowed: 3g; preferred: none |
RE: MM 1.18.2 Supported Bands and Current Bands are empty
eutran-4, eutran-5, eutran-7, | eutran-8, eutran-9, eutran-12, eutran-13, eutran-14, eutran-18, | eutran-19, eutran-20, eutran-26, eutran-29, eutran-30, eutran-32, | eutran-41, eutran-46, eutran-66, utran-19 |current: eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, | eutran-8, eutran-9, eutran-12, eutran-13, eutran-14, eutran-18, | eutran-19, eutran-20, eutran-26, eutran-29, eutran-30, eutran-32, | eutran-41, eutran-46, eutran-66 -- IP | supported: ipv4, ipv6, ipv4v6 -- 3GPP | imei: 354580090133029 | enabled locks: fixed-dialing |operator id: 40493 | operator name: airtel | registration: home -- 3GPP EPS | ue mode of operation: csps-2 |initial bearer path: /org/freedesktop/ModemManager1/Bearer/0 | initial bearer apn: internet | initial bearer ip type: ipv4 -- SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 | sim slot paths: slot 1: /org/freedesktop/ModemManager1/SIM/0 (active) | slot 2: none -- Bearer | paths: /org/freedesktop/ModemManager1/Bearer/1 -----Original Message- From: Amol Lad Sent: Saturday, 2 October 2021 6:49 AM To: 'Aleksander Morgado' Cc: ModemManager (development) Subject: RE: MM 1.18.2 Supported Bands and Current Bands are empty Please find it below: -- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: a0193c11c5ea6e80f76bf9e745d04925de2e0867 -- Hardware | manufacturer: Sierra Wireless, Incorporated | model: Sierra Wireless EM7511 Qualcomm® Snapdragon™ X16 LTE-A | firmware revision: SWI9X50C_01.07.00.00 | h/w revision: EM7511 | supported: gsm-umts, lte |current: gsm-umts, lte | equipment id: 354580090133029 -- System | device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1 |drivers: cdc_mbim, qcserial | plugin: sierra | primary port: cdc-wdm0 | ports: cdc-wdm0 (mbim), ttyUSB0 (qcdm), ttyUSB1 (gps), | ttyUSB2 (at), wwan0 (net) -- Numbers |own: 9108813566 -- Status | unlock retries: sim-pin2 (3) | state: connected |power state: on |access tech: lte | signal quality: 12% (recent) -- Modes| supported: allowed: 3g, 4g; preferred: none |current: allowed: 3g, 4g; preferred: none -- IP | supported: ipv4, ipv6, ipv4v6 -- 3GPP | imei: 354580090133029 | enabled locks: fixed-dialing |operator id: 40493 | operator name: airtel | registration: home -- 3GPP EPS | ue mode of operation: csps-2 |initial bearer path: /org/freedesktop/ModemManager1/Bearer/0 | initial bearer apn: internet | initial bearer ip type: ipv4 -- SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 -- Bearer | paths: /org/freedesktop/ModemManager1/Bearer/1 -Original Message- From: Aleksander Morgado Sent: Saturday, 2 October 2021 3:50 AM To: Amol Lad Cc: ModemManager (development) Subject: Re: MM 1.18.2 Supported Bands and Current Bands are empty Hey, > > I'm testing MM 1.18.2 release and finding that the supported bands and > current bands are shown empty. I'm using EM7511 modem in MBIM mode in OpenWRT > framework (with QMI over MBIM enabled). The bands are displayed correctly in > an older MM release (1.12.6). Please let me know what additional information > I can provide regarding this. > > Please also note that the "length" property is also
RE: MM 1.18.2 Supported Bands and Current Bands are empty
Please find it below: -- General | path: /org/freedesktop/ModemManager1/Modem/0 | device id: a0193c11c5ea6e80f76bf9e745d04925de2e0867 -- Hardware | manufacturer: Sierra Wireless, Incorporated | model: Sierra Wireless EM7511 Qualcomm® Snapdragon™ X16 LTE-A | firmware revision: SWI9X50C_01.07.00.00 | h/w revision: EM7511 | supported: gsm-umts, lte |current: gsm-umts, lte | equipment id: 354580090133029 -- System | device: /sys/devices/platform/soc/soc:internal-regs/f10f.usb3/usb2/2-1 |drivers: cdc_mbim, qcserial | plugin: sierra | primary port: cdc-wdm0 | ports: cdc-wdm0 (mbim), ttyUSB0 (qcdm), ttyUSB1 (gps), | ttyUSB2 (at), wwan0 (net) -- Numbers |own: 9108813566 -- Status | unlock retries: sim-pin2 (3) | state: connected |power state: on |access tech: lte | signal quality: 12% (recent) -- Modes| supported: allowed: 3g, 4g; preferred: none |current: allowed: 3g, 4g; preferred: none -- IP | supported: ipv4, ipv6, ipv4v6 -- 3GPP | imei: 354580090133029 | enabled locks: fixed-dialing |operator id: 40493 | operator name: airtel | registration: home -- 3GPP EPS | ue mode of operation: csps-2 |initial bearer path: /org/freedesktop/ModemManager1/Bearer/0 | initial bearer apn: internet | initial bearer ip type: ipv4 -- SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0 -- Bearer | paths: /org/freedesktop/ModemManager1/Bearer/1 -Original Message- From: Aleksander Morgado Sent: Saturday, 2 October 2021 3:50 AM To: Amol Lad Cc: ModemManager (development) Subject: Re: MM 1.18.2 Supported Bands and Current Bands are empty Hey, > > I'm testing MM 1.18.2 release and finding that the supported bands and > current bands are shown empty. I'm using EM7511 modem in MBIM mode in OpenWRT > framework (with QMI over MBIM enabled). The bands are displayed correctly in > an older MM release (1.12.6). Please let me know what additional information > I can provide regarding this. > > Please also note that the "length" property is also missing in 1.18.2 > > MM 1.18.2 > modem.generic.supported-bands : -- > modem.generic.current-bands : -- > > MM 1.12.6 > modem.generic.supported-bands.length: 29 > modem.generic.supported-bands.value[1] : utran-1 > modem.generic.supported-bands.value[2] : utran-4 > modem.generic.supported-bands.value[3] : utran-6 > ... > > modem.generic.current-bands.length : 21 > modem.generic.current-bands.value[1]: eutran-1 > modem.generic.current-bands.value[2]: eutran-2 > modem.generic.current-bands.value[3]: eutran-3 > ... > Could you give here the output of "mmcli -m 0" when running 1.18.2? -- Aleksander https://aleksander.es
MM 1.18.2 Supported Bands and Current Bands are empty
Hi, I'm testing MM 1.18.2 release and finding that the supported bands and current bands are shown empty. I'm using EM7511 modem in MBIM mode in OpenWRT framework (with QMI over MBIM enabled). The bands are displayed correctly in an older MM release (1.12.6). Please let me know what additional information I can provide regarding this. Please also note that the "length" property is also missing in 1.18.2 MM 1.18.2 modem.generic.supported-bands : -- modem.generic.current-bands : -- MM 1.12.6 modem.generic.supported-bands.length: 29 modem.generic.supported-bands.value[1] : utran-1 modem.generic.supported-bands.value[2] : utran-4 modem.generic.supported-bands.value[3] : utran-6 ... modem.generic.current-bands.length : 21 modem.generic.current-bands.value[1]: eutran-1 modem.generic.current-bands.value[2]: eutran-2 modem.generic.current-bands.value[3]: eutran-3 ... Thanks Amol
RE: EM9190 Support
Thanks. I'll share the output as soon as I'll receive the device. I think the device IDs needs to be inserted in qcserial.c also? -Original Message- From: Aleksander Morgado Sent: Friday, 18 June 2021 2:22 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: EM9190 Support Hey On Fri, Jun 18, 2021 at 5:33 AM Amol Lad wrote: > > Thanks Aleksander, > > What is the recommended MM version to test 5G in this module (QMI & MBIM > mode)? Also what kernel version should I use (for qmi_wwan & cdc_mbim > drivers)? > Any MM 1.16.x release, or MM git master would be best I'd say. Regarding kernel version, for the MBIM mode I guess any recent kernel version should be enough; for the QMI mode I don't see device IDs for the EM9190 in the qmi_wwan driver, so probably you would need to insert the ids on runtime. Could you provide the full lsusb -v "1199:" output with the device in QMI mode, to see which are the qmi_wwan driver updates that we would need? -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: EM9190 Support
Thanks Aleksander, What is the recommended MM version to test 5G in this module (QMI & MBIM mode)? Also what kernel version should I use (for qmi_wwan & cdc_mbim drivers)? Thanks Amol -Original Message- From: Aleksander Morgado Sent: Thursday, 17 June 2021 6:50 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: EM9190 Support Hey, > > Does ModemManager/libqmi/libmbim support Sierra wireless EM9190 module? I'm > not sure if anyone actually got a chance to test EM919X with MM. Please > advise. > I haven't personally heard of anyone using it, truth be told. I did ask Sierra for a sample engineering module some months ago, but that didn't happen :/ There's a high chance that it works without issues, though. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
EM9190 Support
Hi, Does ModemManager/libqmi/libmbim support Sierra wireless EM9190 module? I'm not sure if anyone actually got a chance to test EM919X with MM. Please advise. Thanks Amol ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: libmbim 1.24.0 slowing down MM startup
Thanks a lot Aleksander, I've verified and the fix works! Thanks again Amol -Original Message- From: Aleksander Morgado Sent: Friday, 10 July 2020 1:58 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: libmbim 1.24.0 slowing down MM startup Hey Amol, > > Did you got a chance to see those logs? Please let me know if any other > > information is needed. > > > > Not yet, sorry. Will let you know as soon as I find anything. > Here's the fix: https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/merge_requests/28 I'll release a new 1.24.2 with this and other fixes. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: libmbim 1.24.0 slowing down MM startup
Hi Aleksander, Did you got a chance to see those logs? Please let me know if any other information is needed. Amol From: Amol Lad Sent: Wednesday, 8 July 2020 11:41 AM To: Aleksander Morgado Cc: ModemManager (development) Subject: RE: libmbim 1.24.0 slowing down MM startup Hi Aleksander, The crash was actually when mbim-proxy runs with --verbose. I applied your patch to fix it and attached are the requested logs. Thanks Amol -Original Message- From: Aleksander Morgado mailto:aleksan...@aleksander.es>> Sent: Tuesday, 7 July 2020 6:32 PM To: Amol Lad mailto:amol@4rf.com>> Cc: ModemManager (development) mailto:modemmanager-devel@lists.freedesktop.org>> Subject: Re: libmbim 1.24.0 slowing down MM startup Hey, > > I'm testing 1.14.0 and finding that libmbim has significantly slowed down MM > startup. I'm using EM7565 in MBIM mode. Please see below snippets from log > which highlight the delay. As you can see "couldn't load carrier config; > couldn't load SUPL; assistance data" are causing this slowness. > This looks like QMI over MBIM indications not working properly, how strange. Could you retry debug logging but also including mbim-proxy logs? E.g.: // stop ModemManager and make sure mbim-proxy is not running $ sudo /usr/libexec/mbim-proxy --verbose --no-exit // in another terminal, start ModemManager in debug mode -- Aleksander https://aleksander.es The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: libmbim 1.24.0 slowing down MM startup
Hi Aleksander, I followed your steps and mbim-proxy seg faults when MM tries to enable QMI indications over MBIM. This is just a heads-up just in case something clicks in your mind. I will try to get you a crash dump. Amol -Original Message- From: Aleksander Morgado Sent: Tuesday, 7 July 2020 6:32 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: libmbim 1.24.0 slowing down MM startup Hey, > > I'm testing 1.14.0 and finding that libmbim has significantly slowed down MM > startup. I'm using EM7565 in MBIM mode. Please see below snippets from log > which highlight the delay. As you can see "couldn't load carrier config; > couldn't load SUPL; assistance data" are causing this slowness. > This looks like QMI over MBIM indications not working properly, how strange. Could you retry debug logging but also including mbim-proxy logs? E.g.: // stop ModemManager and make sure mbim-proxy is not running $ sudo /usr/libexec/mbim-proxy --verbose --no-exit // in another terminal, start ModemManager in debug mode -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
libmbim 1.24.0 slowing down MM startup
Hi Aleksander, I'm testing 1.14.0 and finding that libmbim has significantly slowed down MM startup. I'm using EM7565 in MBIM mode. Please see below snippets from log which highlight the delay. As you can see "couldn't load carrier config; couldn't load SUPL; assistance data" are causing this slowness. MM 1.12.6 or MM 1.14.0 + libmbim 1.24.0 Jul 7 11:42:59 [6570]: [modem0] QMI-based capability and mode switching support enabled Jul 7 11:43:04 [6570]: [modem0] couldn't load carrier config: Operation timed out Jul 7 11:43:05 [6570]: [modem0/sim0] couldn't load list of emergency numbers: Failed to parse CRSM query result '+CRSM: 148,8,""' Jul 7 11:43:15 [6570]: [modem0] couldn't load SUPL server: Failed to receive indication with the current server settings Jul 7 11:43:25 [6570]: [modem0] couldn't load supported assistance data types: Failed to receive indication with the predicted orbits data source Jul 7 11:43:25 [6570]: [modem0] state changed (unknown -> disabled) MM 1.12.6 + libmbim 1.22.0 Jul 7 11:38:45 [6529]: QMI-based capability and mode switching support enabled Jul 7 11:38:46 [6529]: couldn't load list of Emergency Numbers: 'Failed to parse CRSM query result '+CRSM: 148,8,""'' Jul 7 11:38:46 [6529]: Modem: state changed (unknown -> disabled) Bearer connection is also slow with libmbim 1.24.0. If I switch to 1.22.0 in below then delay between registered and connect is not seen MM 1.12.6 + libmbim 1.24.0 Jul 7 12:00:21 [6548]: Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (unknown -> registering) Jul 7 12:00:21 [6548]: Modem /org/freedesktop/ModemManager1/Modem/0: 3GPP Registration state changed (registering -> home) Jul 7 12:00:21 [6548]: Modem /org/freedesktop/ModemManager1/Modem/0: state changed (enabled -> registered) Jul 7 12:00:47 [6548]: Simple connect state (6/8): Bearer Jul 7 12:00:47 [6548]: Simple connect state (7/8): Connect Jul 7 12:00:47 [6548]: Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connecting) Jul 7 12:00:51 [6548]: Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> connected) ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: [Resolved] Re: Issue building MM 1.14 on Ubuntu 18.04
Hi Aleksander,
After commenting PKG_FIXUP:=autoreconf, I'm getting below error:
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash
/home/alad/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/ModemManager-1.14.0/missing
aclocal-1.16 -I m4
/home/alad/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/ModemManager-1.14.0/missing:
line 81: aclocal-1.16: command not found
OpenWrt "master" has automake version 1.15.1.
Any suggestion?
Amol
-Original Message-
From: ModemManager-devel On
Behalf Of Aleksander Morgado
Sent: Tuesday, 7 July 2020 12:20 PM
To: Nick
Cc: ModemManager (development)
Subject: Re: [Resolved] Re: Issue building MM 1.14 on Ubuntu 18.04
Hey Nick
> Fixed - Issue was resolved by including autoconf-archive in the Openwrt
> toolchain, as demonstrated by this commit.
> https://github.com/openwrt/openwrt/commit/3c1d1d4332c7fbaccea01b92b28f
> 6d96f7222492
>
You're being forced to use autoconf-archive in the openwrt setup because the
ModemManager package in openwrt has:
PKG_FIXUP:=autoreconf
None of libqmi, libmbim, ModemManager should require autoreconf if building
from a source tarball, only when building from git. By explicitly running
autoreconf, the build is trying to rebuild the configure script instead of
using the provided one in the tarball.
I would definitely remove that line if possible. I think it was already removed
from libqmi and libmbim packages.
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Moving OpenWrt to 1.14.0
Hi Aleksander, Please advise when do you plan to update Openwrt/modemmanager to 1.14.0 release Thanks ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: Location Assistance Servers
Yes, download actually happens on cellular link. It's EM7565 modem. I'll send email to Sierra. The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: Aleksander Morgado Sent: Thursday, 12 March 2020 3:48 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: Location Assistance Servers Hey Amol, > > > Is there any way to disable XTRA location assistance? From where modemmanager > receives assistance servers information? Is this comes from the modem? I see > requests to download these files on cellular link. Who starts the download? > Is it modemmanager or modem? > Are you really seeing download attempts for those XTRA paths in the mobile link? That doesn't make sense to me. The modem firmware shouldn't be doing that IMO, because the whole purpose of the XTRA paths is to download them by other means (e.g. WiFi) and then inject them to the modem. I guess for some reason the modem itself may be doing that by itself? It's definitely not something triggered by ModemManager. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: Location Assistance Servers
Hi Aleksander, Is there any way to disable XTRA location assistance? From where modemmanager receives assistance servers information? Is this comes from the modem? I see requests to download these files on cellular link. Who starts the download? Is it modemmanager or modem? Thanks Amol From: Amol Lad Sent: Monday, 9 March 2020 1:43 PM To: ModemManager (development) Subject: Location Assistance Servers Hi, In some private APNs, location assistance servers are not reachable or not needed. Is there a way to disable location assistance? Thanks Amol # mmcli -m 0 --location-status Location | capabilities: 3gpp-lac-ci, gps-raw, gps-nmea, agps-msa, agps-msb | enabled: 3gpp-lac-ci | signals: no GPS | refresh rate: 30 seconds | supported assistance: xtra | assistance servers: https://xtrapath3.izatcloud.net/xtra3grcej.bin | https://xtrapath1.izatcloud.net/xtra3grcej.bin | https://xtrapath2.izatcloud.net/xtra3grcej.bin The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Location Assistance Servers
Hi, In some private APNs, location assistance servers are not reachable or not needed. Is there a way to disable location assistance? Thanks Amol # mmcli -m 0 --location-status Location | capabilities: 3gpp-lac-ci, gps-raw, gps-nmea, agps-msa, agps-msb | enabled: 3gpp-lac-ci | signals: no GPS | refresh rate: 30 seconds | supported assistance: xtra | assistance servers: https://xtrapath3.izatcloud.net/xtra3grcej.bin | https://xtrapath1.izatcloud.net/xtra3grcej.bin | https://xtrapath2.izatcloud.net/xtra3grcej.bin The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
carrier-configuration and carrier-configuration-revision
Hi, It will be more useful to show correct carrier-configuration and revision. Currently it shows "default" and "-" for revision. Any suggestion how this can be done? Also find below !IMPREF AT Command which gives the carrier configuration/revision. Thanks Amol # mmcli -m 0 -K modem.dbus-path : /org/freedesktop/ModemManager1/Modem/0 modem.generic.device-identifier : a0de6c9e65f5ca5cd94b897407889c7e257cb7c8 modem.generic.manufacturer : Sierra Wireless, Incorporated modem.generic.model : Sierra Wireless EM7565 Qualcomm\302\256 Snapdragon\342\204\242 X16 LTE-A modem.generic.revision : SWI9X50C_01.11.00.00 modem.generic.carrier-configuration : default modem.generic.carrier-configuration-revision: -- modem.generic.hardware-revision : EM7565 response: '!IMPREF: preferred fw version:01.11.00.00 preferred carrier name: GENERIC preferred config name: GENERIC_002.023_000 preferred subpri index: 000 current fw version: 01.11.00.00 current carrier name:GENERIC current config name: GENERIC_002.023_000 current subpri index:000' The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Leading zero(s) missing from MCC/MNC output
Hi, I'm noticing a (minor) issue in MM 1.12.4 release. The operator code is "53005" but leading "0" is missing in MNC field when displayed using -location-get command as below. I've noticed that if there are one or more leading zeros then both MCC and MNC do not report it. I've a test APN with MCC "001" and MNC "01" and what is see is "1" and "1" for both MCC and MNC respectively. I think leading zero(s) should not be removed. Please advise. root@AprisaLTE:~# mmcli -m 0 --location-get -K modem.location.3gpp.mcc : 530 modem.location.3gpp.mnc : 5 Thanks Amol The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: ModemManager 1.12.4
Thank you for your efforts! Please also update OpenWrt with new release. Thanks again. Amol The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: ModemManager-devel On Behalf Of Aleksander Morgado Sent: Monday, 13 January 2020 10:16 PM To: ModemManager (development) Subject: ANN: ModemManager 1.12.4 Hey hey, This is the second bugfix release in the ModemManager 1.12.x series. Overview of changes in ModemManager 1.12.4 --- This release breaks the API of the bindings supporting the MMModem3gppNetwork type, used as result when a Modem3gpp.Scan() operation finishes. This type is now a boxed type with explicit copy/free info, so the interpreter using the bindings is now able to cleanly dispose these variables (it would make the program crash otherwise, so the change is well justified). The getters for the MMModem3gppNetwork type now look like this: E.g. instead of: ModemManager.Modem3gpp.network_get_operator_code(network) We should now do: network.get_operator_code() A new example python application using the Modem3gpp.Scan() operation is provided in the sources, under examples/network-scan-python. There is no API/ABI break in libmm-glib itself. The list of additional changes in this version includes: * Core: ** Added missing ME error codes when building GError variables for the MM_MOBILE_EQUIPMENT_ERROR domain. * Bearer: ** Avoid connection checks or stats updates while disconnecting. * Serial port: ** Fix segfault when port flash operation gets cancelled. * Simple interface: ** Fix the ongoing connection cancellable handling. * Voice interface: ** Fix segfault when voice support check fails. * QMI: ** Fixed several memory leaks, including a severe one happening when multiple GPS sources (e.g. raw and nmea) were enabled at the same time. * Plugins: ** ublox: ignore errors when attempting to disconnect last bearer. * mmcli: ** Allow "yes" and "no" as boolean strings. * Several other minor fixes and memory leak plugs. - About ModemManager: http://www.freedesktop.org/wiki/Software/ModemManager Download here: http://www.freedesktop.org/software/ModemManager/ModemManager-1.12.4.tar.xz Verify it: $ md5sum ModemManager-1.12.4.tar.xz 22280110d75c87a89786a317aa9cee04 ModemManager-1.12.4.tar.xz Please report bugs either to: modemmanager-devel@lists.freedesktop.org Or to gitlab: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: Modem kernel driver changes from cdc_mbim to qmi_wwan after suspend/resume?
Can we see the output of AT!USBCOMP? AT command before and after the issue? root@OpenWrt:/# mmcli -m 0 --command=AT!ENTERCND=\"A710\" response: '' root@OpenWrt:/# mmcli -m 0 --command=AT!USBCOMP? response: 'Config Index: 1 Config Type: 3 (Generic) Interface bitmask: 100D (diag,nmea,modem,mbim) ' root@OpenWrt:/# The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: ModemManager-devel On Behalf Of Aleksander Morgado Sent: Thursday, 19 December 2019 3:36 PM To: Bjørn Mork Cc: ModemManager (development) Subject: Modem kernel driver changes from cdc_mbim to qmi_wwan after suspend/resume? Hey Bjørn & all, I wonder if you have any idea why this issue is happening? https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/165#note_368404 We can see how the kernel driver reported as managing the device that owns the cdc-wdm port changes from cdc_mbim (original one after boot) to qmi_wwan (after a suspend/resume cycle). This makes ModemManager attempt QMI probing instead of MBIM probing on the port, and that fails, so the modem is no longer used after the suspend/resume cycle. Any hint? -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: Cannot send message: QMI service 'pdc' version '1.15' required, got version '1.0'
Looks good to me. Thanks! The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: Aleksander Morgado Sent: Friday, 13 December 2019 11:07 PM To: Amol Lad Cc: modemmanager-devel@lists.freedesktop.org Subject: Re: Cannot send message: QMI service 'pdc' version '1.15' required, got version '1.0' > > > I’m testing mm 1.12.2 + libqmi 1.24.2 on sierra EM7565 (openwrt). Please > > see last line of log. Is this ok? > > > > > > > > I do not see this in mm 1.12.0 + libqmi 1.24.0 > > > > > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Enabling QMI indications > > via MBIM... > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] enabled QMI > > indications via MBIM > > > > Dec 13 15:51:38 OpenWrt [5904]: [cdc-wdm0] MBIM device is > > QMI capable > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Allocating new client ID... > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Registered 'dms' (version > > 1.0) client with ID '1' > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Allocating new client ID... > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Registered 'nas' (version > > 1.25) client with ID '2' > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Allocating new client ID... > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Registered 'loc' (version > > 2.0) client with ID '1' > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Allocating new client ID... > > > > Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Registered 'pdc' (version > > 1.0) client with ID '1' > > > > Dec 13 15:51:39 OpenWrt [5904]: QMI-based capability and > > mode switching support enabled > > > > Dec 13 15:51:39 OpenWrt [5904]: couldn't load carrier config: > > 'Cannot send message: QMI service 'pdc' version '1.15' required, got > > version '1.0'' > > > > I believe the issue is unrelated to the MM/libqmi version. It would be > very strange that the modem replies differnet things when using > different libqmi versions really. > > The problem, though, is something we should fix. The version checks > done by libqmi are truly broken, because they rely on the version info > for each message that is defined in our message database, and that > information is far from good or up to date. If the message is not > supported by the device, we'll get an error when trying to use it. > Trying to return an early error before sending the request assuming > our information of when it was introduced is good is not the way to > go. > See https://gitlab.freedesktop.org/mobile-broadband/libqmi/merge_requests/80 Comments welcome -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Cannot send message: QMI service 'pdc' version '1.15' required, got version '1.0'
Hi, I'm testing mm 1.12.2 + libqmi 1.24.2 on sierra EM7565 (openwrt). Please see last line of log. Is this ok? I do not see this in mm 1.12.0 + libqmi 1.24.0 Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Enabling QMI indications via MBIM... Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] enabled QMI indications via MBIM Dec 13 15:51:38 OpenWrt [5904]: [cdc-wdm0] MBIM device is QMI capable Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Allocating new client ID... Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Registered 'dms' (version 1.0) client with ID '1' Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Allocating new client ID... Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Registered 'nas' (version 1.25) client with ID '2' Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Allocating new client ID... Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Registered 'loc' (version 2.0) client with ID '1' Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Allocating new client ID... Dec 13 15:51:38 OpenWrt [5904]: [/dev/cdc-wdm0] Registered 'pdc' (version 1.0) client with ID '1' Dec 13 15:51:39 OpenWrt [5904]: QMI-based capability and mode switching support enabled Dec 13 15:51:39 OpenWrt [5904]: couldn't load carrier config: 'Cannot send message: QMI service 'pdc' version '1.15' required, got version '1.0'' Thanks Amol The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
MM 1.12.2 plugin load errors
Hi, I'm using Sierra EM7575 in OpenWrt and just to test release 1.12.2, I changed modemmanager's manifest file in OpenWrt to use release 1.12.2. However, I get below errors on startup. Is this normal? Or I need to enable config option(s) for Sierra chipset? Dec 12 08:01:43 OpenWrt [14006]: ModemManager (version 1.12.2) starting in system bus... Dec 12 08:01:43 OpenWrt [14006]: [plugin manager] could not load plugin '/usr/lib/ModemManager/libmm-plugin-zte.so': Error relocating /usr/lib/ModemManager/libmm-plugin-zte.so: mm_broadband_modem_icera_get_type: symbol not found Dec 12 08:01:43 OpenWrt [14006]: [plugin manager] could not load plugin '/usr/lib/ModemManager/libmm-plugin-telit.so': Error relocating /usr/lib/ModemManager/libmm-plugin-telit.so: mm_broadband_modem_mbim_telit_new: symbol not found Dec 12 08:01:43 OpenWrt [14006]: [plugin manager] could not load plugin '/usr/lib/ModemManager/libmm-plugin-sierra-legacy.so': Error relocating /usr/lib/ModemManager/libmm-plugin-sierra-legacy.so: mm_broadband_bearer_sierra_new_finish: symbol not found Dec 12 08:01:43 OpenWrt [14006]: [plugin manager] could not load plugin '/usr/lib/ModemManager/libmm-plugin-samsung.so': Error relocating /usr/lib/ModemManager/libmm-plugin-samsung.so: mm_broadband_modem_icera_get_type: symbol not found Dec 12 08:01:43 OpenWrt [14006]: [plugin manager] could not load plugin '/usr/lib/ModemManager/libmm-plugin-option.so': Error relocating /usr/lib/ModemManager/libmm-plugin-option.so: mm_broadband_modem_option_new: symbol not found Dec 12 08:01:43 OpenWrt [14006]: [plugin manager] could not load plugin '/usr/lib/ModemManager/libmm-plugin-option-hso.so': Error relocating /usr/lib/ModemManager/libmm-plugin-option-hso.so: mm_broadband_modem_option_get_type: symbol not found Dec 12 08:01:43 OpenWrt [14006]: [plugin manager] could not load plugin '/usr/lib/ModemManager/libmm-plugin-novatel.so': Error relocating /usr/lib/ModemManager/libmm-plugin-novatel.so: mm_broadband_modem_novatel_new: symbol not found Dec 12 08:01:43 OpenWrt [14006]: [plugin manager] could not load plugin '/usr/lib/ModemManager/libmm-plugin-nokia-icera.so': Error relocating /usr/lib/ModemManager/libmm-plugin-nokia-icera.so: mm_broadband_modem_icera_new: symbol not found Dec 12 08:01:43 OpenWrt [14006]: [plugin manager] could not load plugin '/usr/lib/ModemManager/libmm-plugin-fibocom.so': Error relocating /usr/lib/ModemManager/libmm-plugin-fibocom.so: mm_broadband_modem_xmm_new: symbol not found Dec 12 08:01:43 OpenWrt [14006]: [plugin manager] could not load plugin '/usr/lib/ModemManager/libmm-plugin-dell.so': Error relocating /usr/lib/ModemManager/libmm-plugin-dell.so: mm_common_novatel_custom_init: symbol not found Amol The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Initial Bearer APN is incorrect
Hi, I'm using Sierra EM7565 in latest openwrt with MM 1.12.0. When I start a connection using "-simple-connect" command then the "initial bearer" used is the APN which was last made active. This breaks in some private APNs which do not recognise that APN. Please refer to below command sequence. I would have thought when we delete the bearer then the corresponding CGDCONT should have also got deleted but that's not happening and I think this is the reason why "initial bearer" from the new connection uses the "old deleted bearer APN" # mmcli -m 0 -e successfully enabled the modem # mmcli -m 0 --simple-connect="apn=airtelgprs.com" successfully connected the modem # mmcli -m 0 --command=AT+CGDCONT? response: '+CGDCONT: 1,"IP","airtelgprs.com","0.0.0.0",0,0,0,0' # mmcli -m 0 ... Bearer |dbus path: /org/freedesktop/ModemManager1/Bearer/1 # mmcli -m 0 --simple-disconnect=/org/freedesktop/ModemManager1/Bearer/1 successfully disconnected all bearers in the modem # mmcli -m 0 --delete-bearer=/org/freedesktop/ModemManager1/Bearer/1 successfully deleted bearer from modem # mmcli -m 0 --command=AT+CGDCONT? response: '+CGDCONT: 1,"IP","airtelgprs.com","0.0.0.0",0,0,0,0 >From above, CGDCONT is still present and not deleted from mode. I ran mm in >debug mode but no output when "-delete-bearer" command is executed. Now start >a new connection: # mmcli -m 0 --simple-connect="apn=jionet" successfully connected the modem # mmcli -m 0 3GPP EPS | ue mode of operation: csps-2 | initial bearer dbus path: /org/freedesktop/ModemManager1/Bearer/3 | initial bearer apn: airtelgprs.com | initial bearer ip type: ipv4 As you can see initial bearer apn is "airtelgprs.com" which we deleted previously Any advise will be of great help. Thanks Amol Full output (and mmcli -b output reports that new apn is "jionet") root@OpenWrt:/# mmcli -m 0 General |dbus path: /org/freedesktop/ModemManager1/Modem/0 |device id: b1778145998fe05be11f9841377b5222e395cd27 Hardware | manufacturer: Sierra Wireless, Incorporated |model: Sierra Wireless EM7565 Qualcomm(r) Snapdragon(tm) X16 LTE-A |firmware revision: SWI9X50C_01.11.00.00 | carrier config: default | h/w revision: EM7565 |supported: gsm-umts, lte | current: gsm-umts, lte | equipment id: 359260080211680 System | device: /sys/devices/platform/soc/soc:internal-regs/f10f8000.usb3/usb5/5-1 | drivers: qcserial, cdc_mbim | plugin: Sierra | primary port: cdc-wdm0 |ports: ttyUSB0 (qcdm), ttyUSB1 (gps), ttyUSB2 (at), | cdc-wdm0 (mbim), wwan0 (net) Numbers | own: 918660286965 Status | unlock retries: sim-pin2 (3) |state: connected | power state: on | access tech: lte | signal quality: 19% (recent) Modes|supported: allowed: 3g; preferred: none | allowed: 4g; preferred: none | allowed: 3g, 4g; preferred: 3g | allowed: 3g, 4g; preferred: 4g | current: allowed: 4g; preferred: none Bands|supported: utran-1, utran-4, utran-6, utran-5, utran-8, utran-9, | utran-2, eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, | eutran-8, eutran-9, eutran-12, eutran-13, eutran-18, eutran-19, | eutran-20, eutran-26, eutran-28, eutran-29, eutran-30, eutran-32, | eutran-41, eutran-46, eutran-66, utran-19 | current: eutran-1, eutran-2, eutran-3, eutran-4, eutran-5, eutran-7, | eutran-8, eutran-9, eutran-12, eutran-13, eutran-18, eutran-19, | eutran-20, eutran-26, eutran-28, eutran-29, eutran-30, eutran-32, | eutran-41, eutran-46, eutran-66 IP |supported: ipv4, ipv6, ipv4v6 3GPP | imei: 359260080211680 |enabled locks:
RE: CIDs not released when MM stops/restarts [openwrt]
Hi,
I'm attempting to fix below reported problem with below patch. But mm crashes
as soon as g_list_free_full (self->priv->qmi_clients, g_free) is called in
mm_port_mbim_close(). If I comment g_list_free_full, then mm shuts down
cleanly. Any suggestion what is going wrong?
Thanks
Amol
diff --git a/src/mm-port-mbim.c b/src/mm-port-mbim.c
index dbc70fef..4f620a55 100644
--- a/src/mm-port-mbim.c
+++ b/src/mm-port-mbim.c
@@ -424,6 +424,20 @@ mm_port_mbim_close (MMPortMbim *self,
#if defined WITH_QMI && QMI_MBIM_QMUX_SUPPORTED
if (self->priv->qmi_device) {
GError *error = NULL;
+GList *l;
+/* Release all allocated clients */
+for (l = self->priv->qmi_clients; l; l = g_list_next (l)) {
+QmiClient *qmi_client = QMI_CLIENT (l->data);
+
+mm_dbg ("Releasing client for qmi_clients '%s'...",
qmi_service_get_string (qmi_client_get_service (qmi_client)));
+qmi_device_release_client (self->priv->qmi_device,
+ qmi_client,
+
QMI_DEVICE_RELEASE_CLIENT_FLAGS_RELEASE_CID,
+ 3, NULL, NULL, NULL);
+g_clear_object (_client);
+}
+g_list_free_full (self->priv->qmi_clients, g_free);
+self->priv->qmi_clients = NULL;
if (!qmi_device_close (self->priv->qmi_device, )) {
mm_warn ("Couldn't properly close QMI device: %s", error->message);
@@ -473,9 +487,17 @@ static void
dispose (GObject *object)
{
MMPortMbim *self = MM_PORT_MBIM (object);
+GList *l;
#if defined WITH_QMI && QMI_MBIM_QMUX_SUPPORTED
-g_list_free_full (self->priv->qmi_clients, g_object_unref);
+/* Deallocate all clients */
+for (l = self->priv->qmi_clients; l; l = g_list_next (l)) {
+QmiClient *qmi_client = QMI_CLIENT (l->data);
+
+if (qmi_client)
+g_object_unref (qmi_client);
+}
+g_list_free_full (self->priv->qmi_clients, g_free);
self->priv->qmi_clients = NULL;
g_clear_object (>priv->qmi_device);
#endif
From: Amol Lad
Sent: Thursday, 21 November 2019 2:52 PM
To: modemmanager-devel@lists.freedesktop.org
Subject: CIDs not released when MM stops/restarts [openwrt]
Hi,
I'm using MM 1.12.0 in openwrt system [EM7565 in MBIM mode].
When MM starts , we see below Client ID allocations.
Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Allocating new client ID...
Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Registered 'dms' (version 1.0)
client with ID '3'
Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Allocating new client ID...
Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Registered 'nas' (version 1.25)
client with ID '4'
Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Allocating new client ID...
Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Registered 'loc' (version 2.0)
client with ID '3'
Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Allocating new client ID...
Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Registered 'pdc' (version 1.0)
client with ID '3'
However, when I restart MM using "service modemmanager restart" command then
the log becomes:
Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Allocating new client ID...
Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Registered 'dms' (version 1.0)
client with ID '4'
Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Allocating new client ID...
Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Registered 'nas' (version
1.25) client with ID '5'
Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Allocating new client ID...
Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Registered 'loc' (version 2.0)
client with ID '4'
Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Allocating new client ID...
Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Registered 'pdc' (version 1.0)
client with ID '4'
Restarting MM again increments the CIDs. It seems when MM stops then CIDs are
not released eventually resulting in "ClientIdsExhausted" error after multiple
MM restarts.
(INFO: If I issue "qmicli -d /dev/cdc-wdm0 -p -nas-reset" then "nas" CID gets
reset)
Please let me know if any more information is needed and advise how we can
address this.
Thanks
Amol
The information in this email communication (inclusive of attachments) is
confidential to 4RF Limited and the intended recipient(s). If you are not the
intended recipient(s), please note that any use, disclosure, distribution or
copying of this information or any part thereof is strictly prohibited and that
the author accepts no liability for the consequences of any action taken on the
basis of the information provided. If you have received this email in error,
please notify the sender immediately by return email and then delete all
CIDs not released when MM stops/restarts [openwrt]
Hi, I'm using MM 1.12.0 in openwrt system [EM7565 in MBIM mode]. When MM starts , we see below Client ID allocations. Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Allocating new client ID... Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Registered 'dms' (version 1.0) client with ID '3' Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Allocating new client ID... Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Registered 'nas' (version 1.25) client with ID '4' Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Allocating new client ID... Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Registered 'loc' (version 2.0) client with ID '3' Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Allocating new client ID... Nov 21 08:50:00 OpenWrt [9084]: [/dev/cdc-wdm0] Registered 'pdc' (version 1.0) client with ID '3' However, when I restart MM using "service modemmanager restart" command then the log becomes: Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Allocating new client ID... Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Registered 'dms' (version 1.0) client with ID '4' Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Allocating new client ID... Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Registered 'nas' (version 1.25) client with ID '5' Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Allocating new client ID... Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Registered 'loc' (version 2.0) client with ID '4' Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Allocating new client ID... Nov 21 08:50:53 OpenWrt [10172]: [/dev/cdc-wdm0] Registered 'pdc' (version 1.0) client with ID '4' Restarting MM again increments the CIDs. It seems when MM stops then CIDs are not released eventually resulting in "ClientIdsExhausted" error after multiple MM restarts. (INFO: If I issue "qmicli -d /dev/cdc-wdm0 -p -nas-reset" then "nas" CID gets reset) Please let me know if any more information is needed and advise how we can address this. Thanks Amol The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: --firmware-list crashes modemmanager?
Surprising; I'm kind of sure there is a crash when running --firmware-list command. I'm using Sierra EM7430 in MBIM mode. qmicli output is below. What is your configuration? root@OpenWrt:/# qmicli -d /dev/cdc-wdm0 -p --dms-list-stored-images [/dev/cdc-wdm0] Device list of stored images retrieved: [0] Type:'modem' Maximum: '4' [modem0] Unique ID: '?_?' Build ID: '02.30.03.00_?' Storage index: '1' Failure count: '0' >>>>>>>>>> [CURRENT] <<<<<<<<<< [modem1] Unique ID: '?_?' Build ID: '02.20.03.01_?' Storage index: '2' Failure count: '0' [modem2] Unique ID: '?_?' Build ID: '02.20.03.00_?' Storage index: '3' Failure count: '0' [modem3] Unique ID: '?_?' Build ID: '02.24.05.06_?' Storage index: '4' Failure count: '0' [1] Type:'pri' Maximum: '50' [pri0] Unique ID: '001.026_001' Build ID: '02.30.03.00_DOCOMO' >>>>>>>>>> [CURRENT] <<<<<<<<<< [pri1] Unique ID: '002.046_001' Build ID: '02.30.03.00_GENERIC' [pri2] Unique ID: '001.023_001' Build ID: '02.30.03.00_KDDI' [pri3] Unique ID: '001.024_000' Build ID: '02.30.03.00_Softbank' [pri4] Unique ID: '002.044_000' Build ID: '02.30.03.00_TELSTRA' The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: Bjørn Mork Sent: Friday, 15 November 2019 8:21 PM To: Amol Lad Cc: Aleksander Morgado ; modemmanager-devel@lists.freedesktop.org Subject: Re: --firmware-list crashes modemmanager? Amol Lad writes: > root@OpenWrt:/# mmcli -m 0 --firmware-list > error: couldn't list firmware images: > 'GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient > disconnected from message bus without replying' Odd. Works for me: root@wrt1900ac-1:/# mmcli -m 0 --firmware-list Firmware | list: 01.09.04.00_GENERIC_002.019_000 | current: yes | gobi pri unique id: 002.019_000 | gobi modem unique id: ?_? Bjørn ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
--firmware-list crashes modemmanager?
Hi Aleksander, It seems "mmcli -m 0 -firmware-list" is crashing modemmanager. There is no debug output also in -debug mode. Please see last two commands in bottom of this email. I'm running MM 1.12.0 (in openwrt) root@OpenWrt:/# mmcli -m 0 General |dbus path: /org/freedesktop/ModemManager1/Modem/0 |device id: 1f75cd7f52f1f8d71fed0aeb735b4c9c28e3b338 Hardware | manufacturer: Sierra Wireless, Incorporated |model: Sierra Wireless EM7430 Qualcomm(r) Snapdragon(tm) X7 LTE-A |firmware revision: SWI9X30C_02.30.03.00 | carrier config: default | h/w revision: EM7430 |supported: gsm-umts, lte | current: gsm-umts, lte | equipment id: 359075062306476 System | device: /sys/devices/platform/soc/soc:internal-regs/f10f8000.usb3/usb5/5-1 | drivers: qcserial, cdc_mbim | plugin: Sierra | primary port: cdc-wdm0 |ports: ttyUSB0 (qcdm), ttyUSB1 (gps), ttyUSB2 (at), | cdc-wdm0 (mbim), wwan0 (net) Numbers | own: 9108813566 Status | unlock retries: sim-pin2 (3) |state: connected | power state: on | access tech: lte | signal quality: 0% (recent) Modes|supported: allowed: 3g; preferred: none | allowed: 4g; preferred: none | allowed: 3g, 4g; preferred: 3g | allowed: 3g, 4g; preferred: 4g | current: allowed: 4g; preferred: none Bands|supported: utran-1, utran-6, utran-5, utran-8, utran-9, eutran-1, | eutran-3, eutran-5, eutran-7, eutran-8, eutran-18, eutran-19, | eutran-21, eutran-28, eutran-38, eutran-39, eutran-40, eutran-41, | utran-19 | current: eutran-1, eutran-3, eutran-5, eutran-7, eutran-8, | eutran-18, eutran-19, eutran-21, eutran-28, eutran-38, eutran-39, | eutran-40, eutran-41 IP |supported: ipv4, ipv6, ipv4v6 3GPP | imei: 359075062306476 |enabled locks: fixed-dialing | operator id: 40445 |operator name: airtel | registration: home 3GPP EPS | ue mode of operation: csps-2 SIM |dbus path: /org/freedesktop/ModemManager1/SIM/0 Bearer |dbus path: /org/freedesktop/ModemManager1/Bearer/0 root@OpenWrt:/# mmcli -m 0 --firmware-list error: couldn't list firmware images: 'GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying' root@OpenWrt:/# mmcli -m 0 error: couldn't find modem at '/org/freedesktop/ModemManager1/Modem/0' The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: MM_BEARER_IP_FAMILY_ANY broken in MM 1.12.0?
Thanks Aleksander,
The patch works with ipv4-only APN. I've set iptype to 'any' and it connects
good and stays connected.
If someone can test with ipv6/ipv4v6 APNs then it would be really great.
Thanks
Amol
The information in this email communication (inclusive of attachments) is
confidential to 4RF Limited and the intended recipient(s). If you are not the
intended recipient(s), please note that any use, disclosure, distribution or
copying of this information or any part thereof is strictly prohibited and that
the author accepts no liability for the consequences of any action taken on the
basis of the information provided. If you have received this email in error,
please notify the sender immediately by return email and then delete all
instances of this email from your system. 4RF Limited will not accept
responsibility for any consequences associated with the use of this email
(including, but not limited to, damages sustained as a result of any viruses
and/or any action or lack of action taken in reliance on it).-Original
Message-
From: Aleksander Morgado
Sent: Friday, 15 November 2019 6:57 PM
To: Amol Lad
Cc: modemmanager-devel@lists.freedesktop.org
Subject: Re: MM_BEARER_IP_FAMILY_ANY broken in MM 1.12.0?
On Fri, Nov 15, 2019 at 1:41 PM Amol Lad wrote:
>
> I'll test it straight away but before that, is similar change needed in
> proto_modemmanager_teardown () as well?
>
Yep yep, you're right, I've updated the patch:
https://github.com/aleksander0m/openwrt-packages/commit/50264dfbd1b365d4639a89085345dd7578021dc9
> proto_modemmanager_teardown() {
> local interface="$1"
>
> local modemstatus bearerpath errorstring local bearermethod_ipv4
> bearermethod_ipv6
>
> local device lowpower iptype
> json_get_vars device lowpower iptype
>
> echo "stopping network"
>
> # load connected bearer information, just the first one should be ok
> modemstatus=$(mmcli --modem="${device}" --output-keyvalue)
> bearerpath=$(modemmanager_get_field "${modemstatus}"
> "modem.generic.bearers.value\[1\]")
> [ -n "${bearerpath}" ] || {
> echo "couldn't load bearer path"
> return
> }
>
> # ip type IPv4 is assumed if none explicitly given [ -z "${iptype}" ]
> && iptype="ipv4"
>
> # load bearer connection methods
> bearerstatus=$(mmcli --bearer "${bearerpath}" --output-keyvalue) [
> "$iptype" = "ipv4" ] || [ "$iptype" = "ipv4v6" ] && {
> bearermethod_ipv4=$(modemmanager_get_field "${bearerstatus}"
> "bearer.ipv4-config.method") echo "IPv4 connection teardown required in
> interface ${interface}: ${bearermethod_ipv4}"
> }
> [ "$iptype" = "ipv6" ] || [ "$iptype" = "ipv4v6" ] && {
> bearermethod_ipv6=$(modemmanager_get_field "${bearerstatus}"
> "bearer.ipv6-config.method") echo "IPv6 connection teardown required in
> interface ${interface}: ${bearermethod_ipv6}"
> }
>
>
> The information in this email communication (inclusive of attachments)
> is confidential to 4RF Limited and the intended recipient(s). If you
> are not the intended recipient(s), please note that any use,
> disclosure, distribution or copying of this information or any part
> thereof is strictly prohibited and that the author accepts no
> liability for the consequences of any action taken on the basis of the
> information provided. If you have received this email in error, please
> notify the sender immediately by return email and then delete all
> instances of this email from your system. 4RF Limited will not accept
> responsibility for any consequences associated with the use of this
> email (including, but not limited to, damages sustained as a result of
> any viruses and/or any action or lack of action taken in reliance on
> it).-Original Message-
> From: Aleksander Morgado
> Sent: Friday, 15 November 2019 6:04 PM
> To: Amol Lad
> Cc: modemmanager-devel@lists.freedesktop.org
> Subject: Re: MM_BEARER_IP_FAMILY_ANY broken in MM 1.12.0?
>
> > > > Please find logs for mm in debug mode for iptype set to "ipv4"
> > > > and "any" separately
> > > >
> > >
> > > Ah, I know what the issue is. The "any" ip-type case is not being
> > > handled in the modemmanager.proto file in the openwrt package, so
> > > as soon as the modem gets connected, it just fails. Let me fix that.
> > >
> >
> > Could you please retest with this patch applied?
> > https://github.com/aleksander0m/openwrt-packages/commit/045fd921c153
> > 31
> > 637d1ec874fe1dc61fac7e8403
> >
>
> Sorry, forgot to update package version, please try this one:
> https://github.com/aleksander0m/openwrt-packages/commit/fbf60bdd2d5ebc
> 4eeeaee1d690299c2530a9cc12
>
> --
> Aleksander
> https://aleksander.es
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: MM_BEARER_IP_FAMILY_ANY broken in MM 1.12.0?
I'll test it straight away but before that, is similar change needed in
proto_modemmanager_teardown () as well?
proto_modemmanager_teardown() {
local interface="$1"
local modemstatus bearerpath errorstring
local bearermethod_ipv4 bearermethod_ipv6
local device lowpower iptype
json_get_vars device lowpower iptype
echo "stopping network"
# load connected bearer information, just the first one should be ok
modemstatus=$(mmcli --modem="${device}" --output-keyvalue)
bearerpath=$(modemmanager_get_field "${modemstatus}"
"modem.generic.bearers.value\[1\]")
[ -n "${bearerpath}" ] || {
echo "couldn't load bearer path"
return
}
# ip type IPv4 is assumed if none explicitly given
[ -z "${iptype}" ] && iptype="ipv4"
# load bearer connection methods
bearerstatus=$(mmcli --bearer "${bearerpath}" --output-keyvalue)
[ "$iptype" = "ipv4" ] || [ "$iptype" = "ipv4v6" ] && {
bearermethod_ipv4=$(modemmanager_get_field "${bearerstatus}"
"bearer.ipv4-config.method")
echo "IPv4 connection teardown required in interface ${interface}:
${bearermethod_ipv4}"
}
[ "$iptype" = "ipv6" ] || [ "$iptype" = "ipv4v6" ] && {
bearermethod_ipv6=$(modemmanager_get_field "${bearerstatus}"
"bearer.ipv6-config.method")
echo "IPv6 connection teardown required in interface ${interface}:
${bearermethod_ipv6}"
}
The information in this email communication (inclusive of attachments) is
confidential to 4RF Limited and the intended recipient(s). If you are not the
intended recipient(s), please note that any use, disclosure, distribution or
copying of this information or any part thereof is strictly prohibited and that
the author accepts no liability for the consequences of any action taken on the
basis of the information provided. If you have received this email in error,
please notify the sender immediately by return email and then delete all
instances of this email from your system. 4RF Limited will not accept
responsibility for any consequences associated with the use of this email
(including, but not limited to, damages sustained as a result of any viruses
and/or any action or lack of action taken in reliance on it).-Original
Message-
From: Aleksander Morgado
Sent: Friday, 15 November 2019 6:04 PM
To: Amol Lad
Cc: modemmanager-devel@lists.freedesktop.org
Subject: Re: MM_BEARER_IP_FAMILY_ANY broken in MM 1.12.0?
> > > Please find logs for mm in debug mode for iptype set to "ipv4" and
> > > "any" separately
> > >
> >
> > Ah, I know what the issue is. The "any" ip-type case is not being
> > handled in the modemmanager.proto file in the openwrt package, so as
> > soon as the modem gets connected, it just fails. Let me fix that.
> >
>
> Could you please retest with this patch applied?
> https://github.com/aleksander0m/openwrt-packages/commit/045fd921c15331
> 637d1ec874fe1dc61fac7e8403
>
Sorry, forgot to update package version, please try this one:
https://github.com/aleksander0m/openwrt-packages/commit/fbf60bdd2d5ebc4eeeaee1d690299c2530a9cc12
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: MM_BEARER_IP_FAMILY_ANY broken in MM 1.12.0?
Please find logs for mm in debug mode for iptype set to "ipv4" and "any" separately Thanks Amol The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: Aleksander Morgado Sent: Friday, 15 November 2019 2:37 PM To: Amol Lad Cc: modemmanager-devel@lists.freedesktop.org Subject: Re: MM_BEARER_IP_FAMILY_ANY broken in MM 1.12.0? Hey > > I’m using openwrt-master with latest mm 1.12.0 with EM7430 modem. As > there were few discussions regarding using iptype as “any” in this > forum so I tried it using below openwrt configuration > > > > config interface 'wwan' > > option device > '/sys/devices/platform/soc/soc:internal-regs/f10f8000.usb3/usb5/5-1' > > option proto 'modemmanager' > > option apn '4rf.com' > > option iptype 'any' > > > > However, connection immediately gets disconnected after successful > connect which results in indefinite cycle of > > > > enabling->enabled->registered->connecting->connected->disconnecting->registered->disabling->disabled->enabling->enabled-> > and so on.. > > > > Short log is below followed with detailed log for “bearer 6”. I had to > stop modemmanager to stop this cycle > > > > Please note the problem does not happen if iptype is ‘ipv4’; this happens > when iptype is set to ‘any’ > > Could you run MM in debug mode, and get logs when using "any" and when using "ipv4" separately? Please attach full logs as separate attachments, because browsing an extremely long email body to find anything is very difficult :) -- Aleksander https://aleksander.es Nov 15 04:07:34 OpenWrt [7005]: [1573790854.136468] Modem is currently registered in a 3GPP network Nov 15 04:07:34 OpenWrt [7005]: [1573790854.136801] Simple connect state (6/8): Bearer Nov 15 04:07:34 OpenWrt [7005]: [1573790854.137139] Creating new bearer... Nov 15 04:07:34 OpenWrt [7005]: [1573790854.137463] Creating MBIM bearer in MBIM modem Nov 15 04:07:34 OpenWrt [7005]: [1573790854.138552] Simple connect state (7/8): Connect Nov 15 04:07:34 OpenWrt [7005]: [1573790854.138979] Connecting bearer '/org/freedesktop/ModemManager1/Bearer/6' Nov 15 04:07:34 OpenWrt [7005]: [1573790854.139388] Modem /org/freedesktop/ModemManager1/Modem/0: state changed (registered -> connecting) Nov 15 04:07:34 OpenWrt [7005]: [1573790854.140368] Launching connection with data port (net/wwan0) Nov 15 04:07:34 OpenWrt [7005]: [1573790854.140754] Activating packet service... Nov 15 04:07:34 OpenWrt [7005]: [/dev/cdc-wdm0] Sent message... <<<<<< RAW: <<<<<< length = 52 <<<<<< data = 03:00:00:00:34:00:00:00:C0:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:0A:00:00:00:01:00:00:00:04:00:00:00:00:00:00:00 Nov 15 04:07:34 OpenWrt [7005]: [/dev/cdc-wdm0] Sent message (translated)... <<<<<< Header: <<<<<< length = 52 <<<<<< type= command (0x0003) <<<<<< transaction = 192 <<<<<< Fragment header: <<<<<< total = 1 <<<<<< current = 0 <<<<<< Contents: <<<<<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) <<<<<< cid = 'packet-service' (0x000a) <<<<<< type= 'set' (0x0001) <<<<<< Fields: <<<<<< PacketServiceAction = 'attach' Nov 15 04:07:34 OpenWrt [7005]: [/dev/cdc-wdm0] Received message... >>>>>> RAW: >>>>>> length = 68 >>>>>> data = >>>>>> 03:00:00:80:44:00:00:00:BF:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:0B:00:00:00:00:00:00:00:14:00:00:00:00:00:00:00:63:00:00:00:05:00:00:00:02:00:00:00:FF:FF:FF:FF Nov 15 04:07:34 OpenWrt [7005]: [/dev/cdc-wdm0] Received message (translated)... >>>>>&g
RE: Regression regarding ip_type when updating from 1.10.4 to 1.12.0
Thanks Nick,
Leaving blank will not help:
modemmanager.proto
# ip type IPv4 is assumed if none explicitly given
[ -z "${iptype}" ] && iptype="ipv4"
Setting it to "ipv4v6" will configure it for dual stack? So how to set "
MM_BEARER_IP_FAMILY_ANY "
include/ModemManager-enums.h:
/**
* MMBearerIpFamily:
* @MM_BEARER_IP_FAMILY_NONE: None or unknown.
* @MM_BEARER_IP_FAMILY_IPV4: IPv4.
* @MM_BEARER_IP_FAMILY_IPV6: IPv6.
* @MM_BEARER_IP_FAMILY_IPV4V6: IPv4 and IPv6.
* @MM_BEARER_IP_FAMILY_ANY: Mask specifying all IP families.
*
* Type of IP family to be used in a given Bearer.
*/
typedef enum { /*< underscore_name=mm_bearer_ip_family >*/
MM_BEARER_IP_FAMILY_NONE= 0,
MM_BEARER_IP_FAMILY_IPV4= 1 << 0,
MM_BEARER_IP_FAMILY_IPV6= 1 << 1,
MM_BEARER_IP_FAMILY_IPV4V6 = 1 << 2,
MM_BEARER_IP_FAMILY_ANY = 0x
} MMBearerIpFamily;
The information in this email communication (inclusive of attachments) is
confidential to 4RF Limited and the intended recipient(s). If you are not the
intended recipient(s), please note that any use, disclosure, distribution or
copying of this information or any part thereof is strictly prohibited and that
the author accepts no liability for the consequences of any action taken on the
basis of the information provided. If you have received this email in error,
please notify the sender immediately by return email and then delete all
instances of this email from your system. 4RF Limited will not accept
responsibility for any consequences associated with the use of this email
(including, but not limited to, damages sustained as a result of any viruses
and/or any action or lack of action taken in reliance on it).-Original
Message-
From: Nick B
Sent: Friday, 15 November 2019 9:19 AM
To: Amol Lad
Cc: Andreas Fett ; modemmanager-devel@lists.freedesktop.org
Subject: Re: Regression regarding ip_type when updating from 1.10.4 to 1.12.0
I think you can just leave it blank, or you can try ipv4v6 with the latest
master
Best,
Nick
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: Regression regarding ip_type when updating from 1.10.4 to 1.12.0
Sorry for basic question. How to you set ip_type to ANY in OpenWrt conf (below). I tried : option iptype 'any' but it did not work config interface 'wwan' option device '/sys/devices/platform/soc/soc:internal-regs/f10f8000.usb3/usb5/5-1' option proto 'modemmanager' option apn 'internet' option roaming '1' option iptype 'ipv4' The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: ModemManager-devel On Behalf Of Andreas Fett Sent: Friday, 15 November 2019 3:58 AM To: modemmanager-devel@lists.freedesktop.org Subject: Re: Regression regarding ip_type when updating from 1.10.4 to 1.12.0 Hi Dan, thank you for your feedback. On Thu, Nov 14, 2019 at 03:24:35PM -0600, Dan Williams wrote: > Aleksander: we should probably fine-tune the logic something like this: > > 1) bearer default_ip_family follows what the modem is capable of via > AT+CGDCONT=? or the equivalent; eg if the modem has V4V6 contexts then > we default to IPV4V6. > 2) If the user passes a specific IP family for the bearer, fail if > that family is not successfully connected (as we do now?) > 3) If the user passes ANY: > 3a) use the default_ip_family (no change) > 3b) the modem accepts whatever connect result happens, eg if v4 or > v6-only that's fine, don't fail. > 3c) if the connection result failed because the network rejected a > V4V6 request for example, or the default_ip_family is V4 but the APN > only accepts V6, then should we retry with V4? > My concern is to get Dualstack if available and any kind of Connectivity if it's not. So I like your outline above very much and if ModemManager could guarantee that behaviour independetly of the actual modem driver I'd happily switch to pass ANY in the bearer an be done with it. Andreas -- The three chief virtues of a programmer are: Laziness, Impatience and Hubris. -- Larry Wall ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: OpenWrt package and udev rules
This rule is already in MM 1.12.0. You had to apply it separately?
root@OpenWrt:/lib/udev/rules.d# cat 77-mm-sierra.rules
# do not edit this file, it will be overwritten on update
ACTION!="add|change|move|bind", GOTO="mm_sierra_end"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="1199", GOTO="mm_sierra"
GOTO="mm_sierra_end"
LABEL="mm_sierra"
SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="?*",
ENV{.MM_USBIFNUM}="$attr{bInterfaceNumber}"
# Netgear AC341U: enable connection status polling explicitly
ATTRS{idVendor}=="1199", ATTRS{idProduct}=="9057",
ENV{ID_MM_QMI_CONNECTION_STATUS_POLLING_ENABLE}="1"
# MC74XX: Add port hints
# if 03: primary port
# if 02: raw NMEA port
# if 00: diag/qcdm port
ATTRS{idVendor}=="1199", ATTRS{idProduct}=="9071", ENV{.MM_USBIFNUM}=="03",
ENV{ID_MM_PORT_TYPE_AT_PRIMARY}="1"
ATTRS{idVendor}=="1199", ATTRS{idProduct}=="9071", ENV{.MM_USBIFNUM}=="02",
ENV{ID_MM_PORT_TYPE_GPS}="1"
ATTRS{idVendor}=="1199", ATTRS{idProduct}=="9071", ENV{.MM_USBIFNUM}=="00",
ENV{ID_MM_PORT_TYPE_QCDM}="1"
LABEL="mm_sierra_end"
From: ModemManager-devel On
Behalf Of Nick B
Sent: Friday, 15 November 2019 5:14 AM
To: Bjørn Mork
Cc: ModemManager (development) ;
Aleksander Morgado
Subject: Re: OpenWrt package and udev rules
Hey,
FWIW, updating these rules definitely sped up the configuration of my MC7430 on
OpenWrt by about 20 to 30 seconds. See:
https://www.mail-archive.com/modemmanager-devel@lists.freedesktop.org/msg05430.html
Best,
Nick
The information in this email communication (inclusive of attachments) is
confidential to 4RF Limited and the intended recipient(s). If you are not the
intended recipient(s), please note that any use, disclosure, distribution or
copying of this information or any part thereof is strictly prohibited and that
the author accepts no liability for the consequences of any action taken on the
basis of the information provided. If you have received this email in error,
please notify the sender immediately by return email and then delete all
instances of this email from your system. 4RF Limited will not accept
responsibility for any consequences associated with the use of this email
(including, but not limited to, damages sustained as a result of any viruses
and/or any action or lack of action taken in reliance on it).
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: Issues with IPv4v6 and IPv6 on openwrt with a Quectel EG06-E
Hi Aleksander,
Is this behaviour ("NoEffect" error) specific to Quectel EG06-E modem or you
think it's a general issue across all modems?
I would really love to test your changes but have no APN with IPv6 support ☹
Amol
The information in this email communication (inclusive of attachments) is
confidential to 4RF Limited and the intended recipient(s). If you are not the
intended recipient(s), please note that any use, disclosure, distribution or
copying of this information or any part thereof is strictly prohibited and that
the author accepts no liability for the consequences of any action taken on the
basis of the information provided. If you have received this email in error,
please notify the sender immediately by return email and then delete all
instances of this email from your system. 4RF Limited will not accept
responsibility for any consequences associated with the use of this email
(including, but not limited to, damages sustained as a result of any viruses
and/or any action or lack of action taken in reliance on it).-Original
Message-
From: ModemManager-devel On
Behalf Of Aleksander Morgado
Sent: Thursday, 7 November 2019 10:22 PM
To: Thomas Schäfer ; Bjørn Mork
Cc: Dan Williams ; ModemManager (development)
; libqmi (development)
; Nick B
Subject: Issues with IPv4v6 and IPv6 on openwrt with a Quectel EG06-E
Hey Thomas, Bjørn and all,
I'm trying to test IPv4v6 and IPv6 using a Quectel EG06-E, which runs in QMI
mode. This is in OpenWRT, using this branch that I'm working
on:
https://github.com/aleksander0m/openwrt-packages/commit/b5805c3e1d2965662d2fe16aa80140a242339abd
(BTW, any additional test with that branch would be very welcome)
When I fire up the connection through ModemManager, the logic will create
separate WDS clients for the IPv4 and IPv6 "start network"
commands (only one IPv6 client in case of IPv6 only).
What I see in the logs is that the "start network" command for the
IPv4 part works successfully, but the one for the IPv6 part returns a
"NoEffect" error.
<< QMUX:
<< length = 26
<< flags = 0x80
<< service = "wds"
<< client = 20
<< QMI:
<< flags = "response"
<< transaction = 3
<< tlv_length = 14
<< message = "Start Network" (0x0020)
<< TLV:
<< type = "Result" (0x02)
<< length = 4
<< value = 01:00:1A:00
<< translated = FAILURE: NoEffect
In the logic of MM, a "NoEffect" error is treated as no error, so the logic
goes on and tries to "WDS Get Current Settings" with the IPv6 client, and that
one fails with an OutOfCall error.
<< QMUX:
<< length = 19
<< flags = 0x80
<< service = "wds"
<< client = 20
<< QMI:
<< flags = "response"
<< transaction = 4
<< tlv_length = 7
<< message = "Get Current Settings" (0x002D)
<< TLV:
<< type = "Result" (0x02)
<< length = 4
<< value = 01:00:0F:00
<< translated = FAILURE: OutOfCall
Does anyone have any idea what could be happening here?
These tests are using the "data.tre.dk" APN in Denmark.
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: mmcli 3gpp network scan
mbimcli actually shows more detailed output but it also has got RSSI and Error Rate field incorrect... [/dev/cdc-wdm0] Visible providers (6): Provider [0]: Provider ID: '405861' Provider name: 'Jio 4G' State: 'home, preferred, visible, registered' Cellular class: 'gsm' RSSI: '99' Error rate: '99' Provider [1]: Provider ID: '40445' Provider name: 'IND airtel' State: 'forbidden, visible' Cellular class: 'gsm' RSSI: '99' Error rate: '99' Provider [2]: Provider ID: '40486' Provider name: 'Vodafone IN' State: 'forbidden, visible' Cellular class: 'gsm' RSSI: '99' Error rate: '99' Provider [3]: Provider ID: '40510' Provider name: '405 10' State: 'forbidden, visible' Cellular class: 'gsm' RSSI: '99' Error rate: '99' Provider [4]: Provider ID: '40471' Provider name: 'CellOne' State: 'forbidden, visible' Cellular class: 'gsm' RSSI: '99' Error rate: '99' Provider [5]: Provider ID: '404999' Provider name: '404 999' State: 'forbidden, visible' Cellular class: 'gsm' RSSI: '99' Error rate: '99' The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: Aleksander Morgado Sent: Thursday, 10 October 2019 2:05 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: mmcli 3gpp network scan Hey, > > I’m using almost the latest modemmanager from master (commit hash: > 0a85254d1765db6e55770d36e24b1e6349e789f4). When starting network scan using > mmcli, the availability field is always “unknown” whereas for qmicli the > “Status” is reported with more details. Please advise if this is desired > behaviour in mmcli output? > I recall this being a limitation of the "MBIM Query Visible Providers" implementation in some modules, which is what ModemManager does when the modem is managed in MBIM mode. You can see qmicli providing better data because it's doing "QMI NAS Network Scan" over MBIM instead. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: “bytes-rx” and “bytes-tx” statistics are not getting populated
Yes, my default route is through modem only and in fact below is qmicli output root@OpenWrt:/# qmicli -d /dev/cdc-wdm0 -p --wds-get-packet-statistics [/dev/cdc-wdm0] Connection statistics: TX packets OK: 97 RX packets OK: 87 TX packets dropped: 0 RX packets dropped: 0 TX bytes OK: 6271 RX bytes OK: 9891 When I switched modem back to QMI mode then these stats are reported in mmcli. Again some problem with MBIM support in the modem? The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: Aleksander Morgado Sent: Thursday, 10 October 2019 4:09 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: “bytes-rx” and “bytes-tx” statistics are not getting populated Hey, > Oct 10 09:23:13 OpenWrt [6904]: [/dev/cdc-wdm0] Received message > (translated)... > >>>>>> Header: > >>>>>> length = 96 > >>>>>> type= command-done (0x8003) > >>>>>> transaction = 37 > >>>>>> Fragment header: > >>>>>> total = 1 > >>>>>> current = 0 > >>>>>> Contents: > >>>>>> status error = 'None' (0x) > >>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) > >>>>>> cid = 'packet-statistics' (0x0014) > >>>>>> Fields: > >>>>>> InDiscards = '0' > >>>>>> InErrors = '0' > >>>>>> InOctets = '0' > >>>>>> InPackets = '0' > >>>>>> OutOctets = '0' > >>>>>> OutPackets = '0' > >>>>>> OutErrors = '0' > >>>>>> OutDiscards = '0' The modem is reporting 0 bytes RX/TX, so that's where the problem is. Are you sure you're using the modem connection as default route? -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: “bytes-rx” and “bytes-tx” statistics are not getting populated
t;> length = 96 >>>>>> data = >>>>>> 03:00:00:80:60:00:00:00:2A:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:14:00:00:00:00:00:00:00:30:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 Oct 10 09:25:43 OpenWrt [6904]: [/dev/cdc-wdm0] Received message (translated)... >>>>>> Header: >>>>>> length = 96 >>>>>> type= command-done (0x8003) >>>>>> transaction = 42 >>>>>> Fragment header: >>>>>> total = 1 >>>>>> current = 0 >>>>>> Contents: >>>>>> status error = 'None' (0x) >>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) >>>>>> cid = 'packet-statistics' (0x0014) >>>>>> Fields: >>>>>> InDiscards = '0' >>>>>> InErrors = '0' >>>>>> InOctets = '0' >>>>>> InPackets = '0' >>>>>> OutOctets = '0' >>>>>> OutPackets = '0' >>>>>> OutErrors = '0' >>>>>> OutDiscards = '0' Oct 10 09:26:13 OpenWrt [6904]: [/dev/cdc-wdm0] Sent message... <<<<<< RAW: <<<<<< length = 48 <<<<<< data = 03:00:00:00:30:00:00:00:2B:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:14:00:00:00:00:00:00:00:00:00:00:00 Oct 10 09:26:13 OpenWrt [6904]: [/dev/cdc-wdm0] Sent message (translated)... <<<<<< Header: <<<<<< length = 48 <<<<<< type= command (0x0003) <<<<<< transaction = 43 <<<<<< Fragment header: <<<<<< total = 1 <<<<<< current = 0 <<<<<< Contents: <<<<<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) <<<<<< cid = 'packet-statistics' (0x0014) <<<<<< type= 'query' (0x) Oct 10 09:26:13 OpenWrt [6904]: [/dev/cdc-wdm0] Received message... >>>>>> RAW: >>>>>> length = 96 >>>>>> data = >>>>>> 03:00:00:80:60:00:00:00:2B:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:14:00:00:00:00:00:00:00:30:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 Oct 10 09:26:13 OpenWrt [6904]: [/dev/cdc-wdm0] Received message (translated)... >>>>>> Header: >>>>>> length = 96 >>>>>> type= command-done (0x8003) >>>>>> transaction = 43 >>>>>> Fragment header: >>>>>> total = 1 >>>>>> current = 0 >>>>>> Contents: >>>>>> status error = 'None' (0x) >>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) >>>>>> cid = 'packet-statistics' (0x0014) >>>>>> Fields: >>>>>> InDiscards = '0' >>>>>> InErrors = '0' >>>>>> InOctets = '0' >>>>>> InPackets = '0' >>>>>> OutOctets = '0' >>>>>> OutPackets = '0' >>>>>> OutErrors = '0' >>>>>> OutDiscards = '0' Oct 10 09:26:17 OpenWrt [6904]: [1570699577.383770] Signal quality value not updated in 60s, marking as not being recent Oct 10 09:26:43 OpenWrt [6904]: [/dev/cdc-wdm0] Sent message... <<<<<< RAW: <<<<<< length = 48 <<<<<< data = 03:00:00:00:30:00:00:00:2C:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:14:00:00:00:00:00:00:00:00:00:00:00 Oct 10 09:26:43 OpenWrt [6904]: [/dev/cdc-wdm0] Sent message (translated)... <<<<<< Header: <<<<<< length = 48 <<<<<< type= command (0x0003) <<<<<< transaction = 44 <<<<<< Fragment header: <<<<<< total = 1 <<<<<< current = 0 <<<<<< Contents: <<<<<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) <<<<<< cid = 'packet-statistics' (0x0014) <<<<<< type= 'query' (0x) Oct 10 09:26:43 OpenWrt [6904]: [/dev/cdc-wdm0] Received message... >>>>>> RAW: >>>>>> length = 96 >>>>>> data = >>>>>> 03:00:00:80:60:00:00:00:2C:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:14:00:00:00:00:00:00:00:30:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 Oct 10 09:26:43 OpenWrt [6904]: [/dev/cdc-wdm0] Received message (translated)... >>>>>> Header: >>>>>> length = 96 >>>>>> type= command-done (0x8003) >>>>>> transaction = 44 >>>>>> Fragment header: >>>>>> total = 1 >>>>>> current = 0 >>>>>> Contents: >>>>>> status error = 'None' (0x) >>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) >>>>>> cid = 'packet-statistics' (0x0014) >>>>>> Fields: >>>>>> InDiscards = '0' >>>>>> InErrors = '0' >>>>>> InOctets = '0' >>>>>> InPackets = '0' >>>>>> OutOctets = '0' >>>>>> OutPackets = '0' >>>>>> OutErrors = '0' >>>>>> OutDiscards = '0' Oct 10 09:27:13 OpenWrt [6904]: [/dev/cdc-wdm0] Sent message... <<<<<< RAW: <<<<<< length = 48 <<<<<< data = 03:00:00:00:30:00:00:00:2D:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:14:00:00:00:00:00:00:00:00:00:00:00 Oct 10 09:27:13 OpenWrt [6904]: [/dev/cdc-wdm0] Sent message (translated)... <<<<<< Header: <<<<<< length = 48 <<<<<< type= command (0x0003) <<<<<< transaction = 45 <<<<<< Fragment header: <<<<<< total = 1 <<<<<< current = 0 <<<<<< Contents: <<<<<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) <<<<<< cid = 'packet-statistics' (0x0014) <<<<<< type= 'query' (0x) Oct 10 09:27:13 OpenWrt [6904]: [/dev/cdc-wdm0] Received message... >>>>>> RAW: >>>>>> length = 96 >>>>>> data = >>>>>> 03:00:00:80:60:00:00:00:2D:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:14:00:00:00:00:00:00:00:30:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 Oct 10 09:27:13 OpenWrt [6904]: [/dev/cdc-wdm0] Received message (translated)... >>>>>> Header: >>>>>> length = 96 >>>>>> type= command-done (0x8003) >>>>>> transaction = 45 >>>>>> Fragment header: >>>>>> total = 1 >>>>>> current = 0 >>>>>> Contents: >>>>>> status error = 'None' (0x) >>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) >>>>>> cid = 'packet-statistics' (0x0014) >>>>>> Fields: >>>>>> InDiscards = '0' >>>>>> InErrors = '0' >>>>>> InOctets = '0' >>>>>> InPackets = '0' >>>>>> OutOctets = '0' >>>>>> OutPackets = '0' >>>>>> OutErrors = '0' >>>>>> OutDiscards = '0' root@OpenWrt:/# The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: Aleksander Morgado Sent: Thursday, 10 October 2019 2:03 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: “bytes-rx” and “bytes-tx” statistics are not getting populated Hey, > I’m using almost the latest modemmanager from master (commit hash: > 0a85254d1765db6e55770d36e24b1e6349e789f4). I started noticing that the > “bytes-rx” and “bytes-tx” statistics are never getting updated even > though there is regular traffic (say ping). I’m not sure if anything > has changed in this area as I remember seeing those stats not long > back… Nothing has changed lately as far as I can tell. Please provide a debug log from ModemManager to see if we're really doing the proper "Packet Statistics Query" via MBIM. -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
mmcli 3gpp network scan
Hi, I'm using almost the latest modemmanager from master (commit hash: 0a85254d1765db6e55770d36e24b1e6349e789f4). When starting network scan using mmcli, the availability field is always "unknown" whereas for qmicli the "Status" is reported with more details. Please advise if this is desired behaviour in mmcli output? Thanks Amol root@OpenWrt:/# mmcli -m 0 --3gpp-scan - 3GPP scan | networks: 404999 - 404 999 (gprs, unknown) | 40510 - 405 10 (gprs, unknown) | 40471 - CellOne (gprs, unknown) | 40486 - Vodafone IN (gprs, unknown) | 40445 - IND airtel (gprs, unknown) | 405861 - Jio 4G (gprs, unknown) root@OpenWrt:/# qmicli -d /dev/cdc-wdm0 -p --nas-network-scan [/dev/cdc-wdm0] Successfully scanned networks Network [0]: MCC: '405' MNC: '861' Status: 'current-serving, home, not-forbidden, preferred' Description: 'Jio 4G' Network [1]: MCC: '404' MNC: '86' Status: 'available, roaming, forbidden, not-preferred' Description: 'Vodafone IN' Network [2]: MCC: '404' MNC: '71' Status: 'available, roaming, forbidden, not-preferred' Description: 'CellOne' Network [3]: MCC: '404' MNC: '45' Status: 'available, roaming, forbidden, not-preferred' Description: 'IND airtel' Network [4]: MCC: '405' MNC: '10' Status: 'available, roaming, forbidden, not-preferred' Description: '405 10' Network [5]: MCC: '404' MNC: '45' Status: 'available, roaming, forbidden, not-preferred' Description: 'IND airtel' The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
“bytes-rx” and “bytes-tx” statistics are not getting populated
Hi, I’m using almost the latest modemmanager from master (commit hash: 0a85254d1765db6e55770d36e24b1e6349e789f4). I started noticing that the “bytes-rx” and “bytes-tx” statistics are never getting updated even though there is regular traffic (say ping). I’m not sure if anything has changed in this area as I remember seeing those stats not long back… root@OpenWrt:/# mmcli -b 1 -K bearer.dbus-path: /org/freedesktop/ModemManager1/Bearer/1 bearer.type : default bearer.status.connected : yes bearer.status.suspended : no bearer.status.interface : wwan0 bearer.status.ip-timeout: 20 bearer.properties.apn : 4rf.com bearer.properties.roaming : allowed bearer.properties.ip-type : ipv4 bearer.properties.user : -- bearer.properties.password : -- bearer.properties.rm-protocol : -- bearer.ipv4-config.method : static bearer.ipv4-config.address : 25.107.237.166 bearer.ipv4-config.prefix : 30 bearer.ipv4-config.gateway : 25.107.237.165 bearer.ipv4-config.dns.length : 1 bearer.ipv4-config.dns.value[1] : 49.45.0.1 bearer.ipv4-config.mtu : 1500 bearer.ipv6-config.method : -- bearer.ipv6-config.address : -- bearer.ipv6-config.prefix : -- bearer.ipv6-config.gateway : -- bearer.ipv6-config.dns : -- bearer.ipv6-config.mtu : -- bearer.stats.duration : 240 bearer.stats.bytes-rx : -- bearer.stats.bytes-tx : -- root@OpenWrt:/# mmcli -m 0 General |dbus path: /org/freedesktop/ModemManager1/Modem/0 |device id: 1f75cd7f52f1f8d71fed0aeb735b4c9c28e3b338 Hardware | manufacturer: Sierra Wireless, Incorporated |model: Sierra Wireless EM7430 Qualcomm® Snapdragon™ X7 LTE-A |firmware revision: SWI9X30C_02.30.03.00 | carrier config: default | h/w revision: EM7430 |supported: gsm-umts, lte | current: gsm-umts, lte | equipment id: 359075062306476 System | device: /sys/devices/platform/soc/soc:internal-regs/f10f8000.usb3/usb5/5-1 | drivers: cdc_mbim, qcserial | plugin: Sierra | primary port: cdc-wdm0 |ports: ttyUSB0 (qcdm), ttyUSB1 (gps), ttyUSB2 (at), | cdc-wdm0 (mbim), wwan0 (net) Numbers | own: 918660286965 Status | unlock retries: sim-pin2 (3) |state: connected | power state: on | access tech: lte | signal quality: 16% (recent) Modes|supported: allowed: 3g; preferred: none | allowed: 4g; preferred: none | allowed: 3g, 4g; preferred: 3g | allowed: 3g, 4g; preferred: 4g | current: allowed: 3g, 4g; preferred: 4g Bands|supported: utran-1, utran-6, utran-5, utran-8, utran-9, eutran-1, | eutran-3, eutran-5, eutran-7, eutran-8, eutran-18, eutran-19, | eutran-21, eutran-28, eutran-38, eutran-39, eutran-40, eutran-41, | utran-19 | current: utran-1, utran-6, utran-5, utran-8, utran-9, eutran-1, | eutran-3, eutran-5, eutran-7, eutran-8, eutran-18, eutran-19, | eutran-21, eutran-28, eutran-38, eutran-39, eutran-40, eutran-41, | utran-19 IP |supported: ipv4, ipv6, ipv4v6 3GPP | imei: 359075062306476 |enabled locks: fixed-dialing | operator id: 405861 |operator name: Jio 4G | registration: home 3GPP EPS | ue mode of operation: csps-2 SIM |dbus path: /org/freedesktop/ModemManager1/SIM/0 Bearer |dbus path: /org/freedesktop/ModemManager1/Bearer/1 The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is
Dual SIM support in Sierra EM7455/7430
Hi, Sierra EM7455/7430 provide support for dual SIM cards. Current sim can be found out using AT!UIMS? at command. This will return "0" or "1" depending on which sim is active. Similarly, SIM 0 can be made active using AT!UIMS=0 and SIM 1 using AT!UIMS=1. Now how to achieve this SIM switching using modemmanager? If this support is not there then what needs to be done to add this support? Amol The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: modemmanager/qmicli openwrt feed update
Hi Nick,
When do you think the merge will be done?
Amol
From: Nick B
Sent: Monday, 9 September 2019 6:02 PM
To: Aleksander Morgado
Cc: Amol Lad ; ModemManager (development)
Subject: Re: modemmanager/qmicli openwrt feed update
Hey everyone!
The final missing piece before a merge might be making sure the scripts pass
Shellcheck, which, if you don’t know, ensures the script is POSIX compliant. I
have started on that work in my Shellcheck branch linked below. If anyone
would like to test, I think the modemmanager.common file is done, but
modemmanager.proto might be ready tomorrow. I could only test it on OpenWrt,
which uses the Almquist shell. Tested by stopping/starting MM, rebooting,
debug mode, and reading the logread output.
Code
https://github.com/nickberry17/packages-1/tree/shellcheck/net/modemmanager/files
A couple of questions:
Does this variable need to be used by another file?
In modemmanager.common line 14:
MODEMMANAGER_PID_FILE="${MODEMMANAGER_RUNDIR}/modemmanager.pid"
^-- SC2034: MODEMMANAGER_PID_FILE appears unused. Verify it or export it.
Is the expected behaviour to only apply permissions on the deepest directory?
25-modemmanager-tty has the same.
In 25-modemmanager-net line 12:
mkdir -m 0755 -p "${MODEMMANAGER_RUNDIR}"
^-- SC2174: When used with -p, -m only applies to the deepest directory.
Best,
Nick
The information in this email communication (inclusive of attachments) is
confidential to 4RF Limited and the intended recipient(s). If you are not the
intended recipient(s), please note that any use, disclosure, distribution or
copying of this information or any part thereof is strictly prohibited and that
the author accepts no liability for the consequences of any action taken on the
basis of the information provided. If you have received this email in error,
please notify the sender immediately by return email and then delete all
instances of this email from your system. 4RF Limited will not accept
responsibility for any consequences associated with the use of this email
(including, but not limited to, damages sustained as a result of any viruses
and/or any action or lack of action taken in reliance on it).
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: [PATCH] Include minutes in SMS timezone field
Hi Akeksander, Your proposal seems reasonable. Please find below merge request for review: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/merge_requests/172 Thanks Amol The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: Aleksander Morgado Sent: Thursday, 19 September 2019 1:16 PM To: Amol Lad Cc: ModemManager (development) Subject: Re: [PATCH] Include minutes in SMS timezone field Hey, > Comment in libmm-glib/mm-sms.c :mm_sms_get_timestamp() states that the time > returned is ISO8601 complaint. However, ISO8601 mandates that year must be in > format and not just YY. What we are showing in timestamp field is > YYMMDDHHMMSS+ZZ. This is more in-line with the 7 octet timestamp received in > SMS PDU and also shown using AT Command: > > AT+CMGR=1 > +CMGR: "REC UNREAD","+85291234567",,"07/02/18,00:05:10+32" > > OK > > Now, we cannot do as SMS PDU only has YY. > I don't think there will be many stored SMS from last century, so let's assume that if we get only a 2-digit year value, we can prepend "20" to that value to get the 4-digit year value. > More important, you will notice in above AT command output that the > timezone is "+32" which is actually "Quarters" and not "Hours" as MM > is showing now > > So we've below ways to fix this: > > 1) change sms_decode_timestamp() to populate +ZZ as "quarters" and not > "hours". This then becomes in-line with AT command reporting. > 2) change format to YYMMDDHHMMSS+HHMM > > So what is the preference? > Let's do ISO8601 in long format (with field separators), which is really readable, what do you think? e.g. 2019-09-19T09:45:00+0200 Cheers! -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
modemmanager.proto issue?
Hi Aleksander,
Regarding modemmanager.proto file @
https://gitlab.freedesktop.org/mobile-broadband/mobile-broadband-openwrt/blob/master/modemmanager/files/modemmanager.proto
Did you mean "while [ $idx -le $bearercount ];" in below function instead of "
while [ $idx -ge $bearercount ];" ?
modemmanager_cleanup_connection() {
local modemstatus="$1"
local bearercount idx bearerpath
bearercount=$(modemmanager_get_field "${modemstatus}"
"modem.generic.bearers.length")
# do nothing if no bearers reported
[ -n "${bearercount}" ] && [ $bearercount -ge 1 ] && {
# explicitly disconnect just in case
/usr/bin/mmcli --modem="${device}" --simple-disconnect >/dev/null 2>&1
# and remove all bearer objects, if any found
idx=1
while [ $idx -ge $bearercount ]; do
bearerpath=$(modemmanager_get_field "${modemstatus}"
"modem.generic.bearers.value\[$idx\]")
/usr/bin/mmcli --modem "${device}" --delete-bearer="${bearerpath}" >/dev/null
2>&1
idx=$(expr $idx + 1)
done
}
}
Thanks
Amol
The information in this email communication (inclusive of attachments) is
confidential to 4RF Limited and the intended recipient(s). If you are not the
intended recipient(s), please note that any use, disclosure, distribution or
copying of this information or any part thereof is strictly prohibited and that
the author accepts no liability for the consequences of any action taken on the
basis of the information provided. If you have received this email in error,
please notify the sender immediately by return email and then delete all
instances of this email from your system. 4RF Limited will not accept
responsibility for any consequences associated with the use of this email
(including, but not limited to, damages sustained as a result of any viruses
and/or any action or lack of action taken in reliance on it).
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
[PATCH] Support allow-roaming property in openwrt protocol handler
Hi,
Below patch allows user to configure roaming in /etc/config/network along with
other parameters such as apn. This patch is generated from Mobile Broadband
OpenWRT git
(https://gitlab.freedesktop.org/mobile-broadband/mobile-broadband-openwrt).
I've tested it in my EM7455 setup.
Thanks
Amol
>From 179492c83db02011cdd57f41e03ebe9dab204cdf Mon Sep 17 00:00:00 2001
From: "amol.lad"
Date: Thu, 12 Sep 2019 11:45:30 +0530
Subject: [PATCH] support allow-roaming property in openwrt protocol handler
---
README| 1 +
modemmanager/files/modemmanager.proto | 7 ---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/README b/README
index 04feff0..0883a94 100644
--- a/README
+++ b/README
@@ -42,3 +42,4 @@ Install it in the following way:
option password 'vodafone'
option pincode '7423'
option lowpower '1'
+option roaming '0'
diff --git a/modemmanager/files/modemmanager.proto
b/modemmanager/files/modemmanager.proto
index 00a4278..71769f1 100755
--- a/modemmanager/files/modemmanager.proto
+++ b/modemmanager/files/modemmanager.proto
@@ -246,6 +246,7 @@ proto_modemmanager_init_config() {
proto_config_add_string pincode
proto_config_add_string iptype
proto_config_add_boolean lowpower
+ proto_config_add_boolean roaming
}
proto_modemmanager_setup() {
@@ -254,8 +255,8 @@ proto_modemmanager_setup() {
local modempath modemstatus bearercount bearerpath connectargs
bearerstatus beareriface method
local operatorname operatorid registration accesstech
signalquality
- local device apn username password pincode iptype metric
- json_get_vars device apn username password pincode iptype metric
+ local device apn username password pincode iptype roaming metric
+ json_get_vars device apn username password pincode iptype roaming
metric
# validate sysfs path given in config
[ -n "${device}" ] || {
@@ -286,7 +287,7 @@ proto_modemmanager_setup() {
# setup connect args; APN mandatory (even if it may be empty)
echo "starting connection with apn '${apn}'..."
-
connectargs="apn=${apn}${username:+,user=${username}}${password:+,password=${password}}${pincode:+,pin=${pincode}}${iptype:+,ip-type=${iptype}}"
+
connectargs="apn=${apn}${username:+,user=${username}}${password:+,password=${password}}${pincode:+,pin=${pincode}}${iptype:+,ip-type=${iptype}}${roaming:+,allow-roaming=${roaming}}"
/usr/bin/mmcli --modem="${device}" --timeout 120
--simple-connect="${connectargs}" || {
proto_notify_error "${interface}" CONNECT_FAILED
proto_block_restart "${interface}"
--
2.17.1
The information in this email communication (inclusive of attachments) is
confidential to 4RF Limited and the intended recipient(s). If you are not the
intended recipient(s), please note that any use, disclosure, distribution or
copying of this information or any part thereof is strictly prohibited and that
the author accepts no liability for the consequences of any action taken on the
basis of the information provided. If you have received this email in error,
please notify the sender immediately by return email and then delete all
instances of this email from your system. 4RF Limited will not accept
responsibility for any consequences associated with the use of this email
(including, but not limited to, damages sustained as a result of any viruses
and/or any action or lack of action taken in reliance on it).
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
modemmanager/qmicli openwrt feed update
Hi Aleksander, If you consider this ok, then can you please update the modemmanager and qmicli to the latest release in openwrt feed? They are currently at 1.10.0 and 1.22.4 respectively. Thanks Amol The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: Resetting Bearer on OpenWRT
Hi Enrico, Can you please share what you did to address this? I think this is very much desired enhancement especially when the signal is not that great and there and frequent disconnections/reconnections occurring. Thanks Amol The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: ModemManager-devel On Behalf Of Enrico Mioso Sent: Sunday, 8 September 2019 12:55 PM To: Aleksander Morgado Cc: ModemManager (development) ; James Hilliard Subject: Re: Resetting Bearer on OpenWRT Hi! On Sun, 8 Sep 2019, Aleksander Morgado wrote: > Absolutely no idea, because I don't know how netifd expects that to be > reported or how it does connection monitoring. Any info on how that > works would be appreciated. I admit I didn't follow the entire discussion from the beginning, so sorry for the noise in case what I am telling is useless. From my unerstanding, anyone please correct me if I am wrong, lots of relevant code is in OpenWRt's netifd-proto.sh. From my understanding, netifd expects to be informed by protocol handlers about when things change, especially because in this case the network interface wouldn't change it's state apparently. So, as righly pointed out by you, MM may directly emit ubus events simulating what a protocol handler does, or it may invoke a shell script carrying out that task, keeping the state consistent. This is what I did in AGH - I am not saying it's the best solution, but that's the route I choose. Enrico ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
mmcli not listing firmware images from modem
Hi, I'm using Solidrun's clearfog-base plarform with Sierra Wireless EM7430 LTE chipset. I'm running OpenWRT 18.06 with ModemManager feed from https://gitlab.freedesktop.org/mobile-broadband/mobile-broadband-openwrt mmcli is not reporting stored firmware images but same can be retrieved using qmicli. Can you please advise what is going wrong? root@OpenWrt:/# mmcli -m 0 --firmware-list Firmware | list: n/a root@OpenWrt:/# mmcli -m 0 --firmware-status error: firmware status unsupported root@OpenWrt:/# qmicli -d /dev/cdc-wdm0 -p --dms-list-firmware-images error: Unknown option --dms-list-firmware-images root@OpenWrt:/# qmicli -d /dev/cdc-wdm0 -p --dms-list-stored-images [/dev/cdc-wdm0] Device list of stored images retrieved: [0] Type:'modem' Maximum: '4' [modem0] Unique ID: '?_?' Build ID: '02.23.00.00_?' Storage index: '1' Failure count: '0' >> [CURRENT] << [modem1] Unique ID: '?_?' Build ID: '02.20.03.01_?' Storage index: '2' Failure count: '0' [modem2] Unique ID: '?_?' Build ID: '02.20.03.00_?' Storage index: '3' Failure count: '0' [1] Type:'pri' Maximum: '50' [pri0] Unique ID: '001.001_000' Build ID: '02.20.03.00_DOCOMO' >> [CURRENT] << [pri1] Unique ID: '002.018_000' Build ID: '02.23.00.00_GENERIC' [pri2] Unique ID: '000.008_000' Build ID: '02.20.03.00_KDDI' [pri3] Unique ID: '000.007_000' Build ID: '02.20.03.00_Softbank' [pri4] Unique ID: '002.019_001' Build ID: '02.20.03.01_TELSTRA' Thanks Amol The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it). ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: Modemmanager significant startup delay
Same here. Paul's rules brought the ModemManager start-up delay to almost nil! The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-Original Message- From: Nick Sent: Monday, 26 August 2019 3:47 AM To: Aleksander Morgado Cc: Paul Bartell ; modemmanager-devel@lists.freedesktop.org; Amol Lad Subject: Re: Modemmanager significant startup delay Hey, FWIW, Testing Paul’s rules on my MC7430 and ModemManager starts up the connection noticeably faster, shaves off about 20 seconds for me. I haven’t cleaned up the rules per Aleksander’s suggestions yet. Best, Nick ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
RE: Modemmanager significant startup delay
Please help with this. What could be the cause of significant MM startup delay? From: ModemManager-devel On Behalf Of Amol Lad Sent: Monday, 19 August 2019 4:05 PM To: modemmanager-devel@lists.freedesktop.org Subject: Modemmanager significant startup delay Hi, I'm using Solidrun's clearfog-base plarform with Sierra Wireless EM7430 LTE chipset. I'm running OpenWRT 18.06 with ModemManager feed from https://gitlab.freedesktop.org/mobile-broadband/mobile-broadband-openwrt It is taking around 20 seconds for modemanager to bring up the LTE IP interface (i.e. after around 20 seconds 'wwan1' interface is up and I can ping external world). With uqmi the interface comes up instantly. Please refer to below logs (captured in -debug mode). It seems most of this delay is because of "serial command timeout". As you can see from the last time "[plugin manager] task 0: finished in '17.149826' seconds " Please advise what is going wrong. ... Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.535657] (ttyUSB2): <-- '' Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.535956] (ttyUSB2): <-- 'OK' Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536110] (tty/ttyUSB2) port is AT-capable Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536188] [plugin manager] task 0,ttyUSB2: found best plugin for port (Sierra) Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536269] [plugin manager] task 0,ttyUSB2: finished in '1.604063' seconds Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536348] [plugin manager] task 0,ttyUSB2: best plugin matches device reported one: Sierra Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536433] [plugin Manager] task 0: still 2 running probes (2 active): ttyUSB1, ttyUSB0 Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536565] (ttyUSB2) device open count is 0 (close) Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536702] (ttyUSB2) closing port... Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.537143] (ttyUSB2) serial port closed Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.537304] (ttyUSB2) forced to close port Mon Aug 19 10:11:06 2019 daemon.debug [2086]: [1566209466.220126] [plugin manager] task 0: min probing time elapsed Mon Aug 19 10:11:06 2019 daemon.debug [2086]: [1566209466.220187] [plugin Manager] task 0: still 2 running probes (2 active): ttyUSB1, ttyUSB0 Mon Aug 19 10:11:08 2019 daemon.debug [2086]: [1566209468.868113] Parsing AT got: 'Serial command timed out' Mon Aug 19 10:11:08 2019 daemon.debug [2086]: [1566209468.868197] Parsing AT got: 'Serial command timed out' Mon Aug 19 10:11:08 2019 daemon.debug [2086]: [1566209468.868282] (ttyUSB1): --> 'AT' Mon Aug 19 10:11:08 2019 daemon.debug [2086]: [1566209468.868351] (ttyUSB0): --> 'AT' Mon Aug 19 10:11:11 2019 daemon.debug [2086]: [1566209471.869749] Parsing AT got: 'Serial command timed out' Mon Aug 19 10:11:11 2019 daemon.debug [2086]: [1566209471.869831] Parsing AT got: 'Serial command timed out' Mon Aug 19 10:11:11 2019 daemon.debug [2086]: [1566209471.869917] (ttyUSB1): --> 'AT' Mon Aug 19 10:11:11 2019 daemon.debug [2086]: [1566209471.869984] (ttyUSB0): --> 'AT' Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869689] Parsing AT got: 'Serial command timed out' Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869745] (tty/ttyUSB1) port is not AT-capable Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869806] Parsing AT got: 'Serial command timed out' Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869834] (tty/ttyUSB0) port is not AT-capable Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869884] (tty/ttyUSB1) probing QCDM... Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869916] (ttyUSB1) device open count is 0 (close) Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869943] (ttyUSB1) closing serial port... Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870349] (ttyUSB1) serial port closed Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870415] (ttyUSB1) forced to close port Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870517] (ttyUSB1) opening serial port... Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870779] (ttyUSB1) device open count is 1 (open) Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870851] (tty/ttyUSB0) probing QCDM... Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870886] (ttyUSB0) device open count is 0 (close) Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870913] (ttyUSB0) closing serial port... Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.871138] (ttyUSB0) serial port closed Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.871196] (ttyUSB0) forced to close port Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.
Modemmanager significant startup delay
Hi, I'm using Solidrun's clearfog-base plarform with Sierra Wireless EM7430 LTE chipset. I'm running OpenWRT 18.06 with ModemManager feed from https://gitlab.freedesktop.org/mobile-broadband/mobile-broadband-openwrt It is taking around 20 seconds for modemanager to bring up the LTE IP interface (i.e. after around 20 seconds 'wwan1' interface is up and I can ping external world). With uqmi the interface comes up instantly. Please refer to below logs (captured in -debug mode). It seems most of this delay is because of "serial command timeout". As you can see from the last time "[plugin manager] task 0: finished in '17.149826' seconds " Please advise what is going wrong. ... Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.535657] (ttyUSB2): <-- '' Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.535956] (ttyUSB2): <-- 'OK' Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536110] (tty/ttyUSB2) port is AT-capable Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536188] [plugin manager] task 0,ttyUSB2: found best plugin for port (Sierra) Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536269] [plugin manager] task 0,ttyUSB2: finished in '1.604063' seconds Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536348] [plugin manager] task 0,ttyUSB2: best plugin matches device reported one: Sierra Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536433] [plugin Manager] task 0: still 2 running probes (2 active): ttyUSB1, ttyUSB0 Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536565] (ttyUSB2) device open count is 0 (close) Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.536702] (ttyUSB2) closing port... Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.537143] (ttyUSB2) serial port closed Mon Aug 19 10:11:05 2019 daemon.debug [2086]: [1566209465.537304] (ttyUSB2) forced to close port Mon Aug 19 10:11:06 2019 daemon.debug [2086]: [1566209466.220126] [plugin manager] task 0: min probing time elapsed Mon Aug 19 10:11:06 2019 daemon.debug [2086]: [1566209466.220187] [plugin Manager] task 0: still 2 running probes (2 active): ttyUSB1, ttyUSB0 Mon Aug 19 10:11:08 2019 daemon.debug [2086]: [1566209468.868113] Parsing AT got: 'Serial command timed out' Mon Aug 19 10:11:08 2019 daemon.debug [2086]: [1566209468.868197] Parsing AT got: 'Serial command timed out' Mon Aug 19 10:11:08 2019 daemon.debug [2086]: [1566209468.868282] (ttyUSB1): --> 'AT' Mon Aug 19 10:11:08 2019 daemon.debug [2086]: [1566209468.868351] (ttyUSB0): --> 'AT' Mon Aug 19 10:11:11 2019 daemon.debug [2086]: [1566209471.869749] Parsing AT got: 'Serial command timed out' Mon Aug 19 10:11:11 2019 daemon.debug [2086]: [1566209471.869831] Parsing AT got: 'Serial command timed out' Mon Aug 19 10:11:11 2019 daemon.debug [2086]: [1566209471.869917] (ttyUSB1): --> 'AT' Mon Aug 19 10:11:11 2019 daemon.debug [2086]: [1566209471.869984] (ttyUSB0): --> 'AT' Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869689] Parsing AT got: 'Serial command timed out' Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869745] (tty/ttyUSB1) port is not AT-capable Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869806] Parsing AT got: 'Serial command timed out' Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869834] (tty/ttyUSB0) port is not AT-capable Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869884] (tty/ttyUSB1) probing QCDM... Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869916] (ttyUSB1) device open count is 0 (close) Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.869943] (ttyUSB1) closing serial port... Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870349] (ttyUSB1) serial port closed Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870415] (ttyUSB1) forced to close port Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870517] (ttyUSB1) opening serial port... Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870779] (ttyUSB1) device open count is 1 (open) Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870851] (tty/ttyUSB0) probing QCDM... Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870886] (ttyUSB0) device open count is 0 (close) Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.870913] (ttyUSB0) closing serial port... Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.871138] (ttyUSB0) serial port closed Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.871196] (ttyUSB0) forced to close port Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.871261] (ttyUSB0) opening serial port... Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.871351] (ttyUSB0) device open count is 1 (open) Mon Aug 19 10:11:14 2019 daemon.debug [2086]: [1566209474.871423] (ttyUSB1): --> 7e 00 78 f0 7e Mon Aug 19 10:11:14 2019 daemon.debug [2086]:
