Understanding Default Bearers and PDP Contexts
Aleksander Morgado
aleksandermj at chromium.org
Tue May 9 09:34:15 UTC 2023
Hey!
>
> Should a bearer of type MM_BEARER_TYPE_DEFAULT correspond 1-1 with a
> modem PDP context?
>
> Said another way, if I have a default bearer with APN B, should `mmcli
> -m 0 --3gpp-profile-list` and `AT+CGDCONT` show a profile/PDP context
> with APN B?
>
They're related but not fully the same. The bearer objects exposed by
MM represent the "independent connections" that have been or may be
triggered with MM. The bearer objects contain settings (e.g.
user-provided settings) as well as state (once it's connected). The
existence of such a bearer object exposed by MM in DBus does NOT mean
a corresponding context is configured in the modem, at least not if
the bearer object is disconnected. Once the bearer object is
connected, there should be a corresponding context configured in the
modem. In fact, the bearer connection sequence involves configuring a
context first and then connecting that context.
> If there isn't a direct correspondence then the rest of this message can
> be ignored. Pessimistically dumping more information here in case this
> is a bug, and for searchability should another find themselves as
> confused as I am.
>
> Configuration Info:
> - Modem: Quectel EG95-NAXD, FW version EG95NAXDGAR07A01M1G
> - Location: US
> - Carrier: AT&T
> - Platform: Yocto Linux (kirkstone)
> - ModemManager version: 1.18.6
> - NetworkManager version: 1.36.2
>
> Problem Description:
> My goal is verifying that traffic is being sent directly to a private
> APN without flowing through the PDN addressed by the initial-attach APN.
>
Ah, nice one.
> My intuition says that this should be possible, and that there would be
> a correspondence between default bearers and PDP contexts. A source [1]
> for which I have no sense of reputation quotes:
>
> > According to 3GPP TS 23.401 [82], there is a 1 to 1 mapping between
> > active EPS bearer context and active PDP context
>
> Reading through 3GPP TS 23.401 version 18.1.0 [2] I haven't been able to
> verify that claim.
>
> In NetworkManager, I have a connection config with
> `[gsm]\napn="m2m.com.attz"` (well, goal is a different APN, but this
> suffices for example). I can see that this creates bearer 1, and
> generating traffic will augment stats on `mmcli -b 1`. However,
> `AT+CGDCONT` and `AT+CGREG` indicate that there isn't a PDP context
> defined with `m2m.com.attz` as APN, and that the active PDP context is
> using the APN of the default-attach bearer 0, `broadband`.
>
> #+begin_quote
> # mmcli -m 0
> -----------------------------------
> General | path: /org/freedesktop/ModemManager1/Modem/0
> | device id: <snip, valid>
> -----------------------------------
> Hardware | manufacturer: QUALCOMM INCORPORATED
> | model: QUECTEL Mobile Broadband Module
> | firmware revision: EG95NAXDGAR07A01M1G
> | carrier config: VoLTE-ATT
> | carrier config revision: 0501033C
> | h/w revision: 10000
> | supported: gsm-umts, lte
> | current: gsm-umts, lte
> | equipment id: <snip, valid>
> -----------------------------------
> System | device: /sys/devices/platform/bus at 5b000000/5b0e0000.usb/ci_hdrc.1/usb1/1-1
> | drivers: option, qmi_wwan
> | plugin: quectel
> | primary port: cdc-wdm0
> | ports: cdc-wdm0 (qmi), ttyUSB0 (qcdm), ttyUSB2 (at), wwan0 (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: 67% (cached)
> -----------------------------------
> Modes | supported: allowed: 3g; preferred: none
> | allowed: 4g; preferred: none
> | allowed: 3g, 4g; preferred: 4g
> | allowed: 3g, 4g; preferred: 3g
> | current: allowed: 2g, 3g, 4g; preferred: 4g
> -----------------------------------
> Bands | supported: utran-4, utran-5, utran-2, eutran-2, eutran-4, eutran-5,
> | eutran-12, eutran-13, eutran-25, eutran-26
> | current: utran-4, utran-5, utran-2, eutran-2, eutran-4, eutran-5,
> | eutran-12, eutran-13, eutran-25, eutran-26
> -----------------------------------
> IP | supported: ipv4, ipv6, ipv4v6
> -----------------------------------
> 3GPP | imei: <snip, valid>
> | enabled locks: fixed-dialing
> | operator id: 310410
> | operator name: AT&T
> | registration: home
> -----------------------------------
> 3GPP EPS | ue mode of operation: csps-2
> | initial bearer path: /org/freedesktop/ModemManager1/Bearer/0
> | initial bearer apn: broadband
> | initial bearer ip type: ipv4
> -----------------------------------
> SIM | primary sim path: /org/freedesktop/ModemManager1/SIM/0
> | sim slot paths: slot 1: /org/freedesktop/ModemManager1/SIM/0 (active)
> | slot 2: none
> -----------------------------------
> Bearer | paths: /org/freedesktop/ModemManager1/Bearer/1
>
> # 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: broadband
> | ip type: ipv4
This is the initial attach APN.
> # mmcli -b 1
> ------------------------------------
> General | path: /org/freedesktop/ModemManager1/Bearer/1
> | type: default
> ------------------------------------
> Status | connected: yes
> | suspended: no
> | multiplexed: no
> | interface: wwan0
> | ip timeout: 20
> ------------------------------------
> Properties | apn: m2m.com.attz
> | roaming: allowed
> | ip type: ipv4v6
> ------------------------------------
> IPv4 configuration | method: static
> | address: 10.45.22.52
> | prefix: 29
> | gateway: 10.45.22.53
> | dns: 8.8.8.8, 8.8.4.4
> | mtu: 1430
> ------------------------------------
> Statistics | duration: 119
> | bytes rx: 27608
> | bytes tx: 26331
> | attempts: 1
> | total-duration: 119
> | total-bytes rx: 27608
> | total-bytes tx: 26331
>
This one above is the extra APN, different to the attach one. The host
at this point ONLY knows about the IP settings associated to this
extra APN.
> # at 'AT+CGDCONT?'
>
> +CGDCONT: 1,"IP","broadband","0.0.0.0",0,0,0,0
> +CGDCONT: 16,"IPV4V6","attm2mglobal","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0
> +CGDCONT: 2,"IPV4V6","ims","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,0
> +CGDCONT: 3,"IPV4V6","sos","0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0",0,0,0,1
>
> OK
We're not using AT commands to connect your modem, we're using QMI,
and so I wouldn't be surprised if the IP settings are not populated in
the +CGDCONT? response.
When using QMI, we rely on the "QMI WDS Start Network" command to
setup the data connection, and that one internally is the one setting
up the context to use in the modem, we don't explicitly create any
context (stored profile) ourselves, although we could do that. MM has
a profile manager interface, and so you could say "create a profile
with these settings" and then in the connection attempt we can say
"connect profile N". When using NetworkManager we don't use profiles
like this, we just pass the connection settings to use in the
connection attempt.
For your usecase in hand, you should realize that you don't have IP
settings for the initial attach APN, we only know that the initial
attach APN was agreed with the network, and that's about it. Your
connection attempt is with a different APN, and you have IP settings
for that APN, so your host will always send IP traffic through that
different APN.
--
Aleksander
More information about the ModemManager-devel
mailing list