PDP settings for LTE only network

[Brendan Simon]

Hello,

I have a number of embedded linux boxes with Quectel EC21 4G modems,
connected to various cellular networks (AT&T, Verizon, ...).

AT&T are removing 3G from some areas and the modems are not reconnecting.
My devices are vanishing off the face of the Internet.

Quectel have provided some assistance and guidance and advised to configure
some settings for AT&T Sunsetting.  The UE Usage Setting was changed to
configure the device as Data Centric (i.e. no voice), however it did not
resolve the issue.

AT&T provided some assistance - apparently the APN was wrong.  Seems like
some generic APNs are being used and not the APN specified in the
NetworkManager configuration.  This all worked ok when 3G was available.

AT&G also suggested the PDP settings of the modem are the issue.
Changing the default PDP context (#!) from an APN of "" to the provided APN
seems to have resolved the connection issue.

I have used `mmcli -m N --command="..." to modify the PDP context for
testing.

I feel this is hacky and shouldn't be required.

*Is there a better (more elegant and generic method) to set the PDP
contexts so modems (preferably any brand) will work on 4G only networks?*

*NOTE: we are using Debian Buster with ModemManager 1.10.0.*


*Would upgrading MM help?  Buster-Backports has 1.14.0 available, which
would be easy to build/install on the existing OS.*

Thanks, Brendan.

Re: PDP settings for LTE only network

[Brendan Simon]

Hi Aleksander,

Many thanks for your response.  That is a BIG BIG HELP -- as I currently 
have to stop the MM service and restart it in debug mode, just to query 
some settings.  I then change settings if necessary and then 
stop/restart MM in non-debug mode.  All that takes a bit of time.


I've just discovered that MM 1.18.0 is available in `buster-sloppy` 
distro - part of Debian Backports, so that looks like the way forward 
for now.


Again, many many thanks !!

Cheers, Brendan.
--


On 14/6/2022 6:01 pm, Aleksander Morgado wrote:

Hey,

On Tue, Jun 14, 2022 at 9:53 AM Brendan Simon  wrote:

Hello,

I have a number of embedded linux boxes with Quectel EC21 4G modems, connected to 
various cellular networks (AT&T, Verizon, ...).

AT&T are removing 3G from some areas and the modems are not reconnecting.  My 
devices are vanishing off the face of the Internet.

Quectel have provided some assistance and guidance and advised to configure some 
settings for AT&T Sunsetting.  The UE Usage Setting was changed to configure 
the device as Data Centric (i.e. no voice), however it did not resolve the issue.

AT&T provided some assistance - apparently the APN was wrong.  Seems like some 
generic APNs are being used and not the APN specified in the NetworkManager 
configuration.  This all worked ok when 3G was available.

AT&G also suggested the PDP settings of the modem are the issue.
Changing the default PDP context (#!) from an APN of "" to the provided APN 
seems to have resolved the connection issue.

I have used `mmcli -m N --command="..." to modify the PDP context for testing.

I feel this is hacky and shouldn't be required.

Is there a better (more elegant and generic method) to set the PDP contexts so 
modems (preferably any brand) will work on 4G only networks?


The way to elegantly change the APN settings for the initial EPS
default bearer would be using e.g.:
$ mmcli --3gpp-set-initial-eps-bearer-settings='apn=something'

In QMI-based modems as the EC21, this would internally change the
profile associated to the initial bearer.


NOTE: we are using Debian Buster with ModemManager 1.10.0.

Would upgrading MM help?  Buster-Backports has 1.14.0 available, which would be 
easy to build/install on the existing OS.


The QMI-based initial EPS bearer settings update was implemented in
commit 5613215db8 (November 2020), which was released with
ModemManager 1.16.0. The latest update in the 1.16.x series is
1.16.10, but the series is now fully unsupported; the latest supported
series is 1.18.x.

Re: PDP settings for LTE only network

[Brendan Simon]

Is there an equivalent setting in the NetworkManager system connection
configuration file for --
3gpp-set-initial-eps-bearer-settings='apn=something' ?

Is there a similar command or NM setting to set the modem UE Usage Setting
to data-centric mode?
Equivalent to: AT+QNVFW="/nv/item_files/modem/mmode/ue_usage_setting",01

That command came from a Quectel document for AT&T 3G Sunset Guide.

Thanks, Brendan.


On Tue, 14 Jun 2022 at 18:08, Brendan Simon 
wrote:

> Hi Aleksander,
>
> Many thanks for your response.  That is a BIG BIG HELP -- as I currently
> have to stop the MM service and restart it in debug mode, just to query
> some settings.  I then change settings if necessary and then stop/restart
> MM in non-debug mode.  All that takes a bit of time.
>
> I've just discovered that MM 1.18.0 is available in `buster-sloppy` distro
> - part of Debian Backports, so that looks like the way forward for now.
>
> Again, many many thanks !!
>
> Cheers, Brendan.
> --
>
>
> On 14/6/2022 6:01 pm, Aleksander Morgado wrote:
>
> Hey,
>
> On Tue, Jun 14, 2022 at 9:53 AM Brendan Simon  
>  wrote:
>
> Hello,
>
> I have a number of embedded linux boxes with Quectel EC21 4G modems, 
> connected to various cellular networks (AT&T, Verizon, ...).
>
> AT&T are removing 3G from some areas and the modems are not reconnecting.  My 
> devices are vanishing off the face of the Internet.
>
> Quectel have provided some assistance and guidance and advised to configure 
> some settings for AT&T Sunsetting.  The UE Usage Setting was changed to 
> configure the device as Data Centric (i.e. no voice), however it did not 
> resolve the issue.
>
> AT&T provided some assistance - apparently the APN was wrong.  Seems like 
> some generic APNs are being used and not the APN specified in the 
> NetworkManager configuration.  This all worked ok when 3G was available.
>
> AT&G also suggested the PDP settings of the modem are the issue.
> Changing the default PDP context (#!) from an APN of "" to the provided APN 
> seems to have resolved the connection issue.
>
> I have used `mmcli -m N --command="..." to modify the PDP context for testing.
>
> I feel this is hacky and shouldn't be required.
>
> Is there a better (more elegant and generic method) to set the PDP contexts 
> so modems (preferably any brand) will work on 4G only networks?
>
>
> The way to elegantly change the APN settings for the initial EPS
> default bearer would be using e.g.:
> $ mmcli --3gpp-set-initial-eps-bearer-settings='apn=something'
>
> In QMI-based modems as the EC21, this would internally change the
> profile associated to the initial bearer.
>
>
> NOTE: we are using Debian Buster with ModemManager 1.10.0.
>
> Would upgrading MM help?  Buster-Backports has 1.14.0 available, which would 
> be easy to build/install on the existing OS.
>
>
> The QMI-based initial EPS bearer settings update was implemented in
> commit 5613215db8 (November 2020), which was released with
> ModemManager 1.16.0. The latest update in the 1.16.x series is
> 1.16.10, but the series is now fully unsupported; the latest supported
> series is 1.18.x.
>
>
>
>

3gpp-set-eps-ue-mode-operation fails to set some options

[Brendan Simon]

I'm trying to use the `--3gpp-set-eps-ue-mode-operation` to set
`data-centric` or `voice-centric` modes.

I note there are 4 possible values: ps-1, ps-2, csps-1 and csps-2, with
ps-2 and csps-2 being data-centric.

My Quectel E21 modem only accepts one option; csps-2.  All other options
fail.

*What determines what options MM can or cannot set** for ue-mode ?* - is it
the modem, SIM card, network, other?

*How can I use the `--3gpp-set-eps-ue-mode-operation` option to set/change
from voice-centric to data-centric, etc.*

I would prefer not to issue AT commands (especially since Debian does not
configure MM to allow AT commands and I have to use debug mode).

Below are some annotated commands and output.

Thanks, Brendan.

--


*# mmcli -m 0 --3gpp-set-eps-ue-mode-operation=csps-1*error: couldn't set
UE mode of operation for EPS:
'GDBus.Error:org.freedesktop.ModemManager1.Error.MobileEquipment.NotSupported:
Operation not supported'


*# mmcli -m 0 --3gpp-set-eps-ue-mode-operation=csps-2*successfully set UE
mode of operation for EPS

I had set the `ue_usage_setting` to `01` according to a Quectel guide.


*# mmcli -m 0
--command='AT+QNVFR="/nv/item_files/modem/mmode/ue_usage_setting"'*response:
'+QNVFR: 01'

This shows up as `csps-2` in MM status.


*# mmcli -m 0 | grep "ue mode"*  3GPP EPS |   ue mode of operation: csps-2

If I change the `ue_usage_setting` to `00`, MM status is `csps-1` (though I
have to reset/power-cycle the modem, otherwise MM status still reports
`csps-2`).


*# mmcli -m 0
--command='AT+QNVFW="/nv/item_files/modem/mmode/ue_usage_setting",00'*response:
''

*# mmcli -m 0
--command='AT+QNVFR="/nv/item_files/modem/mmode/ue_usage_setting"'*response:
'+QNVFR: 00'


*# mmcli -m 0 | grep "ue mode"*  3GPP EPS |   ue mode of operation: csps-2

After reset/power-cycle modem


*# mmcli -m 1 | grep "ue mode"*  3GPP EPS |   ue mode of operation: csps-1

--

Re: 3gpp-set-eps-ue-mode-operation fails to set some options

[Brendan Simon]

Ok, so I might have to talk to Quectel to see what is going on and if there
are alternative options.

I'm thinking that I'll have to bite the bullet and build ModemManager
myself with extra options to accept AT commands, unless I can convince the
Debian maintainers to add the extra option as standard.

BTW, regarding the TS and TLVs that I've seen mentioned - are they publicly
available somewhere?

Thanks,
Brendan.


On Fri, 1 Jul 2022 at 19:36, Aleksander Morgado 
wrote:

> Hey Brendan,
>
> > I'm trying to use the `--3gpp-set-eps-ue-mode-operation` to set
> `data-centric` or `voice-centric` modes.
> >
> > I note there are 4 possible values: ps-1, ps-2, csps-1 and csps-2, with
> ps-2 and csps-2 being data-centric.
> >
> > My Quectel E21 modem only accepts one option; csps-2.  All other options
> fail.
> >
> > What determines what options MM can or cannot set for ue-mode ? - is it
> the modem, SIM card, network, other?
> >
> > How can I use the `--3gpp-set-eps-ue-mode-operation` option to
> set/change from voice-centric to data-centric, etc.
> >
> > I would prefer not to issue AT commands (especially since Debian does
> not configure MM to allow AT commands and I have to use debug mode).
> >
>
> The EPS UE mode of operation implementation is currently only
> implemented using AT+CEMODE, so if that's failing to set some of the
> options, it's because the modem is rejecting them in the +CEMODE call.
>
> I've recently discussed about this with @Reinhard Speyerer in some
> emails, and he pointed out there's also now AT+CEUS applicable to both
> 4G and 5G; and he also pointed out that there are some QMI TLVs we
> could use in the "NAS Set System Selection Preference" to configure
> the same settings as +CEMODE and +CEUS. At some point I think we need
> to extend the API with a new method equivalent to +CEUS and still keep
> supporting the +CEMODE based one.
>
> We're in the process of adding a lot of new 5G related APIs, so if
> anyone wants to work on defining new APIs that would fit all this in a
> better way, that would be extremely appreciated.
>
>
> --
> Aleksander
> https://aleksander.es
>

Re: 3gpp-set-eps-ue-mode-operation fails to set some options

[Brendan Simon]

Thanks Reinhard.
The document is dated 2013.  Is that really the latest version?
Brendan.

On Tue, 5 Jul 2022 at 17:51, Reinhard Speyerer  wrote:

> Aleksander Morgado  wrote:
>
> > Hey,
> >
> > On Sun, Jul 3, 2022 at 2:16 AM Brendan Simon 
> wrote:
> > >
> > > Ok, so I might have to talk to Quectel to see what is going on and if
> there are alternative options.
> > >
> > > I'm thinking that I'll have to bite the bullet and build ModemManager
> myself with extra options to accept AT commands, unless I can convince the
> Debian maintainers to add the extra option as standard.
> > >
> > > BTW, regarding the TS and TLVs that I've seen mentioned - are they
> publicly available somewhere?
> > >
> >
> > The AT commands references are published by 3GPP and ETSI. E.g. check
> > 3GPP TS 27.007 at
> >
> https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1515
> >
> > For the QMI TLVs, I'm not sure if there is any publicly accessible
> > document with those defined, truth be told.
>
> Hi,
>
> the corresponding NAS{G,S}etSystemSelectionPref TLVs
> (ServiceDomainPreference and ModemUsagePreference) are documented here
> https://mirrors.edge.kernel.org/caf_patches/quic/gobi/Gobi/index.html .
>
> Regards,
> Reinhard
>

Get modem SIM properties for mmcli

[Brendan Simon]

IND.T Classification: Public

Is there a way to get the modem SIM properties via the mmcli command?
e.g. the ICCID or SimIdentifier
org.freedesktop.ModemManager1.Sim: ModemManager Reference Manual 
(www.freedesktop.org)

I couldn't find anything in the help.

These docs mention the methods (such as sendpin, sendpuk, enablepin, changepin, 
setpreferrednetworks), which are available via mmcli.

It also mentions various properties (such as Active, SimIdentifier, IMSI, ...), 
but I can't find a way to retrieving those via mmcli (except maybe via issue AT 
commands).

org.freedesktop.ModemManager1.Sim: ModemManager Reference Manual 
(www.freedesktop.org)

Are these properties easily obtainable via mmcli?  I would think they should 
be, but I can't find out how.

Thanks,
Brendan.

RE: Get modem SIM properties for mmcli

[Brendan Simon]

IND.T Classification: Public

Thanks Filip for your help.  I think I have enough info to retrieve the 
information.  I will git it a try.

Yes, it is to be parsed by a program/script.

The ModemManager I am currently using is quite old (v1.10 from Debian 10 
Buster) so json (-J) output is practically non-existent.  I either parse the 
raw human text output or use the -K option and parse.

Thanks, Brendan.

From: Filip Kubicz 
Sent: Monday, April 24, 2023 9:01 PM
To: Brendan Simon 
Cc: modemmanager-devel@lists.freedesktop.org
Subject: Re: Get modem SIM properties for mmcli


This email originated from EXTERNAL
I assumed you need to parse it for a program, but if you just need a 
human-readable version, you can also use
mmcli -i 0
For a quick overview, and to filter it, grep for the line that you are 
interested in.

Kind regards,
Filip


On Mon, Apr 24, 2023 at 12:58 PM Filip Kubicz 
mailto:filip.kub...@tier.app>> wrote:
Hi Brendan,

There are a few approaches but a convenient method to retrieve values from 
mmcli is to use -J flag to get the JSON output.

For example, to get modem IMEI, you can do (in bash):
modem="$(mmcli --list-modems -J | jq '."modem-list"[0]' -r)"
imei="$(mmcli -m ${modem} -J | jq '.modem."3gpp".imei' -r)"
echo ${imei}

You should be able to do the same with SIM card information, which you can 
obtain by running
mmcli -i 0 -J
and then parsing it with jq tool to obtain exactly the value you need. Note 
that the SIM may be available under different number/path, which you can get 
from mmcli -m  and parsing "primary sim path"

Kind regards,
Filip


On Mon, Apr 24, 2023 at 12:34 PM Brendan Simon 
mailto:brendan.si...@ind-technology.com.au>>
 wrote:

IND.T Classification: Public

Is there a way to get the modem SIM properties via the mmcli command?
e.g. the ICCID or SimIdentifier
org.freedesktop.ModemManager1.Sim: ModemManager Reference Manual 
(www.freedesktop.org)<https://www.freedesktop.org/software/ModemManager/doc/latest/ModemManager/gdbus-org.freedesktop.ModemManager1.Sim.html#gdbus-property-org-freedesktop-ModemManager1-Sim.SimIdentifier>

I couldn’t find anything in the help.

These docs mention the methods (such as sendpin, sendpuk, enablepin, changepin, 
setpreferrednetworks), which are available via mmcli.

It also mentions various properties (such as Active, SimIdentifier, IMSI, …), 
but I can’t find a way to retrieving those via mmcli (except maybe via issue AT 
commands).

org.freedesktop.ModemManager1.Sim: ModemManager Reference Manual 
(www.freedesktop.org)<https://www.freedesktop.org/software/ModemManager/doc/latest/ModemManager/gdbus-org.freedesktop.ModemManager1.Sim.html>

Are these properties easily obtainable via mmcli?  I would think they should 
be, but I can’t find out how.

Thanks,
Brendan.

Re: Wait for SMS messages

[Brendan Simon]

IND.T Classification: Public

From: Dan Williams 
Sent: Thursday, 30 January 2025 3:39 AM

On Tue, 2025-01-28 at 12:05 +, Brendan Simon wrote:
>
> What's the best way to monitor and wait for SMS messages for
> processing?
> I'm using a Debian based system and python3.
> I was thinking of something involving systemd and/or a python package
> such asdbus_next.

With Python we'd typically use the bundled GObject introspection data
to directly work with libmm-glib. There are some examples in MM git:

https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/tree/main/examples?ref_type=heads

I added an SMS watcher example here:

https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/1284

Hopefully that's easy enough to follow, all questions welcome.

It does require a bit of D-Bus knowledge to fully understand the flow,
but even without that you just plug your own code into the SmsWatcher's
show() method and that'll run for any "new" SMS from any modem. I say
"new" in quotes because it'll also print out any messages in the modem
at the time it's run, then wait for new ones from the network or local
addition.

I tried the SMS watcher example.
It seems to work mostly, however in the code snippet below, the new message 
does not appear in the list from list_sysnc(), and therefore the sms object is 
never added to self.messages.
Is this expected or is there something else missing?

What is the purpose of SmsWatcher?  Why do I need to "watch" SMS messages once 
we have processed them with MessagingWatcher?
Is it for things like handling message deletion or other events?

```python
def on_sms_added(self, messaging, path, received):
for sms in self.iface.list_sync():
if sms.get_path() == path:
#>>> NEVER GETS HERE AS THE NEW MESSAGE DOES NOT APPEAR IN THE 
RETURNED LIST OF MESSAGES !!!
# Watch this SMS
self.messages[sms.get_path()] = SmsWatcher(sms)
```

Re: Cinterion PLS63 not showing up as wwan0

[Brendan Simon]

From: Giacinto Cifelli 
Sent: Thursday, 30 January 2025 3:22 PM

Hi Brendan,

On Wed, Jan 29, 2025 at 6:57 AM Brendan Simon
 wrote:
>
> Thanks Dan.
> I am actually using a 5.10 kernel (not 4.19), but still wouldn't have the 
> patches you mention.
> I can try some 6.1 and 6.6 kernel for our platform and see if that helps.
>
> Cheers, Brendan.
>

if i remember correctly, the PLS63/83 has 2 enumerations, one is wwan,
the other one is qmi.
You should check how is your module enumerating with the command AT^SSRVSET.

Ok.  I will check that out the response to that AT command.

With a newer kernel (6.1) I see the device enumerate as wwx00a0c6ee8cc0 (not 
wwan0).
I think this is the new persistent naming scheme.  I'm not used to it and not 
sure how if effects my system, config, etc, but it's looking like it is a wwan 
device.

# ifconfig -a
wwx00a0c6ee8cc0: flags=4098  mtu 1500
   ether 00:a0:c6:ee:8c:c0  txqueuelen 1000  (Ethernet)
   RX packets 0  bytes 0 (0.0 B)
   RX errors 0  dropped 0  overruns 0  frame 0
   TX packets 0  bytes 0 (0.0 B)
   TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Cinterion PLS63 not showing up as wwan0

[Brendan Simon]

IND.T Classification: External

I am using a Debian 10 Buster Linux system with ModemManager 1.10 (yes I know 
it's old, and we have tried Debian 12 Bookwork with MM 1.20) and cannot get a 
Cinterion PLS63 device to connecto the internet.  MM seems happy enough with 
it.  It is detected and I can show status information with mmcli command.

I have successfully connected over many years with this setup using a Quectel 
EC21 modem, but cannot connect with this new Cinterion PLS63 modem.

One difference is that the device seems to show up as a network interface  
enxNN and not wwan0 , which is what the EC21 shows up as.
Is this expected?
Is this the issue?  If so, how can I get it to show up as a wwan0 device?

Some posts mention udev rules and port type hints.  Is this what I should be 
looking at and are there any example or suggested settings for this modem?

I tried using NetworkManger to setup a connection using the enx interface, but 
the nmtui utility did not recognise it.

Thanks,
Brendan.

Wait for SMS messages

[Brendan Simon]

IND.T Classification: Public

What's the best way to monitor and wait for SMS messages for processing?
I'm using a Debian based system and python3.
I was thinking of something involving systemd and/or a python package such as 
dbus_next.

I want to keep it simple, but I want to avoid a polling task and calls to mmcli 
to list messages and detect new ones by comparing previous listing.
I.e. I want a task to sleep, waiting for an SMS message, and wake up when one 
is received so that it can be processed.

Thanks,
Brendan.

Re: Cinterion PLS63 not showing up as wwan0

[Brendan Simon]

IND.T Classification: Public

Thanks Dan.
I am actually using a 5.10 kernel (not 4.19), but still wouldn't have the 
patches you mention.
I can try some 6.1 and 6.6 kernel for our platform and see if that helps.

Cheers, Brendan.


From: Dan Williams 
Sent: Wednesday, 29 January 2025 1:39 AM
To: Brendan Simon ; 
modemmanager-devel@lists.freedesktop.org 

Subject: Re: Cinterion PLS63 not showing up as wwan0

This email originated from EXTERNAL

On Tue, 2025-01-28 at 06:20 +0000, Brendan Simon wrote:
>
> IND.T Classification: External
>
>
>
> I am using a Debian 10 Buster Linux system with ModemManager 1.10
> (yes I know it's old, and we have tried Debian 12 Bookwork with MM
> 1.20) and cannot get a Cinterion PLS63 device to connecto the
> internet.  MM seems happy enough with it.  It is detected and I can
> show status information with mmcli command.
>
>
> I have successfully connected over many years with this setup using a
> Quectel EC21 modem, but cannot connect with this new Cinterion PLS63
> modem.
>
>
> One difference is that the device seems to show up as a network
> interface  enxNN and not wwan0 , which is what the EC21 shows up
> as.
> Is this expected?

No, if the kernel drivers have the right bits.

> Is this the issue?  If so, how can I get it to show up as a
> wwan0 device?

The kernel drivers "tag" the device as a WWAN device instead of a
regular USB Ethernet device, and that's how it gets wwan0.

These patches seems relevant and were merged for the 5.11 kernel:

https://lore.kernel.org/all/20210126044245.8455-1-gciof...@gmail.com/
https://lore.kernel.org/all/20210120045650.10855-1-gciof...@gmail.com/

I think Buster has a 4.19 kernel? I'll bet your kernel doesn't have
those two patches.

Dan

>
>
> Some posts mention udev rules and port type hints.  Is this what I
> should be looking at and are there any example or suggested settings
> for this modem?
>
>
> I tried using NetworkManger to setup a connection using the
> enx interface, but thenmtui utility did not recognise it.
>
>
> Thanks,
> Brendan.

Re: Cinterion PLS63 not showing up as wwan0

[Brendan Simon]

IND.T Classification: External

Sent: Tuesday, 4 March 2025 3:22 PM
To: Giacinto Cifelli 
Cc: Dan Williams ; modemmanager-devel@lists.freedesktop.org 

Subject: Re: Cinterion PLS63 not showing up as wwan0


From: ModemManager-devel  on 
behalf of Brendan Simon 
Sent: Friday, 31 January 2025 10:28 AM
Subject: Re: Cinterion PLS63 not showing up as wwan0

From: Giacinto Cifelli 
Sent: Thursday, 30 January 2025 3:22 PM

Hi Brendan,

On Wed, Jan 29, 2025 at 6:57 AM Brendan Simon
 wrote:
>
> Thanks Dan.
> I am actually using a 5.10 kernel (not 4.19), but still wouldn't have the 
> patches you mention.
> I can try some 6.1 and 6.6 kernel for our platform and see if that helps.
>
> Cheers, Brendan.
>

if i remember correctly, the PLS63/83 has 2 enumerations, one is wwan,
the other one is qmi.
You should check how is your module enumerating with the command AT^SSRVSET.

Ok.  I will check that out the response to that AT command.

With a newer kernel (6.1) I see the device enumerate as wwx00a0c6ee8cc0 (not 
wwan0).
I think this is the new persistent naming scheme.  I'm not used to it and not 
sure how if effects my system, config, etc, but it's looking like it is a wwan 
device.

# ifconfig -a
wwx00a0c6ee8cc0: flags=4098  mtu 1500
   ether 00:a0:c6:ee:8c:c0  txqueuelen 1000  (Ethernet)
   RX packets 0  bytes 0 (0.0 B)
   RX errors 0  dropped 0  overruns 0  frame 0
   TX packets 0  bytes 0 (0.0 B)
   TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The AT command produced an error.  CME Error.

I was able to prevent the persistent name wwx00a0c6ee8cc0 and keeping wwan0 by 
setting the command line arguments to include: net.ifnames=0

# ifconfig -a
wwan0: flags=4098  mtu 1500
   ether 00:a0:c6:ee:8c:c0  txqueuelen 1000  (Ethernet)
   RX packets 0  bytes 0 (0.0 B)
   RX errors 0  dropped 0  overruns 0  frame 0
   TX packets 0  bytes 0 (0.0 B)
   TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

However, this still does not allow ModemManager to detect the Cinterion modem 
as a WWAN device.
I.e. The device does not show up with: mmcli -L

My setup is now Debian 13 Trixie (testing) amd64, Linux kernel 6.12.12, modem 
connected via USB, ModemManager 1.22.0, NetworkManager 1.50.2.

How do I get ModemManager to detect the Cinterion PLS63 modem?

Some debug.

# journalctl -b -u ModemManager.service | grep --color -i 
"wwx\|error\|cinterion"

Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.836551] 
[plugin-manager] task 0,wwx00a0c6ee8cc0: started
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.836563] 
[plugin-manager] task 0,wwx00a0c6ee8cc0: checking with plugin 'cinterion'
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.836584] 
[plugin/cinterion] probing of port wwx00a0c6ee8cc0 deferred until result 
suggested
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.837051] 
[plugin-manager] task 0,ttyACM3: will try with plugin 'cinterion'
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.837226] 
[plugin-manager] task 0,ttyACM3: checking with plugin 'cinterion'
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.837251] 
[plugin/cinterion] probes required for port ttyACM3: 'at'
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.838155] 
[plugin-manager] task 0,ttyACM2: will try with plugin 'cinterion'
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.838242] 
[plugin-manager] task 0,ttyACM2: checking with plugin 'cinterion'
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.838264] 
[plugin/cinterion] probes required for port ttyACM2: 'at'
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.838727] 
[plugin-manager] task 0,ttyACM1: will try with plugin 'cinterion'
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.838814] 
[plugin-manager] task 0,ttyACM1: checking with plugin 'cinterion'
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.838834] 
[plugin/cinterion] probes required for port ttyACM1: 'at'
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.839401] 
[plugin-manager] task 0,ttyACM0: will try with plugin 'cinterion'
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.839493] 
[plugin-manager] task 0,ttyACM0: checking with plugin 'cinterion'
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.839516] 
[plugin/cinterion] probes required for port ttyACM0: 'at'
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.839613] 
[plugin-manager] task 0,wwx00a0c6ee8cc0: deferring support check until result 
suggested
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.839639] 
[plugin-manager] task 0,ttyACM3: found best plugin for port (cinterion)
Mar 04 15:52:56 trixie1 ModemManager[5599]:  [1741063976.839668] 
[plugin-manager] task 0,ttyACM3: found best plugin: cinterion
Mar 04 15:

Re: Cinterion PLS63 not showing up as wwan0

[Brendan Simon]

IND.T Classification: External




From: Giacinto Cifelli 
Sent: Tuesday, 4 March 2025 8:38 PM

> if i remember correctly, the PLS63/83 has 2 enumerations, one is wwan
> the other one is qmi.
> You should check how is your module enumerating with the command AT^SSRVSET.

check this command options on the ATC guide.
As-is for sure it will return an error.
You need something like AT^SSRVSET="cursrvset", or AT^SSRVSET?, ... I
don't remember exactly.

Also, you can check the presence of /dev/cdc-wdm* and lsusb -t for
which drivers are used.

for the device naming, glad that you found by yourself, it has nothing
to do with MM, and in general doesn't matter, either.

Hi Giacinto.

I have resolve this issue thanks to your help 🙏

SerNum Parameter Description - USB Service Set Number
1 (D) CDC4 (USB4) enumerates as ECM devices. All USB devices of the UE 
enumerate with PID 0x0069.
11 CDC4 (USB4) enumerates as specific WWAN device. All USB devices of the UE 
enumerate with PID 0x006F.

Setting SetNum to 11 worked for me.
AT^SSRVSET="actSrvSet",11

USB driver is now qmi_wan instead of cdc_ether.
/dev/cdc-wdm0 is now present 🙂
ModemManger can detect the modem and I can connect to the Internet 🙂


# lsusb
Bus 001 Device 004: ID 1e2d:006f Gemalto M2M GmbH PLSx3

# lsusb -t
/:  Bus 001.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/8p, 480M
|__ Port 002: Dev 004, If 8, Class=Vendor Specific Class, Driver=qmi_wwan, 
480M

# ls -l /dev/cdc*
crw--- 1 root root 180, 0 Mar  5 08:18 /dev/cdc-wdm0

# mmcli -L
/org/freedesktop/ModemManager1/Modem/0 [QUALCOMM INCORPORATED] 0

# mmcli -m 0
  --
  General  |   path: /org/freedesktop/ModemManager1/Modem/0
   |  device id: c38af5b873e196135a88038b9befbdd6586aa400
  --
  Hardware |   manufacturer: QUALCOMM INCORPORATED
   |  model: 0
   |  firmware revision: 
MPSS.JO.2.0.2.c1.1-00149-9607_GENNS_PACK-1.46706.2.53108.3  1  [Dec 15 2023 
06:00:00]
   |   h/w revision: 1
   |  supported: gsm-umts, lte
   |current: gsm-umts, lte
   |   equipment id: 350588282505965
  --
  System   | device: 
/sys/devices/pci:00/:00:0c.0/usb1/1-2
   |physdev: 
/sys/devices/pci:00/:00:0c.0/usb1/1-2
   |drivers: cdc_acm, qmi_wwan
   | plugin: cinterion
   |   primary port: cdc-wdm0
   |  ports: cdc-wdm0 (qmi), ttyACM0 (at), ttyACM1 
(at), ttyACM2 (at),
   | wwp0s12u2i8 (net)
  --
  Status   |   lock: sim-pin2
   | unlock retries: sim-pin (3), sim-puk (10), sim-pin2 (3), 
sim-puk2 (10)
   |  state: connected
   |power state: on
   |access tech: lte
   | signal quality: 100% (recent)
  --

# ifconfig
wwp0s12u2i8: flags=4305  mtu 1500
inet 10.255.0.29  netmask 255.255.255.252  destination 10.255.0.29
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000 
 (UNSPEC)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Re: Cinterion PLS63 not showing up as wwan0

[Brendan Simon]

IND.T Classification: External

From: ModemManager-devel  on 
behalf of Brendan Simon 
Sent: Friday, 31 January 2025 10:28 AM
Subject: Re: Cinterion PLS63 not showing up as wwan0

From: Giacinto Cifelli 
Sent: Thursday, 30 January 2025 3:22 PM

Hi Brendan,

On Wed, Jan 29, 2025 at 6:57 AM Brendan Simon
 wrote:
>
> Thanks Dan.
> I am actually using a 5.10 kernel (not 4.19), but still wouldn't have the 
> patches you mention.
> I can try some 6.1 and 6.6 kernel for our platform and see if that helps.
>
> Cheers, Brendan.
>

if i remember correctly, the PLS63/83 has 2 enumerations, one is wwan,
the other one is qmi.
You should check how is your module enumerating with the command AT^SSRVSET.

Ok.  I will check that out the response to that AT command.

With a newer kernel (6.1) I see the device enumerate as wwx00a0c6ee8cc0 (not 
wwan0).
I think this is the new persistent naming scheme.  I'm not used to it and not 
sure how if effects my system, config, etc, but it's looking like it is a wwan 
device.

# ifconfig -a
wwx00a0c6ee8cc0: flags=4098  mtu 1500
   ether 00:a0:c6:ee:8c:c0  txqueuelen 1000  (Ethernet)
   RX packets 0  bytes 0 (0.0 B)
   RX errors 0  dropped 0  overruns 0  frame 0
   TX packets 0  bytes 0 (0.0 B)
   TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The AT command produced an error.  CME Error.

I was able to prevent the persistent name wwx00a0c6ee8cc0 and keeping wwan0 by 
setting the command line arguments to include: net.ifnames=0

# ifconfig -a
wwan0: flags=4098  mtu 1500
   ether 00:a0:c6:ee:8c:c0  txqueuelen 1000  (Ethernet)
   RX packets 0  bytes 0 (0.0 B)
   RX errors 0  dropped 0  overruns 0  frame 0
   TX packets 0  bytes 0 (0.0 B)
   TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

However, this still does not allow ModemManager to detect the Cinterion modem 
as a WWAN device.
I.e. The device does not show up with: mmcli -L

My setup is now Debian 13 Trixie (testing) amd64, Linux kernel 6.12.12, modem 
connected via USB, ModemManager 1.22.0, NetworkManager 1.50.2.

How do I get ModemManager to detect the Cinterion PLS63 modem?

Requirements for u-blox LARA0-R2 (R280)

[Brendan Simon (eTRIX)]

I'm trying to get a u-blox LARA-R280 device working with my embedded
linux build -- using Linux kernel 4.4.0 (armhf) and Debian Buster (testing).

  * ModemManagerv 1.10.0
  * NetworkManager 1.14.6


ModemManager discovers the device ok, but NetworkManger does not see a
network device (e.g. `cdc-wdm0` which is what I get with a Quectel modem).

# mmcli -L
    /org/freedesktop/ModemManager1/Modem/0 [u-blox] LARA-R280

# mmcli -m 0
  
  General  |    dbus path: /org/freedesktop/ModemManager1/Modem/0
   |    device id: cefae5a09feceda70ab244f864cd3239d518b487
  
  Hardware | manufacturer: u-blox
   |    model: LARA-R280
   | revision: 30.43
   |    supported: gsm-umts, lte
   |  current: gsm-umts, lte
   | equipment id: 357364080026759
  
  System   |   device:
/sys/devices/soc0/amba/e0002000.usb/ci_hdrc.0/usb1/1-1
   |  drivers: cdc_acm
   |   plugin: u-blox
   | primary port: ttyACM0
   |    ports: ttyACM3 (unknown), ttyACM4 (unknown),
ttyACM5 (unknown),
   |   ttyACM0 (at), ttyACM1 (at), ttyACM2 (at)
  
  Status   |   unlock retries: sim-pin (3), sim-pin2 (3), sim-puk
(10), sim-puk2 (10)
   |    state: registered
   |  power state: on
   |  access tech: lte
   |   signal quality: 60% (recent)
  

# nmcli d
DEVICE   TYPE  STATE CONNECTION
eth0 ethernet  connected wired-connection-1
ttyACM0  gsm   disconnected  --
sit0 iptunnel  unmanaged --
tunl0    iptunnel  unmanaged --
lo   loopback  unmanaged --


`nmcli` shows a `ttyACM0` serial device (instead of the network
interface device).  I'm expecting something like `cdc-wdm0`.  Is that a
correct assumption?

I hand to Monkey patch my kernel to work with the Quectel device
(following documents from Quetel), but I can't find any information from
u-blox about kernel driver requirements (other than the device works
with standard linux drivers).

Any ideas what drivers I need configured/enabled/patched to get the
LARA-R2 module to enumerate as a network device?

Thanks,
Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Requirements for u-blox LARA0-R2 (R280)

[Brendan Simon (eTRIX)]

On 26/4/19 4:57 pm, Lars Melin wrote:
> On 4/26/2019 08:00, Brendan Simon (eTRIX) wrote:
>
>> # nmcli d
>> DEVICE   TYPE  STATE CONNECTION
>> eth0 ethernet  connected wired-connection-1
>> ttyACM0  gsm   disconnected  --
>> sit0 iptunnel  unmanaged --
>> tunl0    iptunnel  unmanaged --
>> lo   loopback  unmanaged --
>>
>>
>> `nmcli` shows a `ttyACM0` serial device (instead of the network
>> interface device).  I'm expecting something like `cdc-wdm0`.  Is that
>> a correct assumption?
>
> No it is a wrong assumption, there are only cdc_acm serial interfaces
> in this device, no net interfaces.

Thanks Lars.  It works fine on an Ubuntu VM (18.10 Cosmic) and I can see
there is no `wwan` network interface, just the cdc_acm serial interfaces.

Ubuntu is using modemmanager v1.8.2 and network-manager 1.12.4 and
kernel 4.18.0.

My Debian embedded testing system is using modemmanager v1.10.0,
network-manager 1.14.6 and kernel 4.4.0 (custom build, armhf).

Since MM 1.14.6 communicates ok with the modem (i.e. mmcli gives
sensible output), am I safe to assume all the kernel support is there to
bring up the modem via Network Manager?  i.e. can I rule out the 4.4.0
kernel as a source of the problem?

Thanks, Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

u-blox LARA0-R2 (R280) not worrking with MM 1.10

[Brendan Simon (eTRIX)]

I can't get the u-blox LARA R2 device working with ModemManager 1.10.

I've tried a Debian Buster (aka Testing) distro that uses ModemManager
1.10 (and kernel 4.19).  The serial devices are present but `mmcli -L`
does not show any modems.

I've also tried the latest Ubuntu 19.04 Disco release (VM image from
osboxes.org).  It also has ModemManager 1.10 (and kernel 5.0.0) and it
also does not work.  i.e. the serial devices are present but `mmcli -L`
does not show any modems.

The only system that I've got to work is Ubuntu 18.10 Cosmic, which uses
ModemManager 1.8.2 (and kernel 4.18.0).

My guess is that something is broken in ModemManager 1.10 (or some
related package or dependency).  Can someone confirm that please.  Is
there anything I can do to test or provide debug info for this.  I need
to get this working with Debian Buster and MM 1.10.

Thanks,
Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: u-blox LARA0-R2 (R280) not worrking with MM 1.10

[Brendan Simon (eTRIX)]

On 29/4/19 2:57 pm, Lars Melin wrote:
> On 4/29/2019 11:12, Brendan Simon (eTRIX) wrote:
>> I can't get the u-blox LARA R2 device working with ModemManager 1.10.
>>
>> I've tried a Debian Buster (aka Testing) distro that uses
>> ModemManager 1.10 (and kernel 4.19).  The serial devices are present
>> but `mmcli -L` does not show any modems.
>>
>> I've also tried the latest Ubuntu 19.04 Disco release (VM image from
>> osboxes.org).  It also has ModemManager 1.10 (and kernel 5.0.0) and
>> it also does not work.  i.e. the serial devices are present but
>> `mmcli -L` does not show any modems.
>>
>> The only system that I've got to work is Ubuntu 18.10 Cosmic, which
>> uses ModemManager 1.8.2 (and kernel 4.18.0).
>>
>> My guess is that something is broken in ModemManager 1.10 (or some
>> related package or dependency).  Can someone confirm that please. Is
>> there anything I can do to test or provide debug info for this. I
>> need to get this working with Debian Buster and MM 1.10.
>>
>> Thanks,
>> Brendan.
>
> Check your dmesg log for creation of ttyACM devices right after the
> LARA R2 is found and probed on the USB bus, you should get 5 of them.
>
> If not then check that cdc_acm is loaded (lsmod) it may have been
> compiled into the kernel in the working system but may have been
> compiled as a module in the non-working systems in which case you have
> to manually load it with "modprobe cdc_acm".
>
> When you have the ttyACM devices and it still doesn't work then is the
> time to check what modemmanager does, the kernel or networkmanager is
> the least likely to be the cause of your problem. 

Thanks Lars.

On Ubuntu 18.10 Cosmic (MM 1.8.2) I get the following.

# ls /dev/ttyACM*
/dev/ttyACM0  /dev/ttyACM2  /dev/ttyACM4
/dev/ttyACM1  /dev/ttyACM3  /dev/ttyACM5

# lsmod | grep acm
cdc_acm    32768  4

# mmcli -L

Found 1 modems:
    /org/freedesktop/ModemManager1/Modem/1 [u-blox] LARA-R280

# nmcli d
DEVICE   TYPE  STATE CONNECTION
enp0s3   ethernet  connected Wired connection 1
ttyACM0  gsm   disconnected  --
lo   loopback  unmanaged --

# nmcli d connect ttyACM0
Device 'ttyACM0' successfully activated with
'f1ec8522-2a76-4e31-938d-87101f2aeb27'.

# lsmod | grep acm
cdc_acm    32768  5


On Ubuntu 19.04 Cosmic (MM 1.10.1) I get the following.

# ls -l /dev/ttyACM*
crw-rw 1 root dialout 166, 0 Apr 29 03:02 /dev/ttyACM0
crw-rw 1 root dialout 166, 1 Apr 29 03:02 /dev/ttyACM1
crw-rw 1 root dialout 166, 2 Apr 29 03:02 /dev/ttyACM2
crw-rw 1 root dialout 166, 3 Apr 29 03:02 /dev/ttyACM3
crw-rw 1 root dialout 166, 4 Apr 29 03:02 /dev/ttyACM4
crw-rw 1 root dialout 166, 5 Apr 29 03:02 /dev/ttyACM5

# lsmod | grep acm
cdc_acm    32768  0

# mmcli -L
No modems were found

# dmesg | grep acm
[  557.815621] cdc_acm 1-1:1.0: ttyACM0: USB ACM device
[  557.823421] cdc_acm 1-1:1.2: ttyACM1: USB ACM device
[  557.831399] cdc_acm 1-1:1.4: ttyACM2: USB ACM device
[  557.840190] cdc_acm 1-1:1.6: ttyACM3: USB ACM device
[  557.848698] cdc_acm 1-1:1.8: ttyACM4: USB ACM device
[  557.856181] cdc_acm 1-1:1.10: ttyACM5: USB ACM device


# journalctl | grep -i modemmanager
Apr 29 03:09:10 osboxes ModemManager[631]:   [device
/sys/devices/pci:00/:00:0b.0/usb1/1-1] creating modem with
plugin 'u-blox' and '6' ports
Apr 29 03:09:10 osboxes ModemManager[631]:   Modem for device
'/sys/devices/pci:00/:00:0b.0/usb1/1-1' successfully created
Apr 29 03:09:16 osboxes ModemManager[631]:   (tty/ttyACM1) at
port timed out 2 consecutive times
Apr 29 03:09:19 osboxes ModemManager[631]:   (tty/ttyACM1) at
port timed out 3 consecutive times
Apr 29 03:09:22 osboxes ModemManager[631]:   (tty/ttyACM1) at
port timed out 4 consecutive times
Apr 29 03:09:25 osboxes ModemManager[631]:   (tty/ttyACM1) at
port timed out 5 consecutive times
Apr 29 03:09:28 osboxes ModemManager[631]:   (tty/ttyACM1) at
port timed out 6 consecutive times
Apr 29 03:09:31 osboxes ModemManager[631]:   (tty/ttyACM1) at
port timed out 7 consecutive times
Apr 29 03:09:33 osboxes ModemManager[631]:   (tty/ttyACM1) at
port timed out 8 consecutive times
Apr 29 03:09:34 osboxes ModemManager[631]:   (tty/ttyACM1) at
port timed out 9 consecutive times
Apr 29 03:09:35 osboxes ModemManager[631]:  (tty/ttyACM1) at
port timed out 10 consecutive times, marking modem '(null)' as invalid
Apr 29 03:09:35 osboxes ModemManager[631]:   Modem couldn't be
in

Re: u-blox LARA0-R2 (R280) not worrking with MM 1.10

[Brendan Simon (eTRIX)]

Hi Aleksander,

Unfortunately I never got around to trying this before the loan dev kit
had to be returned.

Regards,
Brendan.



On 16/5/19 1:42 am, Aleksander Morgado wrote:
> Hey Brendan,
>
> Looking at the tags we set, we're just ignoring the ports we don't
> want to use or we don't support, but we're not explicitly specifying
> the purpose of each of the ports:
>
> # LARA-R2 port types
> #  ttyACM0 (if #0): primary
> #  ttyACM1 (if #2): secondary
> #  ttyACM2 (if #4): tertiary
> #  ttyACM3 (if #6): GNSS Tunneling (ignore)
> #  ttyACM4 (if #8): SIM Access Profile (ignore)
> #  ttyACM5 (if #10): Primary Log for diagnostics (ignore)
> ATTRS{idVendor}=="1546", ATTRS{idProduct}=="110a",
> ENV{.MM_USBIFNUM}=="06", ENV{ID_MM_PORT_IGNORE}="1"
> ATTRS{idVendor}=="1546", ATTRS{idProduct}=="110a",
> ENV{.MM_USBIFNUM}=="08", ENV{ID_MM_PORT_IGNORE}="1"
> ATTRS{idVendor}=="1546", ATTRS{idProduct}=="110a",
> ENV{.MM_USBIFNUM}=="0a", ENV{ID_MM_PORT_IGNORE}="1"
>
> Could you try whether flagging ttyACM0 as primary, ttyACM1 as data,
> and ttyACM2 as ignored helps?
>
> E.g., something like this in /lib/udev/rules.d/77-mm-ublox-port-types.rules:
> ATTRS{idVendor}=="1546", ATTRS{idProduct}=="110a",
> ENV{.MM_USBIFNUM}=="06", ENV{ID_MM_PORT_TYPE_AT_PRIMARY}="1"
> ATTRS{idVendor}=="1546", ATTRS{idProduct}=="110a",
> ENV{.MM_USBIFNUM}=="08", ENV{ID_MM_PORT_TYPE_AT_PPP}="1"
> ATTRS{idVendor}=="1546", ATTRS{idProduct}=="110a",
> ENV{.MM_USBIFNUM}=="0a", ENV{ID_MM_PORT_IGNORE}="1"
>
> Once you have added the rules in the file, run "sudo udevadm control
> --reload && sudo udevadm trigger", or reboot the system.
>


___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Configuration file for ModemManager

[Brendan Simon (eTRIX)]

Hi MM devs,

*Is there a configuration file for ModemManager?*

I'm using Debian Buster.  With Network Manager there is the following.

/etc/NetworkManager/NetworkManager.conf
/etc/NetworkManager/conf.d/

I can control the log level of NetworkManager by adding a file in the 
`conf.d/` directory.


However I cannot find a way of changing the logging level of 
ModemManager, that is easy to do and system independent.
The only way I can do it is by modifying the systemd service script 
provided by Debian.

Well, copy that script to /etc/systemd/system/ and modify it.

Still I prefer to not have to modify systemd scripts directly.

*Is there anyway to control the logging level for ModemManager with a 
user configuration files ??*


Thanks, Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Restrict modem (EC21) one of 3G or 4G - ModemManager 1.10.0 (Debian Buster)

[Brendan Simon (eTRIX)]

I'm using a Quectel EC21 modem on a Debian Buster Linux system (using 
modemmanager 1.10.0).


I want to force it to one of 3G or 4G to stop it changing/swapping 
between the two.


I've tried using the `mmcli -m 0 --set-allowed-modes=3g
`.  mmcli seems happy with that.

   # mmcli -m 0
  
  Modes    |    supported: allowed: 3g; preferred: none
   |   allowed: 4g; preferred: none
   |   allowed: 3g, 4g; preferred: 3g
   |   allowed: 3g, 4g; preferred: 4g
   |  current: *allowed: 3g; preferred: none*
  


and the modem connects using 3G (umts).

   
  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: *umts*
   |   signal quality: 57% (recent)
  


However, some time later it swaps over to 4G (lte)

   
  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 <<< 4G !!!*
   |   signal quality: 63% (recent)
  


Have I got the right expectations of the `--set-allowable-modes` feature?

Is there something else I need to do?

Does this feature work with MM 1.10.0 ?
I did see some forum discussions about it not working and also patches, 
but I can't quite figure out whether that was pre or post v1.10.0.


There is a backport of MM 1.14.0 which I could try.  Is a later version 
likely to help?


The MM changelog/news file doesn't seem to suggest there is an issue or fix.

I did find this in the git commits, but not sure if it is relevant or not.

   *policy: Use SetCurrentModes instead of SetAllowedModes

   *
   There is no DBus API for SetAllowedModes, but only for
   SetCurrentModes. (cherry picked from commit
   e21e7ddfae3d68418ad9c6f4d589b720b7b85b8b
   
)

   author   Mohammed Sadiq 2019-09-24 19:10:29 
+0530
   committerAleksander Morgado  2019-09-25
   13:38:50 +0200
   commit   b34203b1b8e8676bb686f0c33ba3104c8577b855
   

   (patch
   
)

   tree 80a501b5eae527399c783a2c09e84e1d5b86fe02
   


   parent   00c0911cb2e0e4558d98f4fe5085cd2be89f9ec3
   

   (diff
   
)




Thanks,
Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Restrict modem (EC21) one of 3G or 4G - ModemManager 1.10.0 (Debian Buster)

[Brendan Simon (eTRIX)]

I'm using a Quectel EC21 modem on a Debian Buster Linux system (using 
modemmanager 1.10.0).


I want to force it to one of 3G or 4G to stop it changing/swapping 
between the two.


I've tried using the `mmcli -m 0 --set-allowed-modes=3g
`.  mmcli seems happy with that.

   # mmcli -m 0
  
  Modes    |    supported: allowed: 3g; preferred: none
   |   allowed: 4g; preferred: none
   |   allowed: 3g, 4g; preferred: 3g
   |   allowed: 3g, 4g; preferred: 4g
   |  current: *allowed: 3g; preferred: none*
  


and the modem connects using 3G (umts).

   
  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: *umts*
   |   signal quality: 57% (recent)
  


However, some time later it swaps over to 4G (lte)

   
  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 <<< 4G !!!*
   |   signal quality: 63% (recent)
  


Have I got the right expectations of the `--set-allowable-modes` feature?

Is there something else I need to do?

Does this feature work with MM 1.10.0 ?
I did see some forum discussions about it not working and also patches, 
but I can't quite figure out whether that was pre or post v1.10.0.


There is a backport of MM 1.14.0 which I could try.  Is a later version 
likely to help?


The MM changelog/news file doesn't seem to suggest there is an issue or fix.

I did find this in the git commits, but not sure if it is relevant or not.

   *policy: Use SetCurrentModes instead of SetAllowedModes

   *
   There is no DBus API for SetAllowedModes, but only for
   SetCurrentModes. (cherry picked from commit
   e21e7ddfae3d68418ad9c6f4d589b720b7b85b8b
   
)

   author   Mohammed Sadiq 2019-09-24 19:10:29 
+0530
   committerAleksander Morgado  2019-09-25
   13:38:50 +0200
   commit   b34203b1b8e8676bb686f0c33ba3104c8577b855
   

   (patch
   
)

   tree 80a501b5eae527399c783a2c09e84e1d5b86fe02
   


   parent   00c0911cb2e0e4558d98f4fe5085cd2be89f9ec3
   

   (diff
   
)




Thanks,
Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Restrict modem (EC21) one of 3G or 4G - ModemManager 1.10.0 (Debian Buster)

[Brendan Simon (eTRIX)]

Hi Aleksander,

On 18/08/2020 5:43 pm, Aleksander Morgado wrote:

On Tue, Aug 18, 2020 at 8:16 AM Brendan Simon (eTRIX)
 wrote:

I'm using a Quectel EC21 modem on a Debian Buster Linux system (using 
modemmanager 1.10.0).


Please note, MM 1.10.0 is a very very old release, no longer
supported, and it's not even the last one inthe 1.10.x series...


Fair enough, but 1.10.0 is comes with Debian Buster, which is the latest 
Stable release of Debian.  However there is a backport of 1.14, from the 
Unstable (next release) distro, for Buster.



I want to force it to one of 3G or 4G to stop it changing/swapping between the 
two.

I've tried using the `mmcli -m 0 --set-allowed-modes=3g
`.  mmcli seems happy with that.

However, some time later it swaps over to 4G (lte)

   
   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<<< 4G !!!
|   signal quality: 63% (recent)
   


Have I got the right expectations of the `--set-allowable-modes` feature?

Is there something else I need to do?


This may be a known issue with QMI modems where the internal network
registration attempt is done with "QMI NAS Register In Network"; this
command not only registers in network, it also makes the access tech
preference fallback to "any", and MM doesn't consider that in its API.

There is a recent patch to avoid this, by avoiding the use of "NAS
Register in Network" and use "NAS Set System Selection Preference"
instead: 
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/c70b3557184fdf1472ff0cb36e9fd937cc7f9024

That patch is not yet in any release, though, not even in 1.14.0. I'll
backport it to the 1.14.x branch so that it gets into 1.14.2.

You can confirm that this issue is happening to you by running this
command once the tech went back to the one you didn't want:
$ qmicli -d /dev/cdc-wdm0 -p --nas-get-system-selection-preference


Here is the output.

# qmicli -d /dev/cdc-wdm0 -p --nas-get-system-selection-preference
[/dev/cdc-wdm0] Successfully got system selection preference
    Emergency mode: 'no'
    Mode preference: 'umts, lte'
    Band preference: 'wcdma-2100, wcdma-850-us'
    LTE band preference: '1, 3, 5, 7, 28'
    TD-SCDMA band preference: '(null)'
    Roaming preference: 'any'
    Network selection preference: 'automatic'
    Service domain preference: 'cs-ps'
    GSM/WCDMA acquisition order preference: 'wcdma'
    Acquisition order preference: lte, umts, gsm, td-scdma, 
cdma-1x, cdma-1xevdo


What are the key indicators that confirm the issue?
    Network selection preference: 'automatic'???
    Acquisition order preference: lte, umts, gsm, td-scdma, 
cdma-1x, cdma-1xevdo???


Hopefully 1.14.2 is not far away and hopefully it will be backported for 
Debian Buster quickly :)


Thanks, Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Restrict modem (EC21) one of 3G or 4G - ModemManager 1.10.0 (Debian Buster)

[Brendan Simon (eTRIX)]

On 18/08/2020 6:27 pm, Aleksander Morgado wrote:

Hey,


I'm using a Quectel EC21 modem on a Debian Buster Linux system (using 
modemmanager 1.10.0).


Please note, MM 1.10.0 is a very very old release, no longer
supported, and it's not even the last one inthe 1.10.x series...

Fair enough, but 1.10.0 is comes with Debian Buster, which is the latest
Stable release of Debian.  However there is a backport of 1.14, from the
Unstable (next release) distro, for Buster.


1.10.0 was released in 2019-01-17, and after that there have been 4
new updates in the 1.10.x series (1.10.2 on 2019-06-10, 1.10.4 on
2019-07-04, 1.10.6 on 2019-09-12, 1.10.8 on 2019-10-30. Then we have
had the whole 1.12.x series up and running (7 releases); 1.12.0 was
released on 2019-11-06 and the last 1.12.12 was released on
2020-06-23. 1.14.0 was released on 2020-06-23. You should probably
poke Debian Buster packagers of ModemManager... they are 12 releases
late in their latest stable release ;)


I guess it's a policy thing with Debian, where they choose stability 
over the latest and greatest, once a new distro is released.  All new 
development goes into the unstable distro, with backports from unstable 
to stable when necessary.


Since they have a backport for mm 1.14 I can't be critical of Debian 
being out of date (and I'm someone who tends to be lured by the latest 
and greatest shiny things ;-) )



This may be a known issue with QMI modems where the internal network
registration attempt is done with "QMI NAS Register In Network"; this
command not only registers in network, it also makes the access tech
preference fallback to "any", and MM doesn't consider that in its API.

There is a recent patch to avoid this, by avoiding the use of "NAS
Register in Network" and use "NAS Set System Selection Preference"
instead: 
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/c70b3557184fdf1472ff0cb36e9fd937cc7f9024

That patch is not yet in any release, though, not even in 1.14.0. I'll
backport it to the 1.14.x branch so that it gets into 1.14.2.

You can confirm that this issue is happening to you by running this
command once the tech went back to the one you didn't want:
$ qmicli -d /dev/cdc-wdm0 -p --nas-get-system-selection-preference

Here is the output.

# qmicli -d /dev/cdc-wdm0 -p --nas-get-system-selection-preference
[/dev/cdc-wdm0] Successfully got system selection preference
  Emergency mode: 'no'
  Mode preference: 'umts, lte'
  Band preference: 'wcdma-2100, wcdma-850-us'
  LTE band preference: '1, 3, 5, 7, 28'
  TD-SCDMA band preference: '(null)'
  Roaming preference: 'any'
  Network selection preference: 'automatic'
  Service domain preference: 'cs-ps'
  GSM/WCDMA acquisition order preference: 'wcdma'
  Acquisition order preference: lte, umts, gsm, td-scdma,
cdma-1x, cdma-1xevdo

What are the key indicators that confirm the issue?
  Network selection preference: 'automatic'???
  Acquisition order preference: lte, umts, gsm, td-scdma,
cdma-1x, cdma-1xevdo???


Mode Preference (umts + lte) already tells you that the setting was
reseted (assuming you requested 3G-only).
The SSSP patch in network registration will very very likely solve
your problems.


ok.  I will attempt one of the following.
- try to apply the patch to debian buster sources (1.10.0) and rebuild a 
new package.
- try to apply the patch to debian buster backport sources (1.14.0) and 
rebuild a new package.
- wait for a 1.14.2 release and poke the debian backport maintainer to 
generate a new release.


Thanks, Brendan.


___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Restrict modem (EC21) one of 3G or 4G - ModemManager 1.10.0 (Debian Buster)

[Brendan Simon (eTRIX)]

On 18/08/2020 8:59 pm, Brendan Simon (eTRIX) wrote:

On 18/08/2020 6:27 pm, Aleksander Morgado wrote:

This may be a known issue with QMI modems where the internal network
registration attempt is done with "QMI NAS Register In Network"; this
command not only registers in network, it also makes the access tech
preference fallback to "any", and MM doesn't consider that in its API.

There is a recent patch to avoid this, by avoiding the use of "NAS
Register in Network" and use "NAS Set System Selection Preference"
instead: 
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/c70b3557184fdf1472ff0cb36e9fd937cc7f9024


That patch is not yet in any release, though, not even in 1.14.0. I'll
backport it to the 1.14.x branch so that it gets into 1.14.2.


So the 64 million dollar question is when is 1.14.2 likely to be released ?

I don't even see a 1.14.1 in the `mm-1-14` branch, apart from the 
post-release version bump.


Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Restrict modem (EC21) one of 3G or 4G - ModemManager 1.10.0 (Debian Buster)

[Brendan Simon (eTRIX)]

On 19/08/2020 2:13 am, Aleksander Morgado wrote:

This may be a known issue with QMI modems where the internal network
registration attempt is done with "QMI NAS Register In Network"; this
command not only registers in network, it also makes the access tech
preference fallback to "any", and MM doesn't consider that in its API.

There is a recent patch to avoid this, by avoiding the use of "NAS
Register in Network" and use "NAS Set System Selection Preference"
instead: 
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/c70b3557184fdf1472ff0cb36e9fd937cc7f9024

That patch is not yet in any release, though, not even in 1.14.0. I'll
backport it to the 1.14.x branch so that it gets into 1.14.2.


So the 64 million dollar question is when is 1.14.2 likely to be released ?


Sometime in the next few weeks I'd say.


So it's been a while, but I now have MM 1.14.2 installed on my embedded 
system via Debian Buster Backports repo.


I can successfully set the allowed mode to "3G" and get a UMTS connection.

*    mmcli -m 0 --set-allowed-modes="3G"*

However, if I try to lock to 4G the connection never succeeds.
**
    mmcli -m 0 --set-allowed-modes="4G"**

The only way I can get an LTE connection is with the following.
**
    mmcli -m 0 --set-allowed-modes="3G|4G" --set-preferred-mode=4G**

*I presume this is a bug?  But maybe there is something else going on**?**
**Any ideas or suggestions to get an LTE connection with setting 4G as 
the only allowed mode?*


Also, I've just noticed that 1.14.6 has just hit the Buster Backport 
repo.  I'm not sure if that will help or not, but I don't see anything 
in the NEWS file that would suggest a change in this area.


https://github.com/freedesktop/ModemManager/blob/mm-1-14/NEWS

Thanks, Brendan.



___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Restrict modem (EC21) one of 3G or 4G - ModemManager 1.10.0 (Debian Buster)

[Brendan Simon (eTRIX)]

*RESEND**
*
On 21/10/2020 3:59 pm, Brendan Simon (eTRIX) wrote:

On 19/08/2020 2:13 am, Aleksander Morgado wrote:

There is a recent patch to avoid this, by avoiding the use of "NAS
Register in Network" and use "NAS Set System Selection Preference"
instead:https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/c70b3557184fdf1472ff0cb36e9fd937cc7f9024
So it's been a while, but I now have MM 1.14.2 installed on my 
embedded system via Debian Buster Backports repo.


I can successfully set the allowed mode to "3G" and get a UMTS connection.

*    mmcli -m 0 --set-allowed-modes="3G"*

However, if I try to lock to 4G the connection *never succeeds*.
**
    mmcli -m 0 --set-allowed-modes="4G"**

The only way I can get an LTE connection is with the following.
**
    mmcli -m 0 --set-allowed-modes="3G|4G" --set-preferred-mode=4G**

*Is this a bug?  Maybe there is something else going on**?**
**Any ideas or suggestions to get an LTE connection with setting 4G as 
the only allowed mode?*


___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

set-allowed-modes="4G" not working

[Brendan Simon (eTRIX)]

I am using MM 1.14.6 (from Deiban buster-backports) with Quectel EC21 (qmi).

I can successfully set the allowed mode to "3G" and get a UMTS connection :)

*    mmcli -m 0 --set-allowed-modes="3G"*

However, if I try to lock to 4G the connection *never succeeds* :(
**
    mmcli -m 0 --set-allowed-modes="4G"**

The only way I can get an LTE connection is with the following.
**
    mmcli -m 0 --set-allowed-modes="3G|4G" --set-preferred-mode=4G**

*Is this a bug?*

*Is there any other info I can provide to help resolve this so I can use:

    mmcli -m 0 --set-allowed-modes="4G"***

Thanks, Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Quectel EC21, Debian Jessie, kernel 4.4 (patched)

[Brendan Simon (SEPL)]

I have a embedded linux system, which has been used with a Quectel UC20
device without any issues, but moving to the Quectel EC21 is proving
problematic.

Setup is:

Zynq 7000 ARM SOC
EC21 dev-kit (connected via USB)
Analog Devices linux kernel 4.4 -- monkey patched for EC21 using:


https://www.quectel.com/UploadImage/Downlad/Quectel_WCDMA

Re: [SOLVED] Quectel EC21, Debian Jessie, kernel 4.4 (patched)

[Brendan Simon (eTRIX)]

Date: Fri, 31 Aug 2018 11:28:47 +0200
From: Aleksander Morgado 
Subject: Re: Quectel EC21, Debian Jessie, kernel 4.4 (patched)

On Fri, Aug 31, 2018 at 9:24 AM, Brendan Simon (SEPL)
 wrote:

After the patches were applied, the device is recognise on the USB bus and
MM also recongises the modem.  However I'm getting a failed status of SIM
not found ("sim-missing"), but the SIM is present the dev-kit is known to
work using a Windows box (i.e. gets an IP address from the 4G service).

In linux, after power up, MM shows the "sim-missing" failure reason.

I believe that is just because you're using an ancient modemmanager
version, and the new "UIM" support isn't implemented in MM 1.4.0.
Could you update to MM 1.8? It will be totally compatible API-wise.


Interestingly, after I press the reset button on the dev-kit, MM recognises
a new modem and shows a "registered" status.

I system now recognises the modem (/dev/cdc-wdm0 is registered as well as
some /dev/ttyUSB* devices).

However, nmcli shows the device as a ttyUSB instead of cdc-wdm0 !!  Looking
at mmcli outupt, it seems the "primary port" changes from "cdc-wdm0" to
"ttyUSB8".

Is this normal?  Can I force it to only use cdc-wdm?

That may be because the QMI port isn't responding timely after the
reset. Again, I believe this would be solved with newer MM/libqmi.



Why does the SIM get recognised after pressing the reset button and using
the ttyUSB interface, and not recongised after powerup and using the
cdc-wdm0 interface?

I also tried connecting the dev-kit to a Debian 9 VM, but I couldn't get MM
to recognise it at all.  The ttyUSB and cdc-wdm0 interfaces were present,
but "mmcli -L" shows nothing ("No modems found")

Could this be related or is it a different problem altogether?

How can I get MM to recognise the modem in the Debian 9 setup?

linux kernel 4.9.65-3
modemmanager 1.6.4-1
network-manager  1.6.2-3


This may also be due to timing in the QMI port when it boots, maybe
we're not waiting enough. I'd suggest you try with the latest MM 1.8
if possible.


I couldn't get the modem to attach to my VirtualBox system, so I ditched 
that (will try a Live CD at some point).  Instead I created Debian 9 
(Stretch) and Debian 10 (Buster) root filesystems for my embedded device.


Debian 10 (Buster) worked ok and I could get a connection to the 
Internet :)  It uses modemmanager 1.7.990 (if that's a real version 
number?  I assume it's 1.8 or near enough) and network-manager 1.12.2


Debian 9 (Stretch) gave the same symptoms as Debian 8 (Jessie). Debian 9 
uses modemmanager 1.6.4 and Debian 8 uses 1.4.0.


So my problem is solved if I want to migrate to Debian 10 (Buster), 
which is still in development (due for release early/mid 2019), or 
unless I can get a backport to Debian 9 (Stretch).


Thanks, Brendan.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Configuration for Quectel 3G and 4G modem

[Brendan Simon (eTRIX)]

I have a linux filesystem (Debian based) for an embedded board which
uses a Quectel UC20 3G modem via NetworkManager/ModemManager.

I want to upgrade to use a Quectel EC21 4G modem and want to know if I
can use the same "system-connections" configuration file for both
modems.  e.g. so that same software can run on new and old hardware - or
do I have to have separate config/connection files for each modem?

My 3G configuration looks like this:

id=telstra-mobile-broadband-1
uuid=----
type=gsm
permissions=user:root:;
autoconnect=true

[gsm]
number=*99#
password-flags=1
apn-telstra.extranet

[ipv4]
method=auto

[serial]
baud=115200


Should this same config file work with a 4G modem (EC21) ?

Can I have the one configuation file that will work on 4G and 3G (e.g.
if only 3G is available).  I'm *assuming* yes.  If so, how to configure it.

And 3G fallback also.  Is there anything special I need to do in
configuration, or will ModemManager just wield its magic.

Thanks,
Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Can't get Quectel UC20 modem working on Embedded Board

[Brendan Simon (eTRIX)]

Hi,

Not sure if this the best forum to ask questions regarding MM
configuration, etc.  I hope so.  If not please refer me to appropriate
forums.

I have a Quectel UC20 gsm modem.  I got it working under Debian Jessie
on my MacBook (using VirtualBox).  It all seem to go well and had no
problems getting it to work (well, after I unloaded the option driver,
as the Quectel documentation only specifies the multiple tty method to
access the modem).

Now I have installed the same modem (on an evaluation board) to my
embedded arm board (Digilent ZedBoard with Xilinx Zynq dual ARM-A9 SOC),
also running Debian Jessie.  It's conncected via a USB OTG port.  It
shows up with lsusb and also the /dev/cdc-wdm0 entry is populated.  MM
can see the device with 'mmcli -L' and 'mmcli -m 0' reports a bunch of
information, so everything looks fine as far as detecting and
communicating with the device.

However, I just can't get it to connect to my ISP.  It works ok on the
full Debian Jessie system, but not on the ZedBoard.
I copied the /etc/NetworkManager/system-connections/ file from
the VB system.  I presume that is ok and MM should work.

I thought I would try creating a new connection, but I can't find a way
of doing this from the cli.  nm-connection-editor is gnome app and I
don't have gnome installed on my embedded board.  I tried nmtui,
nmtui-edit, nmtui-connect, but there are no options to add a Mobile
Broadband connection as there is with nm-connection-editor.

Is there a nice/easy way of adding a new Mobile Broadband connection
with the cli tools ?

# cat /etc/NetworkManager/system-connections/Telstra\ Telstra\
\(Next\ G\)\ 1
[connection]
id=Telstra Telstra (Next G) 1
uuid=5ee505f2-e161-436b-9b00-b36cab43ebfc
type=gsm

[gsm]
number=*99#
password-flags=1
apn=telstra.internet
network-type=4

[ipv6]
method=auto

[ipv4]
method=auto

[serial]
baud=115200


# lsmod
Module  Size  Used by
cp210x  7582  0
qmi_wwan   10608  0
cdc_wdm 8788  2 qmi_wwan
usbnet 17174  1 qmi_wwan
mii 3417  1 usbnet
ipv6  262886  24


# cat /boot/config-4.0.0-g0fa909f-dirty | grep -v '#' | grep
'WWAN\|QMI\|USB_SERIAL\|PPP\|QUALCOM'
CONFIG_NET_VENDOR_QUALCOMM=y
CONFIG_PPP=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_FILTER=y
CONFIG_PPP_MPPE=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPPOE=m
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_USB_NET_QMI_WWAN=m
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_CP210X=m
CONFIG_USB_SERIAL_FTDI_SIO=y
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_QCAUX=m
CONFIG_USB_SERIAL_QUALCOMM=m
CONFIG_USB_SERIAL_WWAN=m
CONFIG_USB_SERIAL_OPTION=m


Thanks, Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: Can't get Quectel UC20 modem working on Embedded Board

[Brendan Simon (eTRIX)]

More info below.

On 12/12/2015 10:53 PM, Brendan Simon (eTRIX) wrote:
> Hi,
>
> Not sure if this the best forum to ask questions regarding MM
> configuration, etc.  I hope so.  If not please refer me to appropriate
> forums.
>
> I have a Quectel UC20 gsm modem.  I got it working under Debian Jessie
> on my MacBook (using VirtualBox).  It all seem to go well and had no
> problems getting it to work (well, after I unloaded the option driver,
> as the Quectel documentation only specifies the multiple tty method to
> access the modem).
>
> Now I have installed the same modem (on an evaluation board) to my
> embedded arm board (Digilent ZedBoard with Xilinx Zynq dual ARM-A9
> SOC), also running Debian Jessie.  It's conncected via a USB OTG
> port.  It shows up with lsusb and also the /dev/cdc-wdm0 entry is
> populated.  MM can see the device with 'mmcli -L' and 'mmcli -m 0'
> reports a bunch of information, so everything looks fine as far as
> detecting and communicating with the device.
>
> However, I just can't get it to connect to my ISP.  It works ok on the
> full Debian Jessie system, but not on the ZedBoard.
> I copied the /etc/NetworkManager/system-connections/ file from
> the VB system.  I presume that is ok and MM should work.
>
> I thought I would try creating a new connection, but I can't find a
> way of doing this from the cli.  nm-connection-editor is gnome app and
> I don't have gnome installed on my embedded board.  I tried nmtui,
> nmtui-edit, nmtui-connect, but there are no options to add a Mobile
> Broadband connection as there is with nm-connection-editor.
>
> Is there a nice/easy way of adding a new Mobile Broadband connection
> with the cli tools ?
>
> # cat /etc/NetworkManager/system-connections/Telstra\ Telstra\
> \(Next\ G\)\ 1
> [connection]
> id=Telstra Telstra (Next G) 1
> uuid=5ee505f2-e161-436b-9b00-b36cab43ebfc
> type=gsm
>
> [gsm]
> number=*99#
> password-flags=1
> apn=telstra.internet
> network-type=4
>
> [ipv6]
> method=auto
>
> [ipv4]
> method=auto
>
> [serial]
> baud=115200
>
>
> # lsmod
> Module  Size  Used by
> cp210x  7582  0
> qmi_wwan   10608  0
> cdc_wdm 8788  2 qmi_wwan
> usbnet 17174  1 qmi_wwan
> mii 3417  1 usbnet
> ipv6  262886  24
>
>
> # cat /boot/config-4.0.0-g0fa909f-dirty | grep -v '#' | grep
> 'WWAN\|QMI\|USB_SERIAL\|PPP\|QUALCOM'
> CONFIG_NET_VENDOR_QUALCOMM=y
> CONFIG_PPP=m
> CONFIG_PPP_BSDCOMP=m
> CONFIG_PPP_DEFLATE=m
> CONFIG_PPP_FILTER=y
> CONFIG_PPP_MPPE=m
> CONFIG_PPP_MULTILINK=y
> CONFIG_PPPOE=m
> CONFIG_PPP_ASYNC=m
> CONFIG_PPP_SYNC_TTY=m
> CONFIG_USB_NET_QMI_WWAN=m
> CONFIG_USB_SERIAL=y
> CONFIG_USB_SERIAL_GENERIC=y
> CONFIG_USB_SERIAL_CP210X=m
> CONFIG_USB_SERIAL_FTDI_SIO=y
> CONFIG_USB_SERIAL_PL2303=m
> CONFIG_USB_SERIAL_QCAUX=m
> CONFIG_USB_SERIAL_QUALCOMM=m
> CONFIG_USB_SERIAL_WWAN=m
> CONFIG_USB_SERIAL_OPTION=m
>

# mmcli -L 

Found 1 modems:
/org/freedesktop/ModemManager1/Modem/0 [QUALCOMM INCORPORATED] 0


# mmcli -m 0

/org/freedesktop/ModemManager1/Modem/0 (device id
'a6620fb85776960b03a5848959ac4607cf6922dc')
  -
  Hardware |   manufacturer: 'QUALCOMM INCORPORATED'
   |  model: '0'
   |   revision: 'UC20GQAR03A05M1024  1  [2014/05/05 9:00:00]'
   |  supported: 'gsm-umts'
   |current: 'gsm-umts'
   |   equipment id: '861075020977922'
  -
  System   | device:
'/sys/devices/soc0/amba@0/e0002000.usb/ci_hdrc.0/usb1/1-1/1-1.4'
   |drivers: 'qmi_wwan'
   | plugin: 'Generic'
   |   primary port: 'cdc-wdm0'
   |  ports: 'cdc-wdm0 (qmi), wwan0 (net)'
  -
  Numbers  |   own : 'unknown'
  -
  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: 'umts'
   | signal quality: '68' (recent)
  -
  Modes|  supported: 'allowed: 2g; preferred: none
   |  allowed: 3

Re: Can't get Quectel UC20 modem working on Embedded Board

[Brendan Simon (eTRIX)]

Working now.  See below.

On 12/12/2015 11:09 PM, Brendan Simon (eTRIX) wrote:
> More info below.
>
> On 12/12/2015 10:53 PM, Brendan Simon (eTRIX) wrote:
>> Hi,
>>
>> Not sure if this the best forum to ask questions regarding MM
>> configuration, etc.  I hope so.  If not please refer me to
>> appropriate forums.
>>
>> I have a Quectel UC20 gsm modem.  I got it working under Debian
>> Jessie on my MacBook (using VirtualBox).  It all seem to go well and
>> had no problems getting it to work (well, after I unloaded the option
>> driver, as the Quectel documentation only specifies the multiple tty
>> method to access the modem).
>>
>> Now I have installed the same modem (on an evaluation board) to my
>> embedded arm board (Digilent ZedBoard with Xilinx Zynq dual ARM-A9
>> SOC), also running Debian Jessie.  It's conncected via a USB OTG
>> port.  It shows up with lsusb and also the /dev/cdc-wdm0 entry is
>> populated.  MM can see the device with 'mmcli -L' and 'mmcli -m 0'
>> reports a bunch of information, so everything looks fine as far as
>> detecting and communicating with the device.
>>
>> However, I just can't get it to connect to my ISP.  It works ok on
>> the full Debian Jessie system, but not on the ZedBoard.
>> I copied the /etc/NetworkManager/system-connections/ file from
>> the VB system.  I presume that is ok and MM should work.
>>
>> I thought I would try creating a new connection, but I can't find a
>> way of doing this from the cli.  nm-connection-editor is gnome app
>> and I don't have gnome installed on my embedded board.  I tried
>> nmtui, nmtui-edit, nmtui-connect, but there are no options to add a
>> Mobile Broadband connection as there is with nm-connection-editor.
>>
>> Is there a nice/easy way of adding a new Mobile Broadband connection
>> with the cli tools ?
>>
>> # cat /etc/NetworkManager/system-connections/Telstra\ Telstra\
>> \(Next\ G\)\ 1
>> [connection]
>> id=Telstra Telstra (Next G) 1
>> uuid=5ee505f2-e161-436b-9b00-b36cab43ebfc
>> type=gsm
>>
>> [gsm]
>> number=*99#
>> password-flags=1
>> apn=telstra.internet
>> network-type=4
>>
>> [ipv6]
>> method=auto
>>
>> [ipv4]
>> method=auto
>>
>> [serial]
>> baud=115200
>>
>>
>> # lsmod
>> Module  Size  Used by
>> cp210x  7582  0
>> qmi_wwan   10608  0
>> cdc_wdm 8788  2 qmi_wwan
>> usbnet 17174  1 qmi_wwan
>> mii 3417  1 usbnet
>> ipv6  262886  24
>>
>>
>> # cat /boot/config-4.0.0-g0fa909f-dirty | grep -v '#' | grep
>> 'WWAN\|QMI\|USB_SERIAL\|PPP\|QUALCOM'
>> CONFIG_NET_VENDOR_QUALCOMM=y
>> CONFIG_PPP=m
>> CONFIG_PPP_BSDCOMP=m
>> CONFIG_PPP_DEFLATE=m
>> CONFIG_PPP_FILTER=y
>> CONFIG_PPP_MPPE=m
>> CONFIG_PPP_MULTILINK=y
>> CONFIG_PPPOE=m
>> CONFIG_PPP_ASYNC=m
>> CONFIG_PPP_SYNC_TTY=m
>> CONFIG_USB_NET_QMI_WWAN=m
>> CONFIG_USB_SERIAL=y
>> CONFIG_USB_SERIAL_GENERIC=y
>> CONFIG_USB_SERIAL_CP210X=m
>> CONFIG_USB_SERIAL_FTDI_SIO=y
>> CONFIG_USB_SERIAL_PL2303=m
>> CONFIG_USB_SERIAL_QCAUX=m
>> CONFIG_USB_SERIAL_QUALCOMM=m
>> CONFIG_USB_SERIAL_WWAN=m
>> CONFIG_USB_SERIAL_OPTION=m
>>
>
> # mmcli -L 
>
> Found 1 modems:
> /org/freedesktop/ModemManager1/Modem/0 [QUALCOMM INCORPORATED] 0
>
>
> # mmcli -m 0
>
> /org/freedesktop/ModemManager1/Modem/0 (device id
> 'a6620fb85776960b03a5848959ac4607cf6922dc')
>   -
>   Hardware |   manufacturer: 'QUALCOMM INCORPORATED'
>|  model: '0'
>|   revision: 'UC20GQAR03A05M1024  1  [2014/05/05 9:00:00]'
>|  supported: 'gsm-umts'
>|current: 'gsm-umts'
>|   equipment id: '861075020977922'
>   -
>   System   | device:
> '/sys/devices/soc0/amba@0/e0002000.usb/ci_hdrc.0/usb1/1-1/1-1.4'
>|drivers: 'qmi_wwan'
>| plugin: 'Generic'
>|   primary port: 'cdc-wdm0'
>|  ports: 'cdc-wdm0 (qmi), wwan0 (net)

Python sample to send SMS

[Brendan Simon (eTRIX)]

Hi,

I'm looking for a Python example/sample/snippet to send an SMS message
to a mobile phone.

All I can find is older code that uses EnumerateDevices() method.

e.g.   
https://github.com/miurahr/ModemManager/blob/master/test/mm-send-sms.py

which appears to be old and obsolete, and not supported on my system
(Debian Jessie, modemmanager v 1.4).

I've read some of the ModemManager and DBus docs (not that easy going). 
All I can work out is that the API is now more generic but I can't find
the right set of methods to use.  e.g. to get a list of modems.

Is there an equivalent to the sample above?

Thanks,
Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

ModemManager auto reconnect

[Brendan Simon (eTRIX)]

Hi,

I have a number or remotely deployed arm embedded linux systems that
uses a 3G modem via USB to post http information once per second.  The
modem goes down from time to time.  One reason is we assert the power
reset line on the modem once a day (as I've been told that the modems
need to be reset periodically, otherwise functionality degrades or
eventually lost).  The other reasons I am not sure of (service provider
initiated?  bugs in the application code?

The modem can be off for many hours before eventually reconnecting
(possibly by watchdog reboot) which is not acceptable for our real-time
monitoring application.

Does MM automatically try to re-establish a connection if it sees the
connection go down, or the modem is reset?

Are there recommended or suggested MM settings such that MM will
continually try to reconnect if the modem goes down then back up?

Thanks,
Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ModemManager auto reconnect

[Brendan Simon (eTRIX)]

On 9/02/2016 9:08 AM, Dan Williams wrote:
> On Tue, 2016-02-09 at 07:31 +1100, Brendan Simon (eTRIX) wrote:
>> I have a number or remotely deployed arm embedded linux systems that
>> uses a 3G modem via USB to post http information once per second. 
>>  The
>> modem goes down from time to time.  One reason is we assert the power
>> reset line on the modem once a day (as I've been told that the modems
>> need to be reset periodically, otherwise functionality degrades or
>> eventually lost).  The other reasons I am not sure of (service
>> provider
>> initiated?  bugs in the application code?
>>
>> The modem can be off for many hours before eventually reconnecting
>> (possibly by watchdog reboot) which is not acceptable for our real
>> -time
>> monitoring application.
>>
>> Does MM automatically try to re-establish a connection if it sees the
>> connection go down, or the modem is reset?
>>
>> Are there recommended or suggested MM settings such that MM will
>> continually try to reconnect if the modem goes down then back up?
> This is left up to the connection manager that controls ModemManager
> and tells it to connect.  So whatever you're using to tell ModemManager
> to start the data connection, that's the thing that would monitor for
> the modem being disconnected and periodically restart the data
> connection.

I created a NetworkManager broadband connection in a Debian virtual
machine with a modem connected (dev kit).  I then copied the file that
was created
(/etc/NetworkManager/system-connections/telstra-mobile-broadband-1) into
my build system which will populate my target rootfs for the embedded
system.

I found that the modem was not coming up at boot, but would come up if I
used the `nmtui-connect` utility to activate the connection.  A systemd
service was created to bring up the modem at boot time (a one-shot
script, which brings the modem down then up then calls `nmcli d connect
cdc-wdm0`).

The scirpt works but I'm not sure if it's the `right way` to get the
modem up automatically.  One interesting thing which may be a clue is
that the modem connection does not appear in the `nmtui-edit` utility,
but does appear in the `nmtui-connect` utility.  Is this expected ? 
Also the LAN connection shows up in both utilities but there a
connection file does not exist in /etc/NetworkManager/system-connections/

I presume NetworkManager is starting and managing the connection, yes? 
How do I get it to auto-reconnect when the connection goes down or is
not available?  We are looking at running a custom script invoked via
cron every minute, but that seems a bit hacky.

The system connection file is as follows

[connection]
id=telstra-mobile-broadband-1
uuid=ade7c9ec-26ad-4981-86b4-c2fc6fc4d200
type=gsm
permissions=user:root:;
autoconnect=true

[gsm]
number=*99#
password-flags=1
apn=telstra.extranet

[ipv4]
method=auto

[serial]
baud=115200


Thanks, Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Re: ModemManager auto reconnect

[Brendan Simon (eTRIX)]

On 10/02/2016 3:39 AM, Dan Williams wrote:
> On Tue, 2016-02-09 at 11:27 +1100, Brendan Simon (eTRIX) wrote:
>> On 9/02/2016 9:08 AM, Dan Williams wrote:
>>> On Tue, 2016-02-09 at 07:31 +1100, Brendan Simon (eTRIX) wrote:
>>>> I have a number or remotely deployed arm embedded linux systems
>>>> that
>>>> uses a 3G modem via USB to post http information once per second.
>>>>  The
>>>> modem goes down from time to time.  One reason is we assert the
>>>> power
>>>> reset line on the modem once a day (as I've been told that the
>>>> modems
>>>> need to be reset periodically, otherwise functionality degrades
>>>> or
>>>> eventually lost).  The other reasons I am not sure of (service
>>>> provider
>>>> initiated?  bugs in the application code?
>>>>
>>>> The modem can be off for many hours before eventually
>>>> reconnecting
>>>> (possibly by watchdog reboot) which is not acceptable for our
>>>> real
>>>> -time
>>>> monitoring application.
>>>>
>>>> Does MM automatically try to re-establish a connection if it sees
>>>> the
>>>> connection go down, or the modem is reset?
>>>>
>>>> Are there recommended or suggested MM settings such that MM will
>>>> continually try to reconnect if the modem goes down then back up?
>>> This is left up to the connection manager that controls
>>> ModemManager
>>> and tells it to connect.  So whatever you're using to tell
>>> ModemManager
>>> to start the data connection, that's the thing that would monitor
>>> for
>>> the modem being disconnected and periodically restart the data
>>> connection.
>> I created a NetworkManager broadband connection in a Debian virtual
>> machine with a modem connected (dev kit).  I then copied the file
>> that
>> was created
>> (/etc/NetworkManager/system-connections/telstra-mobile-broadband-1)
>> into
>> my build system which will populate my target rootfs for the embedded
>> system.
>>
>> I found that the modem was not coming up at boot, but would come up
>> if I
>> used the `nmtui-connect` utility to activate the connection.  A
>> systemd
>> service was created to bring up the modem at boot time (a one-shot
>> script, which brings the modem down then up then calls `nmcli d
>> connect
>> cdc-wdm0`).
>>
>> The scirpt works but I'm not sure if it's the `right way` to get the
>> modem up automatically.  One interesting thing which may be a clue is
>> that the modem connection does not appear in the `nmtui-edit`
>> utility,
>> but does appear in the `nmtui-connect` utility.  Is this expected ? 
>> Also the LAN connection shows up in both utilities but there a
>> connection file does not exist in /etc/NetworkManager/system
>> -connections/
>>
>> I presume NetworkManager is starting and managing the connection,
>> yes? 
>> How do I get it to auto-reconnect when the connection goes down or is
>> not available?  We are looking at running a custom script invoked via
>> cron every minute, but that seems a bit hacky.
> What version of NM?  There have been improvements to the autoconnect
> logic for WWAN recently in NM, especially if the SIM has a PIN enabled.
>  Aside from bugs, we would expect NM to periodically retry the
> connection if it fails.

The following Debian Jessie packages are installed.
network-manager0.9.10.0-7
modemmanager   1.4.0-1  

There is no PIN enabled on the SIM cards.

I suspect that there is something not configured properly with NM as it
doesn't recognise that I have a broadband connection if I invoke
`nmtui-edit`.  However it does know about the connection if I invoke
`nmtui-connect`.

Is the file in /etc/NetworkManager/system-connections/ all that I need,
or is there another NM config file that needs to know about the connection?

Is the `uuid` field in the connections file significant?
Does it need to match something on my system?
The `uuid` field is set to the same on all the boxes.

Thanks, Brendan.

___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel