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
Re: Empty APN, 2 PDP contexts and 1 PDP context
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, 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