Re: On allowing bearer creation from PDP context ID.

[Jessy Exum]

Aleksander,
It is good to know that this type of stuff is on your guy's radar. I will
look over this work as time permits and see if I can expand on it.

I am still pretty new to working with gObject and GDbus, so I will likely
have a plethora of stupid questions, so everyone please bear with me :)

Giacinto,
I have looked at some of the initial esp api stuff. I just figured out how
to disable my modem from auto connecting, so I will actually have some
control over the thing. It does sound like there is more I can learn about
it though.

I will check some resources I have to try and figure out how Verizon would
want an MBIM modem to behave. Hopefully I can provide some definitive
answers so we can add something that doesn't need to be redone in a year.

Thanks for the warm welcome to the community,
Jessy Diamond Exum


On Sat, Sep 5, 2020 at 1:45 AM Giacinto Cifelli  wrote:

> Hello Jessy,
>
> On Sat, Sep 5, 2020 at 10:11 AM Jessy Exum 
> wrote:
>
>> Hello everyone, I hope this finds you well.
>>
>> I have been working on getting a product certified with Verizon, but
>> failed because my first implementation did not handle their OTA-DM (Over
>> the Air Device Management) 
>> behavior. This stage of certification relies heavily on creating bearers
>> out of PDP context IDs (Verizon handles most of the messy bits in setting
>> those contexts for you in the modem).
>>
>> My current solution is to manually read the PDP contexts off of the
>> device with AT+CGDCONT=?, reading out the Verizon mandated PDP context, and
>> then asking ModemManager to create a bearer out of that bearer
>> configuration (which causes ModemManager to scan the list of contexts and
>> find an exact match with the one we just read). This works, but it is
>> cumbersome, and I hear that more networks are planning to move to a similar
>> process in the future (Sprint already has, though I heard that is a little
>> half baked).
>>
>> *Because of this, I feel it would be worthwhile to allow bearers to be
>> created by specifying only a PDP context (and perhaps even an API backed
>> way to inspect them).* This would make passing Verizon certification a
>> lot less hackey than it currently is.
>>
>> I am happy to do as much of the work as necessary, but I want to know the
>> community's opinion of this base proposal, and make sure anything that is
>> built actually solves a problem and will be accepted.
>>
>> *Brief overview of the OTA-DM procedure
>> :*
>> I am not a cellular expert, so please forgive and correct any
>> inaccuracies I may let slip in.
>>
>> For those unfamiliar (I know I was), Verizon has a procedure called
>> OTA-DM for automatically determining the APN to use for a SIM card.
>>
>> Verizon has all compatible modems preloaded with a series of PDP
>> contexts. These PDP Contexts are only available when the modem is running
>> Verizon firmware (which is triggered when a Verizon SIM card is inserted).
>>
>> Verizon expects the initial attach bearer will be created from PDP
>> context #1. This first bearer is only for notifying Verizon that we have
>> attached, and will never pass user traffic.
>>
>> Once this initial bearer connects, Verizon and the modem talk for a
>> while. In this conversation:
>>
>>1. The modem reports details about its SIM card to Verizon,
>>2. Verizon checks its database to see if this is the last SIM card it
>>saw in this modem,
>>3. if this is not the SIM Verizon expected, Verizon will update the
>>modem's PDP contexts to the most up to date settings for this SIM.
>>
>> To clarify, this process will not happen every time you connect. A modem
>> has to connect to Verizon with a different SIM card for Verizon to do this
>> process again (flipping between SIMs for each connection would cause this
>> process to happen for each connection).
>>
>> After this process completes, Verizon expects that the modem will connect
>> using PDP context #3 for the first data bearer. APNs are not touched by the
>> user, only Verizon defined PDP contexts. I found out the hard way that you
>> will fail your device certification if you do not connect using the 3rd
>> context.
>> *END OTA-DM description.*
>>
>> Any input on if we should allow creation of bearers from PDP context
>> numbers to support new cellular network features would be appreciated.
>>
>
> There is an embryo of what you need in the SetInitialEpsBearerSettings().
> For Cinterion modems on VZW networks, the latest MM upstream considers
> that the modem will attach with CID#3. CID#1 is not used, but also should
> not be overwritten.
> I think CID#1 is used internally and transparently.
>
> Ideally it should be possible to specify only the CID for activating a
> PDN, however it is non-portable: modems using MBIM instead of AT commands
> don't support the notion of CID at all.
> I am not sure how VZW specifies the operations for these modems. I know
> th

Re: On allowing bearer creation from PDP context ID.

[Giacinto Cifelli]

Hello Jessy,

On Sat, Sep 5, 2020 at 10:11 AM Jessy Exum 
wrote:

