Empty APN, 2 PDP contexts and 1 PDP context

Filip Kubicz filip.kubicz at tier.app
Fri Apr 12 14:38:31 UTC 2024


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 <
aleksandermj at 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
> >                      |        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
> >
>
> In the above output, your initial EPS default bearer that is brought
> up during attach is using the "super" APN. I don't think this is what
> you want, based on the previous comments? Not sure.
>
> > 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.
> >
>
> Yes. As long as you don't modify state of the modem with the AT
> commands, i.e. only use commands to read the state, you can safely run
> them and they will give you the latest up to date info.
>
> > 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.
> >
>
> I assume the modem is reporting the PDP context in CID 1 with empty
> APN because the attach APN settings have an empty APN. You can confirm
> this running the following:
>
> $ sudo qmicli -d /dev/cdc-wdm0 -p --wds-get-lte-attach-pdn-list
> // will likely return that profile 1 is the one used for attach
>
> $ sudo qmicli -d /dev/cdc-wdm0 -p --wds-get-profile-list=3gpp
> // and check contents of the profile 1
>
> If you see a blank APN there, it means you're telling the network you
> don't want any specific APN, and the network should assign one to you.
> If this is the case, looking at the output above, it could be the
> network assigning to you the "super" APN that you don't want.
>
> You can manually configure the attach APN settings to be the same as
> the data APN settings with an explicit mmcli operation:
> $ sudo mmcli -m a
> --3gpp-set-initial-eps-bearer-settings="apn=de1.super,ip-type=ipv4"
>
> If this is the problem, you should try to ensure those settings are in
> place before creating the data APN. E.g. you can first check that the
> settings are the expected ones in the mmcli output, and if they
> aren't, you set them.
>
> $ mmcli -m a -K | grep "modem.3gpp.eps.initial-bearer.settings"
> modem.3gpp.eps.initial-bearer.settings.apn      : --
> modem.3gpp.eps.initial-bearer.settings.ip-type  : --
> modem.3gpp.eps.initial-bearer.settings.user     : --
> modem.3gpp.eps.initial-bearer.settings.password : --
>
> --
> Aleksander
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20240412/58b7b7d8/attachment.htm>


More information about the ModemManager-devel mailing list