Re: [RFC] Deprecate SubscriptionState?
Hey, >> > Why raw PCO data in hex string? Why not directly the binary data? >> > e.g. >> > "ay" instead of "s". The signature could be then "a(iay)" >> >> Yeah I'd vote for byte array eg "a(iay)" (eg array of struct of integer >> + byte array). >> > > Sounds good. We will need to indicate whether the received PCO is > partial or complete, so I'll go with something like an array of struct > of (uint32 + boolean + byte array), i.e. a(ubay). > > I'm planning to do the following: > 1. introduce the new Pco property under Modem3gpp interface > 2. set it up for modems supporting MBIM_CID_PCO > 3. migrate the altair-lte plugin to use the Pco property > 4. migrate Chromium OS to use the Pco property instead of the > SubscriptionState property > 5. remove the SubscriptionState property from Modem3gpp -- this is an > MM API break, so a version bump will be needed > > Does that sound like a plan? > LGTM. For the last step, you could cherry pick this commit, where I don't totally remove the property, but flag it as deprecated. https://gitlab.freedesktop.org/mobile-broadband/ModemManager/commit/b382302ef64281329127066253eeeb4aa5736544 -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [RFC] Deprecate SubscriptionState?
On Tue, Aug 7, 2018 at 7:22 AM Dan Williams wrote: > > On Tue, 2018-08-07 at 01:07 +0200, Aleksander Morgado wrote: > > Hey, > > > > Why raw PCO data in hex string? Why not directly the binary data? > > e.g. > > "ay" instead of "s". The signature could be then "a(iay)" > > Yeah I'd vote for byte array eg "a(iay)" (eg array of struct of integer > + byte array). > Sounds good. We will need to indicate whether the received PCO is partial or complete, so I'll go with something like an array of struct of (uint32 + boolean + byte array), i.e. a(ubay). I'm planning to do the following: 1. introduce the new Pco property under Modem3gpp interface 2. set it up for modems supporting MBIM_CID_PCO 3. migrate the altair-lte plugin to use the Pco property 4. migrate Chromium OS to use the Pco property instead of the SubscriptionState property 5. remove the SubscriptionState property from Modem3gpp -- this is an MM API break, so a version bump will be needed Does that sound like a plan? > Dan ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [RFC] Deprecate SubscriptionState?
On Tue, 2018-08-07 at 01:07 +0200, Aleksander Morgado wrote:
> Hey,
>
> > >
> > > At some point we need to handle network-initiated bearers in MM
> > > though.
> > >
> >
> > Given that the SessionId reported in a MBIM_CID_PCO notification
> > may
> > not be associated with any CID managed/known to ModemManager, we
> > may
> > simply expose a PCO property under the Modem3gpp interface. The PCO
> > property can be a list of (session_id, raw_pco_data_in_hex_str)
> > pair
> > (i.e. a(is) or a{is} as the D-Bus type). Does that make sense?
>
> Why raw PCO data in hex string? Why not directly the binary data?
> e.g.
> "ay" instead of "s". The signature could be then "a(iay)"
Yeah I'd vote for byte array eg "a(iay)" (eg array of struct of integer
+ byte array).
Dan
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [RFC] Deprecate SubscriptionState?
Hey,
>>
>> At some point we need to handle network-initiated bearers in MM though.
>>
>
> Given that the SessionId reported in a MBIM_CID_PCO notification may
> not be associated with any CID managed/known to ModemManager, we may
> simply expose a PCO property under the Modem3gpp interface. The PCO
> property can be a list of (session_id, raw_pco_data_in_hex_str) pair
> (i.e. a(is) or a{is} as the D-Bus type). Does that make sense?
Why raw PCO data in hex string? Why not directly the binary data? e.g.
"ay" instead of "s". The signature could be then "a(iay)"
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [RFC] Deprecate SubscriptionState?
Hey, > I guess we could depreciate the SubscriptionState property and let > ModemManger simply forward PCO notifications to other clients. What > D-Bus interface are you considering? For the Altair modem, we may > need to cheat a little bit by repackaging the partial PCO info into a > valid PCO structure. > I was just thinking in a property providing a raw bytearray to contain the PCO info. Would that be enough? -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [RFC] Deprecate SubscriptionState?
Hi Aleksander, I'm actually wiring up SubscriptionState for some MBIM modems that support MBIM_CID_PCO (which just landed in libmbim), and about to send over some patches. It's true that the PCO of interest is the Verizon-specific PCO, which is used for several use cases (e.g. the SIM is unprovisioned / no active subscription, the account runs out of data allowance, etc). It's also true that some modems only support/expose Verizon-specific PCO, which is likely due to certification requirements from Verizon. The MBIM_CID_PCO document from Microsoft also uses Verizon PCO as an example :-| We went with the SubscriptionState property mostly because the Altair modem only reports a portion of the PCO (e.g. FF00 130184xx). I'm testing another MBIM modem which exposes raw PCO info, which is tied to an active connection (i.e. MBIM_CID_PCO SessionId is tied to MBIM_CID_CONNECT SessionId) and are updated over time via MBIM_CID_PCO notifications. I guess we could depreciate the SubscriptionState property and let ModemManger simply forward PCO notifications to other clients. What D-Bus interface are you considering? For the Altair modem, we may need to cheat a little bit by repackaging the partial PCO info into a valid PCO structure. Thanks, Ben On Sat, Jul 28, 2018 at 1:43 PM Aleksander Morgado wrote: > > Hey Dan, Ben & all, > > The SubscriptionState property was originally thought to expose the > state of the subscription with the operator. It has been implemented > only in the Altair LTE plugin, and the current implementation is based > on two main things: > * Verizon-specific logic that allows knowing the subscription state > based on the PCO info. > * Registration check errors, e.g. to say that the SIM is > unprovisioned when the registration fails. > > I'm not sure any of the previous two things are very robust. The > Verizon-specific parsing will only work for Verizon, and the > registration check errors may be caused by multiple different root > causes. To me it looks like the Altair LTE plugin is trying to do more > than it's supposed to do. It would be much better if we exposed the > raw PCO info received, and let upper layers process that if needed > with operator-specific logic. > > What do you all think? > Should we deprecate the SubscriptionState property? > Should we expose the raw PCO info? > > -- > Aleksander > https://aleksander.es > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [RFC] Deprecate SubscriptionState?
We've really been wanting to get it working better for our customers, but honestly your summary is true. Carriers aren't supporting hooks to reliably to get the information. I personally haven't seen a 3GPP command in the data sheets I have to get the info either. If that changes I'd be the first to bring it back but until then it's kind of a dead field. IMHO On Sat, Jul 28, 2018 at 2:42 PM, Aleksander Morgado < aleksan...@aleksander.es> wrote: > Hey Dan, Ben & all, > > The SubscriptionState property was originally thought to expose the > state of the subscription with the operator. It has been implemented > only in the Altair LTE plugin, and the current implementation is based > on two main things: > * Verizon-specific logic that allows knowing the subscription state > based on the PCO info. > * Registration check errors, e.g. to say that the SIM is > unprovisioned when the registration fails. > > I'm not sure any of the previous two things are very robust. The > Verizon-specific parsing will only work for Verizon, and the > registration check errors may be caused by multiple different root > causes. To me it looks like the Altair LTE plugin is trying to do more > than it's supposed to do. It would be much better if we exposed the > raw PCO info received, and let upper layers process that if needed > with operator-specific logic. > > What do you all think? > Should we deprecate the SubscriptionState property? > Should we expose the raw PCO info? > > -- > Aleksander > https://aleksander.es > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel > ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
[RFC] Deprecate SubscriptionState?
Hey Dan, Ben & all, The SubscriptionState property was originally thought to expose the state of the subscription with the operator. It has been implemented only in the Altair LTE plugin, and the current implementation is based on two main things: * Verizon-specific logic that allows knowing the subscription state based on the PCO info. * Registration check errors, e.g. to say that the SIM is unprovisioned when the registration fails. I'm not sure any of the previous two things are very robust. The Verizon-specific parsing will only work for Verizon, and the registration check errors may be caused by multiple different root causes. To me it looks like the Altair LTE plugin is trying to do more than it's supposed to do. It would be much better if we exposed the raw PCO info received, and let upper layers process that if needed with operator-specific logic. What do you all think? Should we deprecate the SubscriptionState property? Should we expose the raw PCO info? -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