> Hello everyone, I hope this finds you well.
>
> I have been working on getting a product certified with Verizon, but
> failed because my first implementation did not handle their OTA-DM (Over
> the Air Device Management) 
> behavior. This stage of certification relies heavily on creating bearers
> out of PDP context IDs (Verizon handles most of the messy bits in setting
> those contexts for you in the modem).
>
> My current solution is to manually read the PDP contexts off of the device
> with AT+CGDCONT=?, reading out the Verizon mandated PDP context, and then
> asking ModemManager to create a bearer out of that bearer configuration
> (which causes ModemManager to scan the list of contexts and find an exact
> match with the one we just read). This works, but it is cumbersome, and I
> hear that more networks are planning to move to a similar process in the
> future (Sprint already has, though I heard that is a little half baked).
>
> *Because of this, I feel it would be worthwhile to allow bearers to be
> created by specifying only a PDP context (and perhaps even an API backed
> way to inspect them).* This would make passing Verizon certification a
> lot less hackey than it currently is.
>
> I am happy to do as much of the work as necessary, but I want to know the
> community's opinion of this base proposal, and make sure anything that is
> built actually solves a problem and will be accepted.
>
> *Brief overview of the OTA-DM procedure
> :*
> I am not a cellular expert, so please forgive and correct any inaccuracies
> I may let slip in.
>
> For those unfamiliar (I know I was), Verizon has a procedure called OTA-DM
> for automatically determining the APN to use for a SIM card.
>
> Verizon has all compatible modems preloaded with a series of PDP contexts.
> These PDP Contexts are only available when the modem is running Verizon
> firmware (which is triggered when a Verizon SIM card is inserted).
>
> Verizon expects the initial attach bearer will be created from PDP context
> #1. This first bearer is only for notifying Verizon that we have attached,
> and will never pass user traffic.
>
> Once this initial bearer connects, Verizon and the modem talk for a while.
> In this conversation:
>
>1. The modem reports details about its SIM card to Verizon,
>2. Verizon checks its database to see if this is the last SIM card it
>saw in this modem,
>3. if this is not the SIM Verizon expected, Verizon will update the
>modem's PDP contexts to the most up to date settings for this SIM.
>
> To clarify, this process will not happen every time you connect. A modem
> has to connect to Verizon with a different SIM card for Verizon to do this
> process again (flipping between SIMs for each connection would cause this
> process to happen for each connection).
>
> After this process completes, Verizon expects that the modem will connect
> using PDP context #3 for the first data bearer. APNs are not touched by the
> user, only Verizon defined PDP contexts. I found out the hard way that you
> will fail your device certification if you do not connect using the 3rd
> context.
> *END OTA-DM description.*
>
> Any input on if we should allow creation of bearers from PDP context
> numbers to support new cellular network features would be appreciated.
>

There is an embryo of what you need in the SetInitialEpsBearerSettings().
For Cinterion modems on VZW networks, the latest MM upstream considers that
the modem will attach with CID#3. CID#1 is not used, but also should not be
overwritten.
I think CID#1 is used internally and transparently.

Ideally it should be possible to specify only the CID for activating a PDN,
however it is non-portable: modems using MBIM instead of AT commands don't
support the notion of CID at all.
I am not sure how VZW specifies the operations for these modems. I know
that for Cinterion modems AT and MBIM coexist whenever possible, but on the
MBIM_CONNECT there is no CID parameter, only APN (and
username/password/...).

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

Re: On allowing bearer creation from PDP context ID.

[Aleksander Morgado]

Hey Jessy,

> I have been working on getting a product certified with Verizon, but failed 
> because my first implementation did not handle their OTA-DM (Over the Air 
> Device Management) behavior. This stage of certification relies heavily on 
> creating bearers out of PDP context IDs (Verizon handles most of the messy 
> bits in setting those contexts for you in the modem).
>
> My current solution is to manually read the PDP contexts off of the device 
> with AT+CGDCONT=?, reading out the Verizon mandated PDP context, and then 
> asking ModemManager to create a bearer out of that bearer configuration 
> (which causes ModemManager to scan the list of contexts and find an exact 
> match with the one we just read). This works, but it is cumbersome, and I 
> hear that more networks are planning to move to a similar process in the 
> future (Sprint already has, though I heard that is a little half baked).
>
> Because of this, I feel it would be worthwhile to allow bearers to be created 
> by specifying only a PDP context (and perhaps even an API backed way to 
> inspect them). This would make passing Verizon certification a lot less 
> hackey than it currently is.
>

Eric already started drafting an API to expose the currently
configured contexts/bearers, and I believe he also provided an
implementation for QMI and MBIM modems:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/179
It hasn't been a priority, though, so nothing more has been done I believe.

The idea in mind is to allow exposing the context/bearer settings to
the user in a clean way, so that these settings can be not only
queried but also modified. And once that is done, yes, we could
definitely have an API to say "create bearer connection with the
settings in CID ".


> I am happy to do as much of the work as necessary, but I want to know the 
> community's opinion of this base proposal, and make sure anything that is 
> built actually solves a problem and will be accepted.
>

Maybe you could review what Eric has done until now, and see how that
fits your purpose? My last suggestion to Eric, IIRC, was to first try
to define all public APIs, to see how they would look like (i.e. not
only showing the list of profile settings, but also allow changing
them or using them for connection), and then go implement them one by
one.

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