Re: Quectel EC25 & AT&T connection Catch-22
Hi Bruce, You can use ModemManager's API to set APN. ModemManager will do it using QMI protocol and there should be no need to send additional AT command unless you're doing something more custom not handled by ModemManager. I've been using Quectel (EG/EC) modems over USB with ModemManager and as Enrico said there is no need to use Quectel's patched driver qmi_wwan_q. With newer Linux versions can use mainline qmi_wwan, as explained here: https://www.mail-archive.com/modemmanager-devel@lists.freedesktop.org/msg06298.html You can just confirm that your modem PID/VID is included in the version of kernel that you use and this is going to work. I'm sharing sample kernel output for reference, hope it helps. I think you need cdc-wdm0 device. Jan 1 00:00:33 kernel: [ 33.548300] usb 1-1: new high-speed USB device number 2 using ci_hdrc Jan 1 00:00:33 kernel: [ 33.781440] usb 1-1: New USB device found, idVendor=2c7c, idProduct=0121, bcdDevice= 3.18 Jan 1 00:00:33 kernel: [ 33.790457] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Jan 1 00:00:33 kernel: [ 33.797992] usb 1-1: Product: EC21-EUX Jan 1 00:00:33 kernel: [ 33.801795] usb 1-1: Manufacturer: Quectel Jan 1 00:00:33 kernel: [ 33.805937] usb 1-1: SerialNumber: 0123456789ABCDEF Jan 1 00:00:33 kernel: [ 33.870897] option 1-1:1.0: GSM modem (1-port) converter detected Jan 1 00:00:33 kernel: [ 33.903985] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0 Jan 1 00:00:33 kernel: [ 33.956276] option 1-1:1.1: GSM modem (1-port) converter detected Jan 1 00:00:33 kernel: [ 33.980366] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1 Jan 1 00:00:33 kernel: [ 33.998549] option 1-1:1.2: GSM modem (1-port) converter detected Jan 1 00:00:34 kernel: [ 34.021000] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB2 Jan 1 00:00:34 kernel: [ 34.052445] option 1-1:1.3: GSM modem (1-port) converter detected Jan 1 00:00:34 kernel: [ 34.076217] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB3 Jan 1 00:00:34 kernel: [ 34.144283] qmi_wwan 1-1:1.4: cdc-wdm0: USB WDM device Jan 1 00:00:34 kernel: [ 34.177899] qmi_wwan 1-1:1.4 wwan0: register 'qmi_wwan' at usb-ci_hdrc.1-1, WWAN/QMI device, xx:xx:e9:ae:aa:11 And part of the mmcli -m 0 output: System | device: /sys/devices/platform/soc/210.bus/2184200.usb/ci_hdrc.1/usb1/1-1 |drivers: qmi_wwan, option | plugin: quectel | primary port: cdc-wdm0 | ports: cdc-wdm0 (qmi), ttyUSB0 (qcdm), ttyUSB1 (ignored), | ttyUSB2 (at), ttyUSB3 (ignored), wwan0 (net) And then you will be able to set APN using ModemManager API: https://www.freedesktop.org/software/ModemManager/doc/latest/ModemManager/gdbus-org.freedesktop.ModemManager1.Modem.Simple.html You can pass the APN to Connect() function. Or for testing you can use mmcli -m 0 --simple-connect="apn=your_apn" mmcli - more info here https://www.freedesktop.org/software/ModemManager/man/1.0.0/mmcli.8.html Kind regards, Filip On Mon, Apr 22, 2024 at 11:12 AM Enrico Mioso wrote: > On Fri, Apr 19, 2024 at 04:39:46PM +, Bruce Johnson wrote: > > I have a question about using both QMI and the serial interface with > ModemManager. > > > > I had little difficulty getting ModemManager's SimpleModem to connect to > T-Mobile (USA) using a Quectel EG25-G, but we found that modem wasn't > compatible with AT&T and/or a private APN used by one of our customers. We > were advised to use the Quectel EC25, and after engaging both Quectel and > AT&T, we were told that we need to insert the APN into the modem using an > AT command, AT+CGDCONT=1,"IPV4V6","mcm.com.attz". I had to tweak the kernel > config and the ModemManager build. > > > > Mods: > > > > * I built ModemManager 1.18.4 with --with-at-command-via-dbus. > > * In the kernel config, I added USB Serial Converter support -> USB > driver for GSM and CDMA modems. > > > > After I did this, the /dev/ttyUSB[1-4] files showed up, and I was able > to issue AT commands using ModemManager, but while the modem would sort-of > connect with SimpleModem's connect method -- I am getting a Bearer, and > mmcli shows "connected" -- I receive no IP address information from the > carrier. Port wwan0 is showing up as "ignored". (mmcli output below) > > > > The Quectel docs also said to patch the kernel a certain way to allow > use of serial and the QMI_WWAN driver, but wwan0 is still ignored. > > > > Does anyone have any suggestions? > > > > Thanks! > > > > -- > > Bruce Johnson > > Chantilly, Virginia > > USA > > I will stand corrected in case - but... > I don't think you need AT commands via d-bus to do this, but giving the > APN via QMI somehow, depending on the object or method you use to connect. > That said, you probably won't need qmi_wwan_q or whatever - the stock > qmi_wwan driver from k
Re: Empty APN, 2 PDP contexts and 1 PDP context
Hi Aleksander,
Thank you for all the explanations. I wasn't aware the initial EPS bearer
needs to be configured separately. Your guesses about the empty APN were
right, I can see:
# qmicli -d /dev/cdc-wdm0 -p --wds-get-lte-attach-pdn-list
Attach PDN list retrieved:
Current list: '1'
Pending list: n/a
# qmicli -d /dev/cdc-wdm0 -p --wds-get-profile-list=3gpp
Profile list retrieved:
[1] 3gpp -
APN: ''
PDP type: 'ipv4-or-ipv6'
PDP context number: '1'
Username: ''
Password: ''
Auth: 'none'
No roaming: 'no'
APN disabled: 'no'
Setting the initial EPS bearer works, I'm going to observe how it impacts
our connectivity, thank you!
# mmcli -m 0
--3gpp-set-initial-eps-bearer-settings="apn=de1.super,ip-type=ipv4"
Successfully set initial EPS bearer properties
# mmcli -m a -K | grep "modem.3gpp.eps.initial-bearer.settings"
modem.3gpp.eps.initial-bearer.settings.apn : de1.super
modem.3gpp.eps.initial-bearer.settings.ip-type : ipv4
modem.3gpp.eps.initial-bearer.settings.user : --
modem.3gpp.eps.initial-bearer.settings.password : --
Kind regards,
Filip
On Tue, Apr 9, 2024 at 11:02 AM Aleksander Morgado <
aleksande...@chromium.org> wrote:
> Hey!
>
> >
> > First of all I wanted to say thanks for developing and supporting a
> great piece of software.
> >
>
> Thanks to you for using it!
>
> > We have a few thousand devices running ModemManager 1.18.6 and Quectel
> EC21 modem. Our service provider Twilio/Kore keeps reporting that on some
> devices we have 2 simultaneous data sessions with different APNs: "super"
> and "de1.super".
> >
> > We use ModemManager's API to find the modem, enable it, then wait for
> auto-register done by the modem FW, and finally create a bearer with
> "de1.super" APN and connect. Operations are run over QMI protocol.
> >
>
> Ok, so if I'm reading this right, you do NOT explicitly configure the
> attach APN settings, you only provide the data APN settings. The
> attach APN settings are provided by the modem itself.
>
> > We have autoselect disabled, so I'd expect to always use European APN
> "de1.super", instead of US "super" which is the default.
> > mmcli -m 0 --command='AT+QMBNCFG="AutoSel"' response: '+QMBNCFG:
> "AutoSel",0
>
> I don't know what AutoSel does in these modems, can you elaborate?
>
> > We have made an experiment to show PDP contexts on the devices with
> AT+CGDCONT?, and noticed an interesting thing:
> > On most of them, it only shows 1 PDP context:
> > PdpContext { ctx_id: 1, pdp_type: IpV4V6, pdp_addr:
> \"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0\", apn: \"\", data_comp: Off, head_comp:
> Off, ipv4_addr_alloc: NasSignaling, request_type:
> ContextEstablishmentOrNon3GppAccessNetworkHandover }
> >
> > However, on 1 of the 200 devices, we see 2 PDP contexts:
> > PdpContext { ctx_id: 2, pdp_type: Ip, pdp_addr: \"0.0.0.0\", apn:
> \"de1.super\", data_comp: Off, head_comp: Off, ipv4_addr_alloc:
> NasSignaling, request_type:
> ContextEstablishmentOrNon3GppAccessNetworkHandover }
> >
> > PdpContext { ctx_id: 1, pdp_type: IpV4V6, pdp_addr:
> \"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0\", apn: \"\", data_comp: Off, head_comp:
> Off, ipv4_addr_alloc: NasSignaling, request_type:
> ContextEstablishmentOrNon3GppAccessNetworkHandover }
> >
> > However, even on device with just 1 PDP context received from AT command
> > # mmcli -m 0 --command='AT+CGDCONT?'
> > response: '+CGDCONT:
> 1,"IPV4V6","","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0'
> >
> > AT commands are run ~10 minutes after modem setup and connection is done
> with ModemManager.
> > ModemManager always reports 2 bearers, I understand the 1st bearer is
> LTE default EPS bearer, while the 2nd one is the actual data session bearer:
> >
>
> Yes.
>
> > # mmcli -b 0
> > -
> > General|path: /org/freedesktop/ModemManager1/Bearer/0
> > |type: default-attach
> > -
> > Status | connected: yes
> > | suspended: no
> > | multiplexed: no
> > | ip timeout: 20
> > -
> > Properties | apn: super
> > | ip type: ipv4
> >
> > # mmcli -b 3
> >
> > General| path:
> /org/freedesktop/ModemManager1/Bearer/3
> > | type: default
> >
> > Status | connected: yes
> > | suspended: no
> > |multiplexed: no
> > | interface: wwan0
> > | ip timeout: 20
> >
> > Properties |apn: de1.super
> > |roaming: allowed
> > |ip type: ipv4
> >
> > IPv4 configuration | method: static
> > |address: 100.79.145.117
> > | prefix: 30
>
Empty APN, 2 PDP contexts and 1 PDP context
Hi ModemManager Community!
First of all I wanted to say thanks for developing and supporting a
great piece of software.
We have a few thousand devices running ModemManager 1.18.6 and Quectel EC21
modem. Our service provider Twilio/Kore keeps reporting that on some
devices we have 2 simultaneous data sessions with different APNs: "super"
and "de1.super".
We use ModemManager's API to find the modem, enable it, then wait for
auto-register done by the modem FW, and finally create a bearer with
"de1.super" APN and connect. Operations are run over QMI protocol.
We have autoselect disabled, so I'd expect to always use European APN
"de1.super", instead of US "super" which is the default.
mmcli -m 0 --command='AT+QMBNCFG="AutoSel"' response: '+QMBNCFG:
"AutoSel",0
We have made an experiment to show PDP contexts on the devices with
AT+CGDCONT?, and noticed an interesting thing:
On most of them, it only shows 1 PDP context:
*PdpContext { ctx_id: 1, pdp_type: IpV4V6, pdp_addr:
\"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0\", apn: \"\", data_comp: Off, head_comp:
Off, ipv4_addr_alloc: NasSignaling, request_type:
ContextEstablishmentOrNon3GppAccessNetworkHandover }*
However, on 1 of the 200 devices, we see 2 PDP contexts:
*PdpContext { ctx_id: 2, pdp_type: Ip, pdp_addr: \"0.0.0.0\", apn:
\"de1.super\", data_comp: Off, head_comp: Off, ipv4_addr_alloc:
NasSignaling, request_type:
ContextEstablishmentOrNon3GppAccessNetworkHandover }*
*PdpContext { ctx_id: 1, pdp_type: IpV4V6, pdp_addr:
\"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0\", apn: \"\", data_comp: Off, head_comp:
Off, ipv4_addr_alloc: NasSignaling, request_type:
ContextEstablishmentOrNon3GppAccessNetworkHandover }*
However, even on device with just 1 PDP context received from AT command
# mmcli -m 0 --command='AT+CGDCONT?'
response: '+CGDCONT:
1,"IPV4V6","","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0'
AT commands are run ~10 minutes after modem setup and connection is done
with ModemManager.
ModemManager always reports 2 bearers, I understand the 1st bearer is LTE
default EPS bearer, while the 2nd one is the actual data session bearer:
# mmcli -b 0
-
General|path: /org/freedesktop/ModemManager1/Bearer/0
|type: default-attach
-
Status | connected: yes
| suspended: no
| multiplexed: no
| ip timeout: 20
-
Properties | apn: super
| ip type: ipv4
# mmcli -b 3
General| path:
/org/freedesktop/ModemManager1/Bearer/3
| type: default
Status | connected: yes
| suspended: no
|multiplexed: no
| interface: wwan0
| ip timeout: 20
Properties |apn: de1.super
|roaming: allowed
|ip type: ipv4
IPv4 configuration | method: static
|address: 100.79.145.117
| prefix: 30
|gateway: 100.79.145.118
|dns: 8.8.4.4, 8.8.8.8
|mtu: 1360
Statistics | duration: 3810
| bytes rx: 513071
| bytes tx: 296673
| attempts: 1
| total-duration: 3810
| total-bytes rx: 513071
| total-bytes tx: 296673
I have some questions:
1. When using QMI, is it reliable to check modem state with AT commands? I
don't care about immediate / race conditions, but I'd like to know that if
I run some AT command e.g. 1 hour after it was set up by ModemManager with
QMI it will tell me the accurate modem state.
2. Why do some devices have only 1 PDP context with empty APN, while others
have 2 PDP contexts with the right APN in context 2?
We'd like to make sure all devices use European APN as it positively
impacts the latency and download speed.
Thank you!
Filip Kubicz
Re: Get modem SIM properties for mmcli
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 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 <
> 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: Get modem SIM properties for mmcli
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 <
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)
>
>
>
>
> 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.
>
ModemManager and modem low power with USB/QMI
Hi! I'm using Quectel EC21EUX modem, connected with USB, and QMI to control it via ModemManager. I have a question about going to sleep with a TCP connection kept so the device can wake up. I have configured the modem to go to low power mode whenever there is no traffic (AT+QSCLK=1, AT+QURCCFG="urcport","usbat", setting DTR and AP_READY pins). With this configuration, LTE modem should wake up when there is an incoming data packet. The easiest way for me put modem to sleep was to stop ModemManager. Now, if I disable ModemManager, and then try to send a network packet from backend to the device, the modem never wakes up. My guess is that when I stop ModemManager, the TCP connection is lost, and this is why modem cannot wake up as it doesn't get the message from backend. My preferred way to sleep modem is to disable USB_VBUS. On the ModemManager side, what should I do to maintain the TCP connection when putting the modem to sleep, so it can wake up when getting a message over network? Kind regards, Filip
Re: Linux system cannot use the data connection
Hi! I'm following up because after 2 months of the device being permanently not able to exchange data, it received a LTE detach, and immediately after it was able to exchange data: Jan 3 00:01:35 ModemManager[302]: [modem0/bearer1] verbose call end reason (3,1067): [cm] detach-with-reattach-lte-nw-detach Jan 3 00:01:35 ModemManager[302]: [modem0] state changed (connected -> registered) Jan 3 00:01:35 ModemManager[302]: [modem0/bearer1] connection #2 finished: duration 86402s, tx: 3540738 bytes, rx: 0 bytes ... Jan 3 00:01:37 [INFO:iot.connectivity:None:_modem_connect_sync] Modem connected successfully: state = connected Jan 3 00:01:46 [ INFO:iot.connectivity:None:ping_network] Successful ping 8.8.8.8, signal quality (63, recent=False) I assume this means a network-initiated detach request. If I'm correct, it maps to this result code in Quectel documentation: *+CGEV: NW DETACH: The network has forced a Packet Domain detach. This implies that all activecontexts have been deactivated. These are not reported separately.* Which would mean that maybe deactivating all PDP contexts could be a workaround in this case, for other affected devices. How to best cause a context deactivation using ModemManager? Kind regards, Filip -- Forwarded message ----- From: Filip Kubicz Date: Wed, Jul 27, 2022 at 9:33 AM Subject: Re: Linux system cannot use the data connection To: Amol Lad Cc: modemmanager-devel@lists.freedesktop.org < modemmanager-devel@lists.freedesktop.org>, Kamil Sroka Hi Amol, > MTU from the carrier is 1360 but wwan0 MTU is set to 1500. It must be set to the MTU received from the carrier. Thank you for your suggestion! I added the correct MTU value setting. However, it looks like it's not the cause of this specific problem, after changing the MTU and resetting the ModemManager, or after changing MTU, resetting ModemManager and resetting the modem, the issue still persists. # ifconfig wwan0 wwan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:100.65.37.39 P-t-P:100.65.37.39 Mask:255.255.255.240 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1360 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:696 (696.0 B) # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes ^C --- 8.8.8.8 ping statistics --- 12 packets transmitted, 0 packets received, 100% packet loss # Do you have an idea what this issue can be caused by, or how to recover the network access on the devices? Kind regards, Filip On Fri, Jul 15, 2022 at 3:30 PM Amol Lad wrote: > Also, one thing I noticed in mmcli-all-log.info. It might not be related > to your problem though. > > MTU from the carrier is 1360 but wwan0 MTU is set to 1500. It must be set > to the MTU received from the carrier. > > -Original Message- > From: Amol Lad > Sent: Friday, 15 July 2022 6:39 PM > To: Filip Kubicz > Cc: modemmanager-devel@lists.freedesktop.org; Kamil Sroka < > kamil.sr...@tier.app> > Subject: RE: Linux system cannot use the data connection > > Please try below (skip dns resolution) > > wget > http://193.63.62.31/sites/default/files/publications/civic_renewal_forms.zip > > From: Filip Kubicz > Sent: Friday, 15 July 2022 6:29 PM > To: Amol Lad > Cc: modemmanager-devel@lists.freedesktop.org; Kamil Sroka < > kamil.sr...@tier.app> > Subject: Re: Linux system cannot use the data connection > > Hi Amol, > > # wget http://speedtest.ftp.otenet.gr/files/test10Mb.db > --1970-01-04 01:06:40-- http://speedtest.ftp.otenet.gr/files/test10Mb.db > Resolving speedtest.ftp.otenet.gr... failed: Temporary failure in name > resolution. > wget: unable to resolve host address 'speedtest.ftp.otenet.gr< > http://speedtest.ftp.otenet.gr>' > > Filip > > > On Fri, Jul 15, 2022 at 2:52 PM Amol Lad amol@4rf.com>> wrote: > Please also try downloading a test file as below and see the result. Does > it download any file at all? > > wget http://speedtest.ftp.otenet.gr/files/test10Mb.db > > > > From: Filip Kubicz mailto:filip.kub...@tier.app>> > Sent: Friday, 15 July 2022 5:28 PM > To: Amol Lad mailto:amol@4rf.com>> > Cc: modemmanager-devel@lists.freedesktop.org modemmanager-devel@lists.freedesktop.org>; Kamil Sroka < > kamil.sr...@tier.app<mailto:kamil.sr...@tier.app>> > Subject: Re: Linux system cannot use the data connection > > Hi Amol, thanks for the answer. I checked that the devices are not hitting > the SIM data limit. > Moreover, as I mentioned there is some small RX/TX occurring for the > device from the operator point of view, but the "ping 8.8.8.8 -I w
Re: Linux system cannot use the data connection
Hi Amol, > MTU from the carrier is 1360 but wwan0 MTU is set to 1500. It must be set to the MTU received from the carrier. Thank you for your suggestion! I added the correct MTU value setting. However, it looks like it's not the cause of this specific problem, after changing the MTU and resetting the ModemManager, or after changing MTU, resetting ModemManager and resetting the modem, the issue still persists. # ifconfig wwan0 wwan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:100.65.37.39 P-t-P:100.65.37.39 Mask:255.255.255.240 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1360 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:696 (696.0 B) # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes ^C --- 8.8.8.8 ping statistics --- 12 packets transmitted, 0 packets received, 100% packet loss # Do you have an idea what this issue can be caused by, or how to recover the network access on the devices? Kind regards, Filip On Fri, Jul 15, 2022 at 3:30 PM Amol Lad wrote: > Also, one thing I noticed in mmcli-all-log.info. It might not be related > to your problem though. > > MTU from the carrier is 1360 but wwan0 MTU is set to 1500. It must be set > to the MTU received from the carrier. > > -Original Message- > From: Amol Lad > Sent: Friday, 15 July 2022 6:39 PM > To: Filip Kubicz > Cc: modemmanager-devel@lists.freedesktop.org; Kamil Sroka < > kamil.sr...@tier.app> > Subject: RE: Linux system cannot use the data connection > > Please try below (skip dns resolution) > > wget > http://193.63.62.31/sites/default/files/publications/civic_renewal_forms.zip > > From: Filip Kubicz > Sent: Friday, 15 July 2022 6:29 PM > To: Amol Lad > Cc: modemmanager-devel@lists.freedesktop.org; Kamil Sroka < > kamil.sr...@tier.app> > Subject: Re: Linux system cannot use the data connection > > Hi Amol, > > # wget http://speedtest.ftp.otenet.gr/files/test10Mb.db > --1970-01-04 01:06:40-- http://speedtest.ftp.otenet.gr/files/test10Mb.db > Resolving speedtest.ftp.otenet.gr... failed: Temporary failure in name > resolution. > wget: unable to resolve host address 'speedtest.ftp.otenet.gr< > http://speedtest.ftp.otenet.gr>' > > Filip > > > On Fri, Jul 15, 2022 at 2:52 PM Amol Lad amol@4rf.com>> wrote: > Please also try downloading a test file as below and see the result. Does > it download any file at all? > > wget http://speedtest.ftp.otenet.gr/files/test10Mb.db > > > > From: Filip Kubicz mailto:filip.kub...@tier.app>> > Sent: Friday, 15 July 2022 5:28 PM > To: Amol Lad mailto:amol@4rf.com>> > Cc: modemmanager-devel@lists.freedesktop.org modemmanager-devel@lists.freedesktop.org>; Kamil Sroka < > kamil.sr...@tier.app<mailto:kamil.sr...@tier.app>> > Subject: Re: Linux system cannot use the data connection > > Hi Amol, thanks for the answer. I checked that the devices are not hitting > the SIM data limit. > Moreover, as I mentioned there is some small RX/TX occurring for the > device from the operator point of view, but the "ping 8.8.8.8 -I wwan0" > does not work. > > Filip > > > On Fri, Jul 15, 2022 at 1:28 PM Amol Lad amol@4rf.com>> wrote: > I generally run into similar situation when my SIM card runs out of money. > Do you want to try topping-up SIM card and see if ping is successful? > > Amol > > From: ModemManager-devel <mailto:modemmanager-devel-boun...@lists.freedesktop.org>> On Behalf Of > Filip Kubicz > Sent: Friday, 15 July 2022 4:14 PM > To: modemmanager-devel@lists.freedesktop.org modemmanager-devel@lists.freedesktop.org> > Cc: Kamil Sroka mailto:kamil.sr...@tier.app>> > Subject: Linux system cannot use the data connection > > Hi! > > I'm using ModemManager 1.18.6 with Quectel EG21-G modem and Twilio > SuperSIM. > > This setup works ok on multiple devices. > However, on a few devices, I see following situation: > > • Modem registered to operator network (e.g. Vodafone UK) > > • Modem reports connected state > > • wwan0 interface has IPv4 address > > • Network provider sees no issues > > • in Network provider console you can see the device exchanges a few > hundred kB of data every hour > > • but ping doesn’t work > > • sending data fails > This looks strange, as if ModemManager was not aware of the data session > that is setup, or Linux system not being able to use it. > > The simplified flow of using the modem: > - enable modem > - wait until it auto-registers >
Re: Linux system cannot use the data connection
Hi Amol, # wget http://speedtest.ftp.otenet.gr/files/test10Mb.db --1970-01-04 01:06:40-- http://speedtest.ftp.otenet.gr/files/test10Mb.db Resolving speedtest.ftp.otenet.gr... failed: Temporary failure in name resolution. wget: unable to resolve host address 'speedtest.ftp.otenet.gr' Filip On Fri, Jul 15, 2022 at 2:52 PM Amol Lad wrote: > Please also try downloading a test file as below and see the result. Does > it download any file at all? > > > > wget http://speedtest.ftp.otenet.gr/files/test10Mb.db > > > > > > > > *From:* Filip Kubicz > *Sent:* Friday, 15 July 2022 5:28 PM > *To:* Amol Lad > *Cc:* modemmanager-devel@lists.freedesktop.org; Kamil Sroka < > kamil.sr...@tier.app> > *Subject:* Re: Linux system cannot use the data connection > > > > Hi Amol, thanks for the answer. I checked that the devices are not hitting > the SIM data limit. > Moreover, as I mentioned there is some small RX/TX occurring for the > device from the operator point of view, but the "ping 8.8.8.8 -I wwan0" > does not work. > > > Filip > > > > > > On Fri, Jul 15, 2022 at 1:28 PM Amol Lad wrote: > > I generally run into similar situation when my SIM card runs out of money. > Do you want to try topping-up SIM card and see if ping is successful? > > > > Amol > > > > *From:* ModemManager-devel < > modemmanager-devel-boun...@lists.freedesktop.org> *On Behalf Of *Filip > Kubicz > *Sent:* Friday, 15 July 2022 4:14 PM > *To:* modemmanager-devel@lists.freedesktop.org > *Cc:* Kamil Sroka > *Subject:* Linux system cannot use the data connection > > > > Hi! > > I'm using ModemManager 1.18.6 with Quectel EG21-G modem and Twilio > SuperSIM. > > > This setup works ok on multiple devices. > However, on a few devices, I see following situation: > > · Modem registered to operator network (e.g. Vodafone UK) > > · Modem reports connected state > > · wwan0 interface has IPv4 address > > · Network provider sees no issues > > · in Network provider console you can see the device exchanges a few > hundred kB of data every hour > > · but ping doesn’t work > > · sending data fails > > This looks strange, as if ModemManager was not aware of the data session > that is setup, or Linux system not being able to use it. > > The simplified flow of using the modem: > - enable modem > - wait until it auto-registers > - create a bearer and connect > - when bearer obtains IP address, configure the network interface > > I attached relevant mmcli information from the device (modem, bearer) and > debug level logs from 2 situations: > - device stable in connected state (but ping fails) > - modem reset - sequence of enable, register, connect -> goes into the > same state where ping does not work. > I also attached the commands that are used for setting up the network > interface when a new IP address is obtained. > > What should I check, or do you know how to avoid this situation? > > > Kind regards, > Filip > -- > > The information in this email communication (inclusive of attachments) is > confidential to 4RF Limited and the intended recipient(s). If you are not > the intended recipient(s), please note that any use, disclosure, > distribution or copying of this information or any part thereof is strictly > prohibited and that the author accepts no liability for the consequences of > any action taken on the basis of the information provided. If you have > received this email in error, please notify the sender immediately by > return email and then delete all instances of this email from your system. > 4RF Limited will not accept responsibility for any consequences associated > with the use of this email (including, but not limited to, damages > sustained as a result of any viruses and/or any action or lack of action > taken in reliance on it). > >
Re: Linux system cannot use the data connection
I love the example :D However... # wget http://193.63.62.31/sites/default/files/publications/civic_renewal_forms.zip --1970-01-04 01:19:23-- http://193.63.62.31/sites/default/files/publications/civic_renewal_forms.zip Connecting to 193.63.62.31:80... failed: Connection timed out. Retrying. --1970-01-04 01:21:36-- (try: 2) http://193.63.62.31/sites/default/files/publications/civic_renewal_forms.zip Connecting to 193.63.62.31:80... failed: Connection timed out. Retrying. --1970-01-04 01:23:50-- (try: 3) http://193.63.62.31/sites/default/files/publications/civic_renewal_forms.zip Connecting to 193.63.62.31:80... failed: Connection timed out. Retrying. ModemManager still reports | state: connected | power state: on | access tech: lte | signal quality: 100% (cached) Bearer statistics: Statistics | duration: 77790 | bytes tx: 3300828 | attempts: 1 | total-duration: 77790 | total-bytes tx: 3300828 I got the information from operator that: Super SIM and the network allow only one active application bearer at a time so the second bearer will be automatically canceled and ModemManager may get confused. Are the 2 bearers expected? I think since some version between 1.12 and 1.14 ModemManager shows initial bearer and actual bearer. Correct? So what could be the real problem in this case? (all logs attached to the first message) Kind regards, Filip On Fri, Jul 15, 2022 at 3:08 PM Amol Lad wrote: > Please try below (skip dns resolution) > > > > wget > http://193.63.62.31/sites/default/files/publications/civic_renewal_forms.zip > > > > *From:* Filip Kubicz > *Sent:* Friday, 15 July 2022 6:29 PM > *To:* Amol Lad > *Cc:* modemmanager-devel@lists.freedesktop.org; Kamil Sroka < > kamil.sr...@tier.app> > *Subject:* Re: Linux system cannot use the data connection > > > > Hi Amol, > > # wget http://speedtest.ftp.otenet.gr/files/test10Mb.db > --1970-01-04 01:06:40-- http://speedtest.ftp.otenet.gr/files/test10Mb.db > Resolving speedtest.ftp.otenet.gr... failed: Temporary failure in name > resolution. > wget: unable to resolve host address 'speedtest.ftp.otenet.gr' > > > Filip > > > > > > On Fri, Jul 15, 2022 at 2:52 PM Amol Lad wrote: > > Please also try downloading a test file as below and see the result. Does > it download any file at all? > > > > wget http://speedtest.ftp.otenet.gr/files/test10Mb.db > > > > > > > > *From:* Filip Kubicz > *Sent:* Friday, 15 July 2022 5:28 PM > *To:* Amol Lad > *Cc:* modemmanager-devel@lists.freedesktop.org; Kamil Sroka < > kamil.sr...@tier.app> > *Subject:* Re: Linux system cannot use the data connection > > > > Hi Amol, thanks for the answer. I checked that the devices are not hitting > the SIM data limit. > Moreover, as I mentioned there is some small RX/TX occurring for the > device from the operator point of view, but the "ping 8.8.8.8 -I wwan0" > does not work. > > > Filip > > > > > > On Fri, Jul 15, 2022 at 1:28 PM Amol Lad wrote: > > I generally run into similar situation when my SIM card runs out of money. > Do you want to try topping-up SIM card and see if ping is successful? > > > > Amol > > > > *From:* ModemManager-devel < > modemmanager-devel-boun...@lists.freedesktop.org> *On Behalf Of *Filip > Kubicz > *Sent:* Friday, 15 July 2022 4:14 PM > *To:* modemmanager-devel@lists.freedesktop.org > *Cc:* Kamil Sroka > *Subject:* Linux system cannot use the data connection > > > > Hi! > > I'm using ModemManager 1.18.6 with Quectel EG21-G modem and Twilio > SuperSIM. > > > This setup works ok on multiple devices. > However, on a few devices, I see following situation: > > · Modem registered to operator network (e.g. Vodafone UK) > > · Modem reports connected state > > · wwan0 interface has IPv4 address > > · Network provider sees no issues > > · in Network provider console you can see the device exchanges a few > hundred kB of data every hour > > · but ping doesn’t work > > · sending data fails > > This looks strange, as if ModemManager was not aware of the data session > that is setup, or Linux system not being able to use it. > > The simplified flow of using the modem: > - enable modem > - wait until it auto-registers > - create a bearer and connect > - when bearer obtains IP address, configure the network interface > > I attached relevant mmcli information from the device (modem, bearer) and > debug level logs from 2 situations: > - device stable
Re: Linux system cannot use the data connection
Hi Amol, thanks for the answer. I checked that the devices are not hitting the SIM data limit. Moreover, as I mentioned there is some small RX/TX occurring for the device from the operator point of view, but the "ping 8.8.8.8 -I wwan0" does not work. Filip On Fri, Jul 15, 2022 at 1:28 PM Amol Lad wrote: > I generally run into similar situation when my SIM card runs out of money. > Do you want to try topping-up SIM card and see if ping is successful? > > > > Amol > > > > *From:* ModemManager-devel < > modemmanager-devel-boun...@lists.freedesktop.org> *On Behalf Of *Filip > Kubicz > *Sent:* Friday, 15 July 2022 4:14 PM > *To:* modemmanager-devel@lists.freedesktop.org > *Cc:* Kamil Sroka > *Subject:* Linux system cannot use the data connection > > > > Hi! > > I'm using ModemManager 1.18.6 with Quectel EG21-G modem and Twilio > SuperSIM. > > > This setup works ok on multiple devices. > However, on a few devices, I see following situation: > > · Modem registered to operator network (e.g. Vodafone UK) > > · Modem reports connected state > > · wwan0 interface has IPv4 address > > · Network provider sees no issues > > · in Network provider console you can see the device exchanges a few > hundred kB of data every hour > > · but ping doesn’t work > > · sending data fails > > This looks strange, as if ModemManager was not aware of the data session > that is setup, or Linux system not being able to use it. > > The simplified flow of using the modem: > - enable modem > - wait until it auto-registers > - create a bearer and connect > - when bearer obtains IP address, configure the network interface > > I attached relevant mmcli information from the device (modem, bearer) and > debug level logs from 2 situations: > - device stable in connected state (but ping fails) > - modem reset - sequence of enable, register, connect -> goes into the > same state where ping does not work. > I also attached the commands that are used for setting up the network > interface when a new IP address is obtained. > > What should I check, or do you know how to avoid this situation? > > > Kind regards, > Filip > -- > The information in this email communication (inclusive of attachments) is > confidential to 4RF Limited and the intended recipient(s). If you are not > the intended recipient(s), please note that any use, disclosure, > distribution or copying of this information or any part thereof is strictly > prohibited and that the author accepts no liability for the consequences of > any action taken on the basis of the information provided. If you have > received this email in error, please notify the sender immediately by > return email and then delete all instances of this email from your system. > 4RF Limited will not accept responsibility for any consequences associated > with the use of this email (including, but not limited to, damages > sustained as a result of any viruses and/or any action or lack of action > taken in reliance on it). > >
