From pgopanapalli at vmware.com Thu Jun 1 16:27:40 2023 From: pgopanapalli at vmware.com (Pradeep Gopanapalli) Date: Thu, 1 Jun 2023 16:27:40 +0000 Subject: Quactel RM520N firmware preferences In-Reply-To: References: Message-ID: Hello Aleksander, Did you get a chance to look into this query? Thanks, Pradeep G ________________________________ From: Pradeep Gopanapalli Sent: Tuesday, May 30, 2023 2:52 PM To: modemmanager-devel at lists.freedesktop.org ; Aleksander Morgado Subject: Quactel RM520N firmware preferences Hello Aleksander, Good morning. We are using Quactel RM520N in openwrt using ModemManager(1.16) , is there any way to select or list firmware on the module using mmcli . For eg: In EM74xx we can use IMPREF to select image for carrier like AT&T , Verizon etc. I tried following AT commands which works for SierraWireless EM modules and these commands are failing for Quactel RM520N module. >> mmcli -m a --command='AT+IMPREF?' error: command failed: 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.Unknown: Unknown error' vc-edge:~# mmcli -m a --command='AT+IMAGE?' error: command failed: 'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.Unknown: Unknown error' mmcli -m a --firmware-list ---------------- Firmware | list: n/a >> mmcli -m a Hardware | manufacturer: Quectel | model: RM520N-GL | firmware revision: RM520NGLAAR01A05M4G | carrier config: CDMAless-Verizon | carrier config revision: 0A010126 | h/w revision: 20000 | supported: gsm-umts, lte, 5gnr | current: gsm-umts, lte, 5gnr | equipment id: 868371050112446 ----------------------------------- Thanks, Pradeep G -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksandermj at chromium.org Mon Jun 5 09:25:13 2023 From: aleksandermj at chromium.org (Aleksander Morgado) Date: Mon, 5 Jun 2023 11:25:13 +0200 Subject: Quactel RM520N firmware preferences In-Reply-To: References: Message-ID: Hey Pradeep, > We are using Quactel RM520N in openwrt using ModemManager(1.16) , > is there any way to select or list firmware on the module using mmcli . > For eg: In EM74xx we can use IMPREF to select image for carrier like AT&T , > Verizon etc. I believe there is no way to do this in Quectel modules, although I may be mistaken. The support in ModemManager to list and select stored images using QMI uses generic Qualcomm operations introduced back with Gobi 3K modules, but I haven't seen any other manufacturer actively allowing to switch full firmware images via these commands, apart from Sierra. Maybe ask Quectel directly, and report back what you find! -- Aleksander From rspmn at arcor.de Mon Jun 5 13:19:51 2023 From: rspmn at arcor.de (Reinhard Speyerer) Date: Mon, 5 Jun 2023 15:19:51 +0200 Subject: Quactel RM520N firmware preferences In-Reply-To: References: Message-ID: On Mon, Jun 05, 2023 at 11:25:13AM +0200, Aleksander Morgado wrote: > Hey Pradeep, > > > We are using Quactel RM520N in openwrt using ModemManager(1.16) , > > is there any way to select or list firmware on the module using mmcli . > > For eg: In EM74xx we can use IMPREF to select image for carrier like AT&T , > > Verizon etc. > > I believe there is no way to do this in Quectel modules, although I > may be mistaken. The support in ModemManager to list and select stored Hi Aleksander, on the AT interface Quectel provides their vendor-specific AT+QMBNCFG command which has similar functionality as AT!IMPREF from Sierra Wireless. No idea whether it is also implemented for RM520N devices as I have only used it on RM500Q devices myself. @Pradeep: please refer to the RM520N AT command manual or https://forums.quectel.com/ for details. Regards, Reinhard > images using QMI uses generic Qualcomm operations introduced back with > Gobi 3K modules, but I haven't seen any other manufacturer actively > allowing to switch full firmware images via these commands, apart from > Sierra. Maybe ask Quectel directly, and report back what you find! > > -- > Aleksander From cmchen at sequans.com Fri Jun 9 08:47:36 2023 From: cmchen at sequans.com (Oakley Chen) Date: Fri, 9 Jun 2023 10:47:36 +0200 (CEST) Subject: Support Sequans LTE module Message-ID: <00d701d99aaf$098b78f0$1ca26ad0$@sequans.com> Dear Sir or Madam, I am writing to ask about add new plug-in on Modem Manager to support Sequans LTE module(https://sequans.com/products/cassiopeia-cb410l/). Please let me know your concern to add this new module into Modem Manager. I would be grateful if you could share your comment for this request. I look forward to hearing from you. Yours faithfully, Oakley Chen Sequans Engineering -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexb at meshplusplus.com Mon Jun 12 23:43:11 2023 From: alexb at meshplusplus.com (Alex Ballmer) Date: Mon, 12 Jun 2023 18:43:11 -0500 Subject: [Quectel EM160R-GL] Various commands over mbim fail with 'Invalid transition' Message-ID: <05A4F237-C4F7-4719-BFBE-723844A75CD6@meshplusplus.com> After upgrading an EM160R-GL modem via QFireHose from firmware version EM160RGLAUR02A07M4G to version EM160RGLAUR02A07M4G, almost all functions fail with ?Invalid transition?. The modem power state is listed as "power state: low? via mmcli. On the former firmware version everything was working fine. This is currently happening with modemmanager 1.18.8 using mbim via the qmi_wwan driver on openwrt with linux 4.4.60 and libmbim 1.28.4 I tried manually enabling it (in case it was FCC locked) via mbimcli --device-open-proxy --device="/dev/cdc-wdm0" --quectel-set-radio-state=on, but this also had no effect. What additional steps would I need to take to debug this? Thanks Log snippet from logread on openwrt with LOG_LEVEL set to debug: Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.095984] [modem0] user request to connect modem Mon Jun 12 22:56:55 2023 daemon.info [10700]: [1686610615.096263] [modem0] simple connect started... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.096345] [modem0] profile ID: unspecified Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.096402] [modem0] PIN: unspecified Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.096447] [modem0] operator ID: unspecified Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.096492] [modem0] allowed roaming: yes Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.096537] [modem0] APN: Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.096580] [modem0] APN type: unspecified Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.096629] [modem0] IP family: unspecified Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.096712] [modem0] allowed authentication: unspecified Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.096806] [modem0] user: unspecified Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.096866] [modem0] password: unspecified Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.096934] [modem0] multiplex: unspecified Mon Jun 12 22:56:55 2023 daemon.info [10700]: [1686610615.096982] [modem0] simple connect state (3/8): enable Mon Jun 12 22:56:55 2023 daemon.info [10700]: [1686610615.097158] [modem0] state changed (disabled -> enabling) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.097834] [modem0] skipping initialization: not first enabling Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.097907] [modem0/ttyUSB2/at] device open count is 2 (open) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.097957] [modem0/ttyUSB3/at] opening serial port... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.099048] [modem0/ttyUSB3/at] setting up baudrate: 57600 Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.099138] [modem0/ttyUSB3/at] no flow control explicitly requested for device Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.099196] [modem0/ttyUSB3/at] port attributes not fully set Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.099295] [modem0/ttyUSB3/at] device open count is 1 (open) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.099345] [modem0/ttyUSB3/at] running init sequence... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.099459] [modem0/ttyUSB0/qcdm] opening serial port... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.100476] [modem0/ttyUSB0/qcdm] device open count is 1 (open) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.100563] [modem0] flashing primary AT port before enabling... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.100721] [modem0/ttyUSB3/at] --> 'ATE0' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message... <<<<<< RAW: <<<<<< length = 48 <<<<<< data = 03:00:00:00:30:00:00:00:1D:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message (translated)... <<<<<< Header: <<<<<< length = 48 <<<<<< type = command (0x00000003) <<<<<< transaction = 29 <<<<<< Fragment header: <<<<<< total = 1 <<<<<< current = 0 <<<<<< Contents: <<<<<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) <<<<<< cid = 'radio-state' (0x00000003) <<<<<< type = 'query' (0x00000000) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.108400] [modem0/ttyUSB3/at] <-- 'OK' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message... >>>>>> RAW: >>>>>> length = 56 >>>>>> data = 03:00:00:80:38:00:00:00:1D:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message (translated)... >>>>>> Header: >>>>>> length = 56 >>>>>> type = command-done (0x80000003) >>>>>> transaction = 29 >>>>>> Fragment header: >>>>>> total = 1 >>>>>> current = 0 >>>>>> Contents: >>>>>> status error = 'None' (0x00000000) >>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) >>>>>> cid = 'radio-state' (0x00000003) >>>>>> Fields: >>>>>> HwRadioState = 'on' >>>>>> SwRadioState = 'off' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.132795] [modem0] updating power state: 'on'... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message... <<<<<< RAW: <<<<<< length = 52 <<<<<< data = 03:00:00:00:34:00:00:00:1E:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message (translated)... <<<<<< Header: <<<<<< length = 52 <<<<<< type = command (0x00000003) <<<<<< transaction = 30 <<<<<< Fragment header: <<<<<< total = 1 <<<<<< current = 0 <<<<<< Contents: <<<<<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) <<<<<< cid = 'radio-state' (0x00000003) <<<<<< type = 'set' (0x00000001) <<<<<< Fields: <<<<<< RadioState = 'on' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message... >>>>>> RAW: >>>>>> length = 48 >>>>>> data = 03:00:00:80:30:00:00:00:1E:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message (translated)... >>>>>> Header: >>>>>> length = 48 >>>>>> type = command-done (0x80000003) >>>>>> transaction = 30 >>>>>> Fragment header: >>>>>> total = 1 >>>>>> current = 0 >>>>>> Contents: >>>>>> status error = 'OperationNotAllowed' (0x0000001c) >>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) >>>>>> cid = 'radio-state' (0x00000003) Mon Jun 12 22:56:55 2023 daemon.warn [10700]: [1686610615.164856] [modem0] OperationNotAllowed Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.164931] [modem0] couldn't update power state: Invalid transition Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.165016] [modem0] attempting fcc unlock... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.165232] [fcc unlock dispatcher] Cannot run fcc unlock operation from /etc/ModemManager/fcc-unlock.d/2c7c:0620: file doesn't exist Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.165357] [fcc unlock dispatcher] Cannot run fcc unlock operation from /usr/lib/ModemManager/fcc-unlock.d/2c7c:0620: file doesn't exist Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.165509] [modem0] couldn't run FCC unlock: fcc unlock operation launch aborted: no valid program found Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.165560] [modem0] updating power state: 'on'... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message... <<<<<< RAW: <<<<<< length = 52 <<<<<< data = 03:00:00:00:34:00:00:00:1F:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message (translated)... <<<<<< Header: <<<<<< length = 52 <<<<<< type = command (0x00000003) <<<<<< transaction = 31 <<<<<< Fragment header: <<<<<< total = 1 <<<<<< current = 0 <<<<<< Contents: <<<<<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) <<<<<< cid = 'radio-state' (0x00000003) <<<<<< type = 'set' (0x00000001) <<<<<< Fields: <<<<<< RadioState = 'on' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message... >>>>>> RAW: >>>>>> length = 48 >>>>>> data = 03:00:00:80:30:00:00:00:1F:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message (translated)... >>>>>> Header: >>>>>> length = 48 >>>>>> type = command-done (0x80000003) >>>>>> transaction = 31 >>>>>> Fragment header: >>>>>> total = 1 >>>>>> current = 0 >>>>>> Contents: >>>>>> status error = 'OperationNotAllowed' (0x0000001c) >>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) >>>>>> cid = 'radio-state' (0x00000003) Mon Jun 12 22:56:55 2023 daemon.warn [10700]: [1686610615.196716] [modem0] OperationNotAllowed Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.196776] [modem0] couldn't update power state: Invalid transition Mon Jun 12 22:56:55 2023 daemon.warn [10700]: [1686610615.196831] [modem0] couldn't enable interface: 'Invalid transition' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.196876] [modem0] running implicit disable after failed enable... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.196935] [modem0] modem has voice capabilities, disabling the Voice interface... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.197011] [modem0] disabling +CLIP calling line reporting in primary port... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.197085] [modem0/ttyUSB2/at] device open count is 3 (open) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.197288] [modem0/ttyUSB2/at] --> 'AT+CLIP=0' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.209424] [modem0/ttyUSB2/at] <-- 'OK' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.209605] [modem0] disabling +CLIP calling line reporting in secondary port... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.209683] [modem0/ttyUSB3/at] device open count is 2 (open) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.209765] [modem0/ttyUSB2/at] device open count is 2 (close) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.209850] [modem0/ttyUSB3/at] --> 'AT+CLIP=0' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.221910] [modem0/ttyUSB3/at] <-- 'OK' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.222093] [modem0] disabling +CRC extended format of incoming call indications in primary port... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.222177] [modem0/ttyUSB2/at] device open count is 3 (open) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.222260] [modem0/ttyUSB3/at] device open count is 1 (close) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.222347] [modem0/ttyUSB2/at] --> 'AT+CRC=0' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.233244] [modem0/ttyUSB2/at] <-- 'OK' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.233457] [modem0] disabling +CRC extended format of incoming call indications in secondary port... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.233536] [modem0/ttyUSB3/at] device open count is 2 (open) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.233616] [modem0/ttyUSB2/at] device open count is 2 (close) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.233706] [modem0/ttyUSB3/at] --> 'AT+CRC=0' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.244421] [modem0/ttyUSB3/at] <-- 'OK' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.244592] [modem0] disabling +CCWA call waiting indications in primary port... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.244672] [modem0/ttyUSB2/at] device open count is 3 (open) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.244752] [modem0/ttyUSB3/at] device open count is 1 (close) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.244841] [modem0/ttyUSB2/at] --> 'AT+CCWA=0' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.255967] [modem0/ttyUSB2/at] <-- 'OK' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.256118] [modem0] disabling +CCWA call waiting indications in secondary port... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.256194] [modem0/ttyUSB3/at] device open count is 2 (open) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.256273] [modem0/ttyUSB2/at] device open count is 2 (close) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.256371] [modem0/ttyUSB3/at] --> 'AT+CCWA=0' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.267694] [modem0/ttyUSB3/at] <-- 'OK' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.268014] [modem0] removing voice unsolicited events handlers in ttyUSB2 Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.268081] [modem0] removing voice unsolicited events handlers in ttyUSB3 Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.268177] [modem0/ttyUSB3/at] device open count is 1 (close) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.268268] [modem0] modem has extended signal reporting capabilities, disabling the Signal interface... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.268464] [modem0] modem has time capabilities, disabling the Time interface... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.268558] [modem0] modem has messaging capabilities, disabling the Messaging interface... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.268628] [modem0] enabled 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) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message... <<<<<< RAW: <<<<<< length = 52 <<<<<< data = 03:00:00:00:34:00:00:00:20:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message (translated)... <<<<<< Header: <<<<<< length = 52 <<<<<< type = command (0x00000003) <<<<<< transaction = 32 <<<<<< Fragment header: <<<<<< total = 1 <<<<<< current = 0 <<<<<< Contents: <<<<<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) <<<<<< cid = 'device-service-subscribe-list' (0x00000013) <<<<<< type = 'set' (0x00000001) <<<<<< Fields: <<<<<< EventsCount = '0' <<<<<< Events = '{ <<<<<< }' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message... >>>>>> RAW: >>>>>> length = 52 >>>>>> data = 03:00:00:80:34:00:00:00:20:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message (translated)... >>>>>> Header: >>>>>> length = 52 >>>>>> type = command-done (0x80000003) >>>>>> transaction = 32 >>>>>> Fragment header: >>>>>> total = 1 >>>>>> current = 0 >>>>>> Contents: >>>>>> status error = 'None' (0x00000000) >>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) >>>>>> cid = 'device-service-subscribe-list' (0x00000013) >>>>>> Fields: >>>>>> EventsCount = '0' >>>>>> Events = '{ >>>>>> }' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.269513] [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) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.269651] [modem0] modem has location capabilities, disabling the Location interface... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.269733] [modem0] location '3gpp-lac-ci' gathering is already disabled... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.269783] [modem0] location 'gps-raw' gathering is already disabled... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.269831] [modem0] location 'gps-nmea' gathering is already disabled... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.269884] [modem0] location 'agps-msa' gathering is already disabled... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.269932] [modem0] location 'agps-msb' gathering is already disabled... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.270052] [modem0] modem has 3GPP/USSD capabilities, disabling the Modem 3GPP/USSD interface... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.270121] [modem0] enabled 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) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message... <<<<<< RAW: <<<<<< length = 52 <<<<<< data = 03:00:00:00:34:00:00:00:21:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message (translated)... <<<<<< Header: <<<<<< length = 52 <<<<<< type = command (0x00000003) <<<<<< transaction = 33 <<<<<< Fragment header: <<<<<< total = 1 <<<<<< current = 0 <<<<<< Contents: <<<<<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) <<<<<< cid = 'device-service-subscribe-list' (0x00000013) <<<<<< type = 'set' (0x00000001) <<<<<< Fields: <<<<<< EventsCount = '0' <<<<<< Events = '{ <<<<<< }' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message... >>>>>> RAW: >>>>>> length = 52 >>>>>> data = 03:00:00:80:34:00:00:00:21:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message (translated)... >>>>>> Header: >>>>>> length = 52 >>>>>> type = command-done (0x80000003) >>>>>> transaction = 33 >>>>>> Fragment header: >>>>>> total = 1 >>>>>> current = 0 >>>>>> Contents: >>>>>> status error = 'None' (0x00000000) >>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) >>>>>> cid = 'device-service-subscribe-list' (0x00000013) >>>>>> Fields: >>>>>> EventsCount = '0' >>>>>> Events = '{ >>>>>> }' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.270938] [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) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.271073] [modem0] modem has 3GPP profile management capabilities, disabling the Modem 3GPP Profile Manager interface... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.271139] [modem0] enabled 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) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message... <<<<<< RAW: <<<<<< length = 52 <<<<<< data = 03:00:00:00:34:00:00:00:22:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message (translated)... <<<<<< Header: <<<<<< length = 52 <<<<<< type = command (0x00000003) <<<<<< transaction = 34 <<<<<< Fragment header: <<<<<< total = 1 <<<<<< current = 0 <<<<<< Contents: <<<<<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) <<<<<< cid = 'device-service-subscribe-list' (0x00000013) <<<<<< type = 'set' (0x00000001) <<<<<< Fields: <<<<<< EventsCount = '0' <<<<<< Events = '{ <<<<<< }' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message... >>>>>> RAW: >>>>>> length = 52 >>>>>> data = 03:00:00:80:34:00:00:00:22:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message (translated)... >>>>>> Header: >>>>>> length = 52 >>>>>> type = command-done (0x80000003) >>>>>> transaction = 34 >>>>>> Fragment header: >>>>>> total = 1 >>>>>> current = 0 >>>>>> Contents: >>>>>> status error = 'None' (0x00000000) >>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) >>>>>> cid = 'device-service-subscribe-list' (0x00000013) >>>>>> Fields: >>>>>> EventsCount = '0' >>>>>> Events = '{ >>>>>> }' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.271911] [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) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.272031] [modem0] modem has 3GPP capabilities, disabling the Modem 3GPP interface... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.272116] [modem0] enabled 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) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message... <<<<<< RAW: <<<<<< length = 52 <<<<<< data = 03:00:00:00:34:00:00:00:23:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message (translated)... <<<<<< Header: <<<<<< length = 52 <<<<<< type = command (0x00000003) <<<<<< transaction = 35 <<<<<< Fragment header: <<<<<< total = 1 <<<<<< current = 0 <<<<<< Contents: <<<<<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) <<<<<< cid = 'device-service-subscribe-list' (0x00000013) <<<<<< type = 'set' (0x00000001) <<<<<< Fields: <<<<<< EventsCount = '0' <<<<<< Events = '{ <<<<<< }' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message... >>>>>> RAW: >>>>>> length = 52 >>>>>> data = 03:00:00:80:34:00:00:00:23:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message (translated)... >>>>>> Header: >>>>>> length = 52 >>>>>> type = command-done (0x80000003) >>>>>> transaction = 35 >>>>>> Fragment header: >>>>>> total = 1 >>>>>> current = 0 >>>>>> Contents: >>>>>> status error = 'None' (0x00000000) >>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) >>>>>> cid = 'device-service-subscribe-list' (0x00000013) >>>>>> Fields: >>>>>> EventsCount = '0' >>>>>> Events = '{ >>>>>> }' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.272888] [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) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.273009] [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) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.273124] [modem0] enabled 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) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message... <<<<<< RAW: <<<<<< length = 52 <<<<<< data = 03:00:00:00:34:00:00:00:24:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] sent message (translated)... <<<<<< Header: <<<<<< length = 52 <<<<<< type = command (0x00000003) <<<<<< transaction = 36 <<<<<< Fragment header: <<<<<< total = 1 <<<<<< current = 0 <<<<<< Contents: <<<<<< service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) <<<<<< cid = 'device-service-subscribe-list' (0x00000013) <<<<<< type = 'set' (0x00000001) <<<<<< Fields: <<<<<< EventsCount = '0' <<<<<< Events = '{ <<<<<< }' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message... >>>>>> RAW: >>>>>> length = 52 >>>>>> data = 03:00:00:80:34:00:00:00:24:00:00:00... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [/dev/cdc-wdm0] received message (translated)... >>>>>> Header: >>>>>> length = 52 >>>>>> type = command-done (0x80000003) >>>>>> transaction = 36 >>>>>> Fragment header: >>>>>> total = 1 >>>>>> current = 0 >>>>>> Contents: >>>>>> status error = 'None' (0x00000000) >>>>>> service = 'basic-connect' (a289cc33-bcbb-8b4f-b6b0-133ec2aae6df) >>>>>> cid = 'device-service-subscribe-list' (0x00000013) >>>>>> Fields: >>>>>> EventsCount = '0' >>>>>> Events = '{ >>>>>> }' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.273915] [modem0] disabling the Modem interface... Mon Jun 12 22:56:55 2023 daemon.info [10700]: [1686610615.274271] [modem0] state changed (enabling -> disabled) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.274766] [modem0/ttyUSB2/at] device open count is 1 (close) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.274829] [modem0/ttyUSB3/at] device open count is 0 (close) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.274883] [modem0/ttyUSB3/at] closing serial port... Mon Jun 12 22:56:55 2023 daemon.notice netifd: wwan (15881): error: couldn't connect the modem: 'GDBus.Error:org.freedesktop.ModemManager1.Error.Core.Retry: Invalid transition' Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.276252] [modem0/ttyUSB3/at] serial port closed Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.276330] [modem0/ttyUSB0/qcdm] device open count is 0 (close) Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.276385] [modem0/ttyUSB0/qcdm] closing serial port... Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.277878] [modem0/ttyUSB0/qcdm] serial port closed Mon Jun 12 22:56:55 2023 daemon.notice netifd: wwan (16013): stopping network Mon Jun 12 22:56:55 2023 daemon.notice netifd: wwan (16013): couldn't load bearer path: disconnecting anyway Mon Jun 12 22:56:55 2023 daemon.debug [10700]: [1686610615.383600] [modem0] user request to disconnect modem (all bearers) Mon Jun 12 22:56:55 2023 daemon.notice netifd: Interface 'wwan' is now down From aleksandermj at chromium.org Tue Jun 13 11:01:57 2023 From: aleksandermj at chromium.org (Aleksander Morgado) Date: Tue, 13 Jun 2023 13:01:57 +0200 Subject: Support Sequans LTE module In-Reply-To: <00d701d99aaf$098b78f0$1ca26ad0$@sequans.com> References: <00d701d99aaf$098b78f0$1ca26ad0$@sequans.com> Message-ID: Hey Oakley, > > I am writing to ask about add new plug-in on Modem Manager to support Sequans LTE module(https://sequans.com/products/cassiopeia-cb410l/). > > Please let me know your concern to add this new module into Modem Manager. I would be grateful if you could share your comment for this request. > We're open to add new plugins, sure. Interestingly, I believe some of us already have some very old Sequans modem that was sent to us like in 2013 or 2014 to test MBIM DSS. Mine is broken and doesn't read the SIM card, but I still have it somewhere. I'm sure your new plugin additions would be completely unrelated to that module, though ;) Feel free to add new plugins to the MM codebase and share your changes via gitlab, see https://modemmanager.org/docs/contribution-guidelines/ -- Aleksander From aleksandermj at chromium.org Tue Jun 13 11:04:27 2023 From: aleksandermj at chromium.org (Aleksander Morgado) Date: Tue, 13 Jun 2023 13:04:27 +0200 Subject: [Quectel EM160R-GL] Various commands over mbim fail with 'Invalid transition' In-Reply-To: <05A4F237-C4F7-4719-BFBE-723844A75CD6@meshplusplus.com> References: <05A4F237-C4F7-4719-BFBE-723844A75CD6@meshplusplus.com> Message-ID: On Tue, Jun 13, 2023 at 1:43?AM Alex Ballmer wrote: > > After upgrading an EM160R-GL modem via QFireHose from firmware version EM160RGLAUR02A07M4G to version EM160RGLAUR02A07M4G, almost all functions fail with ?Invalid transition?. The modem power state is listed as "power state: low? via mmcli. On the former firmware version everything was working fine. > > This is currently happening with modemmanager 1.18.8 using mbim via the qmi_wwan driver on openwrt with linux 4.4.60 and libmbim 1.28.4 > > I tried manually enabling it (in case it was FCC locked) via mbimcli --device-open-proxy --device="/dev/cdc-wdm0" --quectel-set-radio-state=on, but this also had no effect. > > What additional steps would I need to take to debug this? Very likely that they may have changed the FCC unlock algorithm in the newer firmware version :/ -- Aleksander From bjorn at mork.no Tue Jun 13 14:34:55 2023 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Tue, 13 Jun 2023 16:34:55 +0200 Subject: Support Sequans LTE module In-Reply-To: (Aleksander Morgado's message of "Tue, 13 Jun 2023 13:01:57 +0200") References: <00d701d99aaf$098b78f0$1ca26ad0$@sequans.com> Message-ID: <875y7re8hc.fsf@miraculix.mork.no> Aleksander Morgado writes: > Interestingly, I believe some of us already have some very old Sequans > modem that was sent to us like in 2013 or 2014 to test MBIM DSS. Mine > is broken and doesn't read the SIM card, but I still have it > somewhere. I'm sure your new plugin additions would be completely > unrelated to that module, though ;) Yes, I have one too. And a really bad conscience for never doing anything useful with DSS. Bj?rn From alexb at meshplusplus.com Tue Jun 13 16:46:59 2023 From: alexb at meshplusplus.com (Alex Ballmer) Date: Tue, 13 Jun 2023 11:46:59 -0500 Subject: [Quectel EM160R-GL] Various commands over mbim fail with 'Invalid transition' In-Reply-To: References: <05A4F237-C4F7-4719-BFBE-723844A75CD6@meshplusplus.com> Message-ID: > On Jun 13, 2023, at 6:04 AM, Aleksander Morgado wrote: > > On Tue, Jun 13, 2023 at 1:43?AM Alex Ballmer wrote: >> >> After upgrading an EM160R-GL modem via QFireHose from firmware version EM160RGLAUR02A07M4G to version EM160RGLAUR02A07M4G, almost all functions fail with ?Invalid transition?. The modem power state is listed as "power state: low? via mmcli. On the former firmware version everything was working fine. >> >> This is currently happening with modemmanager 1.18.8 using mbim via the qmi_wwan driver on openwrt with linux 4.4.60 and libmbim 1.28.4 >> >> I tried manually enabling it (in case it was FCC locked) via mbimcli --device-open-proxy --device="/dev/cdc-wdm0" --quectel-set-radio-state=on, but this also had no effect. >> >> What additional steps would I need to take to debug this? > > Very likely that they may have changed the FCC unlock algorithm in the > newer firmware version :/ > > -- > Aleksander The same firmware version has worked on other modems of the same model. This appears to be a problem with a specific batch of modems(?). Is this something that is likely to occur? Also in my testing the modem is not FCC locked, its stuck in factory-test mode, as verified by AT+QRFTESTMODE?. Attempting to leave factory-test mode with AT+QRFTESTMODE=0 doesn?t seem to have any effect From aleksandermj at chromium.org Wed Jun 14 08:36:25 2023 From: aleksandermj at chromium.org (Aleksander Morgado) Date: Wed, 14 Jun 2023 10:36:25 +0200 Subject: [Quectel EM160R-GL] Various commands over mbim fail with 'Invalid transition' In-Reply-To: References: <05A4F237-C4F7-4719-BFBE-723844A75CD6@meshplusplus.com> Message-ID: > >> After upgrading an EM160R-GL modem via QFireHose from firmware version EM160RGLAUR02A07M4G to version EM160RGLAUR02A07M4G, almost all functions fail with ?Invalid transition?. The modem power state is listed as "power state: low? via mmcli. On the former firmware version everything was working fine. > >> > >> This is currently happening with modemmanager 1.18.8 using mbim via the qmi_wwan driver on openwrt with linux 4.4.60 and libmbim 1.28.4 > >> > >> I tried manually enabling it (in case it was FCC locked) via mbimcli --device-open-proxy --device="/dev/cdc-wdm0" --quectel-set-radio-state=on, but this also had no effect. > >> > >> What additional steps would I need to take to debug this? > > > > Very likely that they may have changed the FCC unlock algorithm in the > > newer firmware version :/ > > > > -- > > Aleksander > > > The same firmware version has worked on other modems of the same model. This appears to be a problem with a specific batch of modems(?). Is this something that is likely to occur? > > Also in my testing the modem is not FCC locked, its stuck in factory-test mode, as verified by AT+QRFTESTMODE?. Attempting to leave factory-test mode with AT+QRFTESTMODE=0 doesn?t seem to have any effect Ah, that could also be it, yes. Maybe ask for help in the Quectel forum, they may know what happened or how to solve it. -- Aleksander From fredz0003 at gmail.com Wed Jun 14 19:33:48 2023 From: fredz0003 at gmail.com (Fernando B) Date: Wed, 14 Jun 2023 14:33:48 -0500 Subject: Simulate or mock modems Message-ID: Hi all, I figure to ask in this community since most likely everyone deals with modems on a regular basis. I work with edge devices, and sometimes the LTE signal around the house is bad (wfh). We mainly use verizon and att. I have a few scripts that I need to test, I come from the full stack dev world, where we can sometimes mock (fake) certain things, so I was wondering if such a thing exists for LTE modems, a simulator or a mock device in order to streamline testing. Thank you, Fernando B. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hector.jimenez.m at gmv.com Thu Jun 15 11:45:46 2023 From: hector.jimenez.m at gmv.com (=?iso-8859-1?Q?H=E9ctor_Jim=E9nez_M=E9ndez?=) Date: Thu, 15 Jun 2023 11:45:46 +0000 Subject: segmentation fault when calling mm_object_get_modem Message-ID: Hi. We are using ModemManager 1.18.8 library and sometimes we got segmentation fault when calling mm_object_get_modem function. It happens from time to time, no clues about circumstances, as our code is continuously inquiring for modem object in this function: MMModemPtr ModemManagerFacade::getModemPtr(const std::string &imei) { MMObject *object = getObject(imei); if (object == nullptr) { return MMModemPtr(nullptr, &g_object_unref); } return MMModemPtr(mm_object_get_modem(object), &g_object_unref); } It returns a MMModemPtr type, which is a unique pointer: using MMModemPtr = std::unique_ptr;///< MMModem Unique pointer with custom deleter and it's checked every time that function is called as in: MMModemPtr modem = getModemPtr(imei); if (modem == nullptr) { return DPY_UNAVAILABLE; } MMobject is stored in a map std::map mImeiToObjectMap; and obtained in MMObject* ModemManagerFacade::getObject(std::string imei) { /* Some previous checkings ... ...and*/ auto it = mImeiToObjectMap.find(imei); if (it == mImeiToObjectMap.end()) { return nullptr; } return (it->second); } But I don't think MMobject pointer is the problem as it's checked inside mm_object_get_modem function: MMModem * mm_object_get_modem (MMObject *self) { MMModem *modem; g_return_val_if_fail (MM_IS_OBJECT (MM_GDBUS_OBJECT (self)), NULL); modem = (MMModem *)mm_gdbus_object_get_modem (MM_GDBUS_OBJECT (self)); g_warn_if_fail (MM_IS_MODEM (modem)); return modem; } and the backtrace shows that the program terminates after calling mm_gdbus_object_get_modem Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000ffffad048ab8 in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0 [Current thread is 1 (LWP 10802)] (gdb) bt #0 0x0000ffffad048ab8 in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0 #1 0x0000ffffad2f5824 in ?? () from /usr/lib/libgio-2.0.so.0 #2 0x0000ffffad4629dc in mm_gdbus_object_get_modem () from /usr/lib/libmm-glib.so.0 #3 0x0000ffffad422e2c in mm_object_get_modem () from /usr/lib/libmm-glib.so.0 #4 0x0000aaaabff73124 in ModemManagerFacade::getModemPtr(std::__cxx11::basic_string, std::allocator > const&) () #5 0x0000aaaabff745f0 in ModemManagerFacade::getDominantTechnologySignalQuality(std::__cxx11::basic_string, std::allocator > const&, dpyModem::SignalQuality&, bool&) () #6 0x0000aaaabff5d97c in ModemManagerDevice::update_signalQuality() () #7 0x0000aaaabffbb050 in ModemSupervisor::updateModemParameters() () #8 0x0000aaaabffbbc44 in ModemSupervisor::checkModemStatus(boost::system::error_code const&, dpyModem::ModemState) () #9 0x0000aaaabffbcfe8 in boost::asio::detail::wait_handler, boost::_bi::list3, boost::arg<1> (*)(), boost::_bi::value > > >::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long) () #10 0x0000aaaabff0de38 in boost::asio::detail::scheduler::do_run_one(boost::asio::detail::conditionally_enabled_mutex::scoped_lock&, boost::asio::detail::scheduler_thread_info&, boost::system::error_code const&) () #11 0x0000aaaabffe704c in ModemService::operator()(boost::application::basic_context&) () #12 0x0000aaaabffd019c in int boost::application::launch, boost::application::basic_context>(boost::application::auto_handler&, boost::application::basic_context&, boost::system::error_code&) () #13 0x0000aaaabfedc9a0 in main () Any ideas about why this can be happening? Has it ever been seen before? Thank you! [Logo] H?ctor Jim?nez M?ndez Firmware engineer T. 983 54 65 54 M. 696 297 286 Juan de Herrera, n? 17, P.T.B. 47151 Boecillo, Valladolid | Spain [cid:image002.jpg at 01D99F89.0F4ED1E0] [cid:image003.jpg at 01D99F89.0F4ED1E0] [cid:image004.jpg at 01D99F89.0F4ED1E0] [cid:image005.jpg at 01D99F89.0F4ED1E0] [cid:image006.jpg at 01D99F89.0F4ED1E0] [cid:image007.jpg at 01D99F89.0F4ED1E0] www.gmv.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 32181 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 12212 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 12347 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 12322 bytes Desc: image004.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 12329 bytes Desc: image005.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 12373 bytes Desc: image006.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.jpg Type: image/jpeg Size: 12317 bytes Desc: image007.jpg URL: From frederic.martinsons at unabiz.com Sun Jun 18 17:05:49 2023 From: frederic.martinsons at unabiz.com (Frederic Martinsons) Date: Sun, 18 Jun 2023 19:05:49 +0200 Subject: Simulate or mock modems In-Reply-To: References: Message-ID: Hello Fernando, For testing my applications, I personally use the stub/mock from MM git sources ( https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/blob/main/tools/test-modemmanager-service.py ). It is aimed to mock the whole modemmanager process though (not a single modem device) but maybe it can feed your needs. Le mer. 14 juin 2023, 21:34, Fernando B a ?crit : > Hi all, > > I figure to ask in this community since most likely everyone deals with > modems on a regular basis. I work with edge devices, and sometimes the LTE > signal around the house is bad (wfh). We mainly use verizon and att. I have > a few scripts that I need to test, I come from the full stack dev world, > where we can sometimes mock (fake) certain things, so I was wondering if > such a thing exists for LTE modems, a simulator or a mock device in order > to streamline testing. > > Thank you, > Fernando B. > -- *Disclaimer*:**_?This e-mail and any attachments thereto are intended for the sole use of the recipient(s) named above and may contain information that is confidential and/or proprietary to UnaBiz. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication, or dissemination in any form) by persons other than the intended recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete it._ -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic.martinsons at unabiz.com Sun Jun 18 17:20:48 2023 From: frederic.martinsons at unabiz.com (Frederic Martinsons) Date: Sun, 18 Jun 2023 19:20:48 +0200 Subject: Simulate or mock modems In-Reply-To: References: Message-ID: Fit, not feed of course. Anyway, if it doesn't fit your needs, you may want to look at this code anyway and maybe tweak it to add more features. If you do so, please open a merge request, I'm sure there are people (including me of course) who are willing to see this modemanager mock getting better. Have a nice day Le dim. 18 juin 2023, 19:05, Frederic Martinsons < frederic.martinsons at unabiz.com> a ?crit : > Hello Fernando, > > For testing my applications, I personally use the stub/mock from MM git > sources ( > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/blob/main/tools/test-modemmanager-service.py > ). > > It is aimed to mock the whole modemmanager process though (not a single > modem device) but maybe it can feed your needs. > > Le mer. 14 juin 2023, 21:34, Fernando B a ?crit : > >> Hi all, >> >> I figure to ask in this community since most likely everyone deals with >> modems on a regular basis. I work with edge devices, and sometimes the LTE >> signal around the house is bad (wfh). We mainly use verizon and att. I have >> a few scripts that I need to test, I come from the full stack dev world, >> where we can sometimes mock (fake) certain things, so I was wondering if >> such a thing exists for LTE modems, a simulator or a mock device in order >> to streamline testing. >> >> Thank you, >> Fernando B. >> > -- *Disclaimer*:**_?This e-mail and any attachments thereto are intended for the sole use of the recipient(s) named above and may contain information that is confidential and/or proprietary to UnaBiz. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication, or dissemination in any form) by persons other than the intended recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender immediately and delete it._ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredz0003 at gmail.com Tue Jun 20 02:01:01 2023 From: fredz0003 at gmail.com (Fernando B) Date: Mon, 19 Jun 2023 21:01:01 -0500 Subject: Simulate or mock modems In-Reply-To: References: Message-ID: Thanks for the recommendation Frederic. I think if I get enough time I might do some unittests and stubs for my scripts. On Sun, Jun 18, 2023, 12:21 PM Frederic Martinsons < frederic.martinsons at unabiz.com> wrote: > Fit, not feed of course. > > Anyway, if it doesn't fit your needs, you may want to look at this code > anyway and maybe tweak it to add more features. > If you do so, please open a merge request, I'm sure there are people > (including me of course) who are willing to see this modemanager mock > getting better. > > Have a nice day > > Le dim. 18 juin 2023, 19:05, Frederic Martinsons < > frederic.martinsons at unabiz.com> a ?crit : > >> Hello Fernando, >> >> For testing my applications, I personally use the stub/mock from MM git >> sources ( >> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/blob/main/tools/test-modemmanager-service.py >> ). >> >> It is aimed to mock the whole modemmanager process though (not a single >> modem device) but maybe it can feed your needs. >> >> Le mer. 14 juin 2023, 21:34, Fernando B a ?crit : >> >>> Hi all, >>> >>> I figure to ask in this community since most likely everyone deals with >>> modems on a regular basis. I work with edge devices, and sometimes the LTE >>> signal around the house is bad (wfh). We mainly use verizon and att. I have >>> a few scripts that I need to test, I come from the full stack dev world, >>> where we can sometimes mock (fake) certain things, so I was wondering if >>> such a thing exists for LTE modems, a simulator or a mock device in order >>> to streamline testing. >>> >>> Thank you, >>> Fernando B. >>> >> > *Disclaimer:** This e-mail and any attachments thereto are intended for > the sole use of the recipient(s) named above and may contain information > that is confidential and/or proprietary to UnaBiz. Any use of the > information contained herein (including, but not limited to, total or > partial reproduction, communication, or dissemination in any form) by > persons other than the intended recipient(s) is prohibited. If you have > received this e-mail in error, please notify the sender immediately and > delete it.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From hector.jimenez.m at gmv.com Tue Jun 20 15:44:28 2023 From: hector.jimenez.m at gmv.com (=?iso-8859-1?Q?H=E9ctor_Jim=E9nez_M=E9ndez?=) Date: Tue, 20 Jun 2023 15:44:28 +0000 Subject: unable to reconnect to "MM_MODEM_STATE_REGISTERED" status modem until it's reset Message-ID: Hello. We are using ModemManager 1.12.12 library in one of our projects and we are getting MM_MODEM_STATE_REGISTERED status when polling for Modem status with mm_modem_get_state function. Then we try to connect again by using mm_modem_simple_connect_sync function to get the bearer, and then mm_bearer_connect_sync with that bearer, which gets all bearer parameters, But modem still in MM_MODEM_STATE_REGISTERED status after that. Then we try again and finally restart the modem device and finally achieve to reconnect to modem. In some other situations, this procedure reconnects at first try, but we don't know why exactly modem returns MM_MODEM_STATE_REGISTERED status itself. Our system in boarded on a vehicle which is in moving around, so we are thinking it could be a matter of signal loss, but mmcli tool doesn't show low signal values. It shows modem in "registered" stated though when this happens. We are able to reconnect by "simple disconnect" the modem when it gets in "registered" state and before doing the reconnection procedure described above, but I seriously doubt this is the correct way to handle it. Is there any known/solved issue about this "registered" modem state relating to this version of the library? If not... any ideas about properly handling it? Thank you! [Logo] H?ctor Jim?nez M?ndez Firmware engineer T. 983 54 65 54 M. 696 297 286 Juan de Herrera, n? 17, P.T.B. 47151 Boecillo, Valladolid | Spain [cid:image002.jpg at 01D9A392.1EA4A680] [cid:image003.jpg at 01D9A392.1EA4A680] [cid:image004.jpg at 01D9A392.1EA4A680] [cid:image005.jpg at 01D9A392.1EA4A680] [cid:image006.jpg at 01D9A392.1EA4A680] [cid:image007.jpg at 01D9A392.1EA4A680] www.gmv.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 32181 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 12212 bytes Desc: image002.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 12347 bytes Desc: image003.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 12322 bytes Desc: image004.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 12329 bytes Desc: image005.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 12373 bytes Desc: image006.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.jpg Type: image/jpeg Size: 12317 bytes Desc: image007.jpg URL: From an010 at live.com Wed Jun 21 12:28:07 2023 From: an010 at live.com (Aleksandar Nikolic) Date: Wed, 21 Jun 2023 12:28:07 +0000 Subject: ModemManager - Access Technology vs ModemCapability Message-ID: Hi all, The device I am using has a Cinterion? EXS82-W built-in and I am noticing some weird behavior when it comes to Access Technologies and ModemCapatibiliy, IMHO it doesn't make sense, but I guess I am wrong somewhere and would like to know where. Reading the AccessTechnologies property busctl get-property org.freedesktop.ModemManager1 /org/freedesktop/ModemManager1/Modem/0 org.freedesktop.ModemManager1.Modem AccessTechnologies u 16384 The value 16384 should correspond to MM_MODEM_ACCESS_TECHNOLOGY_LTE. Reading the SupportedCapabilities property busctl get-property org.freedesktop.ModemManager1 /org/freedesktop/ModemManager1/Modem/0 org.freedesktop.ModemManager1.Modem SupportedCapabilities au 1 4 The value should correspond to MM_MODEM_CAPABILITY_GSM_UMTS. Question How can it be that my modem supports only GSM/UMTS from the general access technology families, but at the same time it is using the LTE technology when registered with or connected to a network? Thanks and cheers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksandermj at chromium.org Sat Jun 24 22:28:00 2023 From: aleksandermj at chromium.org (Aleksander Morgado) Date: Sun, 25 Jun 2023 00:28:00 +0200 Subject: segmentation fault when calling mm_object_get_modem In-Reply-To: References: Message-ID: Hey H?ctor, > We are using ModemManager 1.18.8 library and sometimes we got segmentation > fault when calling mm_object_get_modem function. It happens from time to > time, no clues about circumstances, as our code is continuously inquiring > for modem object in this function: > > > > MMModemPtr ModemManagerFacade::getModemPtr(const std::string &imei) > > { > > MMObject *object = getObject(imei); > > if (object == nullptr) { > > return MMModemPtr(nullptr, &g_object_unref); > > } > > > > return MMModemPtr(mm_object_get_modem(object), &g_object_unref); > > } > > > > It returns a MMModemPtr type, which is a unique pointer: > > using MMModemPtr = std::unique_ptr;///< > MMModem Unique pointer with custom deleter > > > > and it?s checked every time that function is called as in: > > MMModemPtr modem = getModemPtr(imei); > > if (modem == nullptr) { > > return DPY_UNAVAILABLE; > > } > > > > MMobject is stored in a map > > std::map mImeiToObjectMap; > > > > and obtained in > > MMObject* ModemManagerFacade::getObject(std::string imei) > > { > > /* Some previous checkings ? > > ?and*/ > > auto it = mImeiToObjectMap.find(imei); > > if (it == mImeiToObjectMap.end()) { > > return nullptr; > > } > > return (it->second); > > } > > > > But I don?t think MMobject pointer is the problem as it?s checked inside > mm_object_get_modem function: > > MMModem * > > mm_object_get_modem (MMObject *self) > > { > > MMModem *modem; > > > > g_return_val_if_fail (MM_IS_OBJECT (MM_GDBUS_OBJECT (self)), NULL); > > > > modem = (MMModem *)mm_gdbus_object_get_modem (MM_GDBUS_OBJECT (self)); > > g_warn_if_fail (MM_IS_MODEM (modem)); > > return modem; > > } > > > > and the backtrace shows that the program terminates after calling > mm_gdbus_object_get_modem > > > > Program terminated with signal SIGSEGV, Segmentation fault. > > #0 0x0000ffffad048ab8 in g_hash_table_lookup () from > /usr/lib/libglib-2.0.so.0 > > [Current thread is 1 (LWP 10802)] > > (gdb) bt > > #0 0x0000ffffad048ab8 in g_hash_table_lookup () from > /usr/lib/libglib-2.0.so.0 > > #1 0x0000ffffad2f5824 in ?? () from /usr/lib/libgio-2.0.so.0 > #2 0x0000ffffad4629dc in mm_gdbus_object_get_modem () from > /usr/lib/libmm-glib.so.0 > > #3 0x0000ffffad422e2c in mm_object_get_modem () from > /usr/lib/libmm-glib.so.0 > > #4 0x0000aaaabff73124 in > ModemManagerFacade::getModemPtr(std::__cxx11::basic_string std::char_traits, std::allocator > const&) () > > #5 0x0000aaaabff745f0 in > ModemManagerFacade::getDominantTechnologySignalQuality(std::__cxx11::basic_string std::char_traits, std::allocator > const&, > dpyModem::SignalQuality&, bool&) () > > #6 0x0000aaaabff5d97c in ModemManagerDevice::update_signalQuality() () > > #7 0x0000aaaabffbb050 in ModemSupervisor::updateModemParameters() () > > #8 0x0000aaaabffbbc44 in > ModemSupervisor::checkModemStatus(boost::system::error_code const&, > dpyModem::ModemState) () > > #9 0x0000aaaabffbcfe8 in > boost::asio::detail::wait_handler boost::_mfi::mf2 dpyModem::ModemState>, > boost::_bi::list3, boost::arg<1> (*)(), > boost::_bi::value > > >::do_complete(void*, > boost::asio::detail::scheduler_operation*, boost::system::error_code > const&, unsigned long) () > > #10 0x0000aaaabff0de38 in > boost::asio::detail::scheduler::do_run_one(boost::asio::detail::conditionally_enabled_mutex::scoped_lock&, > boost::asio::detail::scheduler_thread_info&, boost::system::error_code > const&) () > > #11 0x0000aaaabffe704c in > ModemService::operator()(boost::application::basic_context&) () > > #12 0x0000aaaabffd019c in int > boost::application::launch boost::application::auto_handler, > boost::application::basic_context>(boost::application::auto_handler&, > boost::application::basic_context&, boost::system::error_code&) () > > #13 0x0000aaaabfedc9a0 in main () > > > > Any ideas about why this can be happening? Has it ever been seen before? > i'd bet this is some memory corruption happening somewhere. Is the issue easily reproducible? maybe you can prepare a small reproducer program that triggers this issue for us to analyze? Otherwise, I suggest you try to run under valgrind to see if you get any memory related issues reported there. The only thing I can say about this issue is that I don't recall anything similar to this reported lately in the past years. libmm-glib is used by multiple other projects, so there's a high chance that the issue is indeed a memory corruption somewhere in your project. Maybe a double free, or a use-after-free, or something like that. Also please note that the g_return_if_fail() calls may be disabled in the build! you should ensure these are being used in your build before assuming they're being called. Sorry I cannot help more :/ -- Aleksander -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksandermj at chromium.org Sat Jun 24 22:30:46 2023 From: aleksandermj at chromium.org (Aleksander Morgado) Date: Sun, 25 Jun 2023 00:30:46 +0200 Subject: unable to reconnect to "MM_MODEM_STATE_REGISTERED" status modem until it's reset In-Reply-To: References: Message-ID: Hey, > > We are using ModemManager 1.12.12 library in one of our projects and we are getting MM_MODEM_STATE_REGISTERED status when polling for Modem status with mm_modem_get_state function. > > > > Then we try to connect again by using mm_modem_simple_connect_sync function to get the bearer, and then mm_bearer_connect_sync with that bearer, which gets all bearer parameters, > > > > But modem still in MM_MODEM_STATE_REGISTERED status after that. > > > > Then we try again and finally restart the modem device and finally achieve to reconnect to modem. > > > > In some other situations, this procedure reconnects at first try, but we don?t know why exactly modem returns MM_MODEM_STATE_REGISTERED status itself. > > > > Our system in boarded on a vehicle which is in moving around, so we are thinking it could be a matter of signal loss, but mmcli tool doesn?t show low signal values. It shows modem in ?registered? stated though when this happens. > > > > We are able to reconnect by ?simple disconnect? the modem when it gets in ?registered? state and before doing the reconnection procedure described above, but I seriously doubt this is the correct way to handle it. > > > > Is there any known/solved issue about this ?registered? modem state relating to this version of the library? > > > > If not? any ideas about properly handling it? > This vaguely reminds me to some issue years ago, but my memory is not that good. MM 1.12 is extremely old and we have fixed and improved the whole stack a lot in the next releases. -- Aleksander From aleksandermj at chromium.org Sat Jun 24 22:32:48 2023 From: aleksandermj at chromium.org (Aleksander Morgado) Date: Sun, 25 Jun 2023 00:32:48 +0200 Subject: ModemManager - Access Technology vs ModemCapability In-Reply-To: References: Message-ID: Hey, > > The device I am using has a Cinterion? EXS82-W built-in and I am noticing some weird behavior when it comes to Access Technologies and ModemCapatibiliy, IMHO it doesn't make sense, but I guess I am wrong somewhere and would like to know where. > > Reading the AccessTechnologies property > > busctl get-property org.freedesktop.ModemManager1 /org/freedesktop/ModemManager1/Modem/0 org.freedesktop.ModemManager1.Modem AccessTechnologies > u 16384 > > The value 16384 should correspond to MM_MODEM_ACCESS_TECHNOLOGY_LTE. > > Reading the SupportedCapabilities property > > busctl get-property org.freedesktop.ModemManager1 /org/freedesktop/ModemManager1/Modem/0 org.freedesktop.ModemManager1.Modem SupportedCapabilities > au 1 4 > > The value should correspond to MM_MODEM_CAPABILITY_GSM_UMTS. > > Question > > How can it be that my modem supports only GSM/UMTS from the general access technology families, but at the same time it is using the LTE technology when registered with or connected to a network? > This is definitely a bug when reading supported capabilities. Could you open a new bug in gitlab and attach MM debug log to see what's happening? See * https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/new * https://modemmanager.org/docs/modemmanager/debugging/ -- Aleksander From hector.jimenez.m at gmv.com Thu Jun 29 07:38:50 2023 From: hector.jimenez.m at gmv.com (=?utf-8?B?SMOpY3RvciBKaW3DqW5leiBNw6luZGV6?=) Date: Thu, 29 Jun 2023 07:38:50 +0000 Subject: unable to reconnect to "MM_MODEM_STATE_REGISTERED" status modem until it's reset In-Reply-To: References: Message-ID: Thank you! We'll consider updating MM to newer versions depending on how our workaround affects the user experience. Kind regards! H?ctor Jim?nez M?ndez Firmware engineer T. 983 54 65 54 M. 696 297 286 Juan de Herrera, n? 17, P.T.B. 47151 Boecillo, Valladolid | Spain www.gmv.com -----Mensaje original----- De: Aleksander Morgado Enviado el: domingo, 25 de junio de 2023 0:31 Para: H?ctor Jim?nez M?ndez CC: modemmanager-devel at lists.freedesktop.org Asunto: Re: unable to reconnect to "MM_MODEM_STATE_REGISTERED" status modem until it's reset Hey, > > We are using ModemManager 1.12.12 library in one of our projects and we are getting MM_MODEM_STATE_REGISTERED status when polling for Modem status with mm_modem_get_state function. > > > > Then we try to connect again by using mm_modem_simple_connect_sync > function to get the bearer, and then mm_bearer_connect_sync with that > bearer, which gets all bearer parameters, > > > > But modem still in MM_MODEM_STATE_REGISTERED status after that. > > > > Then we try again and finally restart the modem device and finally achieve to reconnect to modem. > > > > In some other situations, this procedure reconnects at first try, but we don?t know why exactly modem returns MM_MODEM_STATE_REGISTERED status itself. > > > > Our system in boarded on a vehicle which is in moving around, so we are thinking it could be a matter of signal loss, but mmcli tool doesn?t show low signal values. It shows modem in ?registered? stated though when this happens. > > > > We are able to reconnect by ?simple disconnect? the modem when it gets in ?registered? state and before doing the reconnection procedure described above, but I seriously doubt this is the correct way to handle it. > > > > Is there any known/solved issue about this ?registered? modem state relating to this version of the library? > > > > If not? any ideas about properly handling it? > This vaguely reminds me to some issue years ago, but my memory is not that good. MM 1.12 is extremely old and we have fixed and improved the whole stack a lot in the next releases. -- Aleksander P Please consider the environment before printing this e-mail.