Re: ModemManager [PATCH 2/2] Take 3 of: Improvements to SIM PIN handling - Add EnabledFacilityLocks property
> > > > > I guess I don't have a problem with merging them, although strictly
> > > > > speaking they refer to different things - locks vs. the PINs needed to
> > > > > unlock those locks.
> > > > >
> > > > Yeah, you're totally right... but at the end the PIN/PUK codes are
> > > > directly related to facilities. E.g "SIM facility", has "PIN code" and
> > > > "PUK code". But it really seems broken to use the enum of codes as index
> > > > for facilities, not the best idea.
> > > > >
> > > > > Two other points to consider regarding lock/PIN handling in the new
> > > > > API:
> > > > > * PIN, PUK, PIN2, and PUK2 are PINs for SIM locks. The rest are
> > > > > device locks, so having them belong to the *.Sim interface
> > > > > doesn't seem completely right. But 3gpp gloms them all
> > > > > together, so maybe we should just live with this.
> > > >
> > > > In the 0.6 API they are not handled in the SIM interface. UnlockRetries
> > > > and PinRetryCounts are handled in the Modem interface, along with
> > > > UnlockRequired; and the EnabledFacilityLocks one is handled in the 3GPP
> > > > interface. Anyway, I'm not very convinced yet, on why we do keep
> > > > EnabledFacilityLocks in one interface and
> > > > UnlockRetries/PinRetryCounts/UnlockRequired in another one. Shouldn't we
> > > > have all in the 3GPP-specific interface? Are there CDMA-only modems with
> > > > facility locks?
> > >
> > > In Russia and Korea there's RUIMs which are basically SIMs for CDMA and
> > > aren't 3GPP at all. They may use the same basic interfaces, but there's
> > > a lot of Qualcomm-iness in there. I kept the PIN/Lock stuff on the
> > > Modem interface so that we could more easily support these types of
> > > devices in the future.
> > >
> >
> > I see, good to know.
> >
> > > > > * Shouldn't we add an argument to EnablePin and ChangePin that
> > > > > specifies the lock to which the operation should apply? This
> > > > > would mirror the CLCK and CPWD AT commands, which take the
> > > > > facility name as an argument. This would correct what seems to
> > > > > be an oversight in the current API.
> > > >
> > > > Not an oversight, just that the main use case is to be able to
> > > > Enable/Change the SIM PIN, and the idea was to keep it simple. But now
> > > > that we report if given facility locks are enabled or disabled, it could
> > > > make sense to also allow trying to enable/disable all reported ones. We
> > > > would need to move Enable() and Change() out from the SIM object and
> > > > back to some interface in the Modem object.
> > > >
> > > > And now that you talk about EnablePin() and ChangePin(); the same logic
> > > > could be applied to SendPin() and SendPuk(). SendPin()/SendPuk() should
> > > > be used only when UnlockRequired says that there is something to unlock;
> > > > they are actually backed by the same CPIN command. So, UnlockRequired
> > > > may be saying "ph-sim-pin" (phone-specific PIN required), and we can
> > > > then use SendPin() to send that specific code to the modem. Therefore,
> > > > SendPin() is really not related to the SIM, but to UnlockRequired, and
> > > > so they ought to be in the same interface (in the 0.6 API, SendPin() and
> > > > SendPuk() are managed in the SIM object).
> > >
> > > That makes some sense. They were originally added when the world was a
> > > simpler place :)
> > >
> >
> > If we do move SendPin(), SendPuk, ChangePin(), EnablePin() out of the
> > SIM object, not sure if it is worth having it around.
> >
> > > >
> > > > And a new brainstorm here... given that we're going to break the DBus
> > > > API, we can try to rework and consolidate all related properties.
> > > >
> > > > We could assume that each facility has 2 codes (PIN, PUK), and that the
> > > > PUK code will only be required once all PIN attempts have been used
> > > > (didn't look at any documentation, but that seems to me always the
> > > > case).
> > >
> > > That looks to be the case, yes. The non-call-barring CLCK facilities
> > > have corresponding lock codes that would be reported by +CPIN?.
> > >
> > > > If we do assume this, we could then setup a "FacilityLocks" dictionary
> > > > with signature "a{ubuu}" where:
> > > > * The uint32 in the first position identifies the facility.
> > > > * The boolean in the second position tells whether the facility has a
> > > > lock.
> > > > * The uint32 in the third position has the PIN retry count.
> > > > * The uint32 in the fourth position has the PUK retry count.
> > > >
> > > > Then, we could have UnlockRequired be just a uint32 where we identify
> > > > the 'facility' locked (as opposed to identifying which pin code we
> > > > need).
> > >
> > > I assume you're suggesting we do an enum for facilities? (which is
> > > fine)
> > >
> >
> > We already have that enum, MMModemGsmFacility is called in git master.
> >
> > > > So, if we get "SIM" facility in UnlockRequired,
Re: ModemManager [PATCH 2/2] Take 3 of: Improvements to SIM PIN handling - Add EnabledFacilityLocks property
On Thu, 2011-12-01 at 09:11 +0100, Aleksander Morgado wrote:
> > > > I guess I don't have a problem with merging them, although strictly
> > > > speaking they refer to different things - locks vs. the PINs needed to
> > > > unlock those locks.
> > > >
> > > Yeah, you're totally right... but at the end the PIN/PUK codes are
> > > directly related to facilities. E.g "SIM facility", has "PIN code" and
> > > "PUK code". But it really seems broken to use the enum of codes as index
> > > for facilities, not the best idea.
> > > >
> > > > Two other points to consider regarding lock/PIN handling in the new
> > > > API:
> > > > * PIN, PUK, PIN2, and PUK2 are PINs for SIM locks. The rest are
> > > > device locks, so having them belong to the *.Sim interface
> > > > doesn't seem completely right. But 3gpp gloms them all
> > > > together, so maybe we should just live with this.
> > >
> > > In the 0.6 API they are not handled in the SIM interface. UnlockRetries
> > > and PinRetryCounts are handled in the Modem interface, along with
> > > UnlockRequired; and the EnabledFacilityLocks one is handled in the 3GPP
> > > interface. Anyway, I'm not very convinced yet, on why we do keep
> > > EnabledFacilityLocks in one interface and
> > > UnlockRetries/PinRetryCounts/UnlockRequired in another one. Shouldn't we
> > > have all in the 3GPP-specific interface? Are there CDMA-only modems with
> > > facility locks?
> >
> > In Russia and Korea there's RUIMs which are basically SIMs for CDMA and
> > aren't 3GPP at all. They may use the same basic interfaces, but there's
> > a lot of Qualcomm-iness in there. I kept the PIN/Lock stuff on the
> > Modem interface so that we could more easily support these types of
> > devices in the future.
> >
>
> I see, good to know.
>
> > > > * Shouldn't we add an argument to EnablePin and ChangePin that
> > > > specifies the lock to which the operation should apply? This
> > > > would mirror the CLCK and CPWD AT commands, which take the
> > > > facility name as an argument. This would correct what seems to
> > > > be an oversight in the current API.
> > >
> > > Not an oversight, just that the main use case is to be able to
> > > Enable/Change the SIM PIN, and the idea was to keep it simple. But now
> > > that we report if given facility locks are enabled or disabled, it could
> > > make sense to also allow trying to enable/disable all reported ones. We
> > > would need to move Enable() and Change() out from the SIM object and
> > > back to some interface in the Modem object.
> > >
> > > And now that you talk about EnablePin() and ChangePin(); the same logic
> > > could be applied to SendPin() and SendPuk(). SendPin()/SendPuk() should
> > > be used only when UnlockRequired says that there is something to unlock;
> > > they are actually backed by the same CPIN command. So, UnlockRequired
> > > may be saying "ph-sim-pin" (phone-specific PIN required), and we can
> > > then use SendPin() to send that specific code to the modem. Therefore,
> > > SendPin() is really not related to the SIM, but to UnlockRequired, and
> > > so they ought to be in the same interface (in the 0.6 API, SendPin() and
> > > SendPuk() are managed in the SIM object).
> >
> > That makes some sense. They were originally added when the world was a
> > simpler place :)
> >
>
> If we do move SendPin(), SendPuk, ChangePin(), EnablePin() out of the
> SIM object, not sure if it is worth having it around.
>
> > >
> > > And a new brainstorm here... given that we're going to break the DBus
> > > API, we can try to rework and consolidate all related properties.
> > >
> > > We could assume that each facility has 2 codes (PIN, PUK), and that the
> > > PUK code will only be required once all PIN attempts have been used
> > > (didn't look at any documentation, but that seems to me always the
> > > case).
> >
> > That looks to be the case, yes. The non-call-barring CLCK facilities
> > have corresponding lock codes that would be reported by +CPIN?.
> >
> > > If we do assume this, we could then setup a "FacilityLocks" dictionary
> > > with signature "a{ubuu}" where:
> > > * The uint32 in the first position identifies the facility.
> > > * The boolean in the second position tells whether the facility has a
> > > lock.
> > > * The uint32 in the third position has the PIN retry count.
> > > * The uint32 in the fourth position has the PUK retry count.
> > >
> > > Then, we could have UnlockRequired be just a uint32 where we identify
> > > the 'facility' locked (as opposed to identifying which pin code we
> > > need).
> >
> > I assume you're suggesting we do an enum for facilities? (which is
> > fine)
> >
>
> We already have that enum, MMModemGsmFacility is called in git master.
>
> > > So, if we get "SIM" facility in UnlockRequired, we could then check the
> > > corresponding entry in the FacilityLocks dictionary and see how many
> > > retry counts we have for
Re: ModemManager [PATCH 2/2] Take 3 of: Improvements to SIM PIN handling - Add EnabledFacilityLocks property
> > > I guess I don't have a problem with merging them, although strictly
> > > speaking they refer to different things - locks vs. the PINs needed to
> > > unlock those locks.
> > >
> > Yeah, you're totally right... but at the end the PIN/PUK codes are
> > directly related to facilities. E.g "SIM facility", has "PIN code" and
> > "PUK code". But it really seems broken to use the enum of codes as index
> > for facilities, not the best idea.
> > >
> > > Two other points to consider regarding lock/PIN handling in the new
> > > API:
> > > * PIN, PUK, PIN2, and PUK2 are PINs for SIM locks. The rest are
> > > device locks, so having them belong to the *.Sim interface
> > > doesn't seem completely right. But 3gpp gloms them all
> > > together, so maybe we should just live with this.
> >
> > In the 0.6 API they are not handled in the SIM interface. UnlockRetries
> > and PinRetryCounts are handled in the Modem interface, along with
> > UnlockRequired; and the EnabledFacilityLocks one is handled in the 3GPP
> > interface. Anyway, I'm not very convinced yet, on why we do keep
> > EnabledFacilityLocks in one interface and
> > UnlockRetries/PinRetryCounts/UnlockRequired in another one. Shouldn't we
> > have all in the 3GPP-specific interface? Are there CDMA-only modems with
> > facility locks?
>
> In Russia and Korea there's RUIMs which are basically SIMs for CDMA and
> aren't 3GPP at all. They may use the same basic interfaces, but there's
> a lot of Qualcomm-iness in there. I kept the PIN/Lock stuff on the
> Modem interface so that we could more easily support these types of
> devices in the future.
>
I see, good to know.
> > > * Shouldn't we add an argument to EnablePin and ChangePin that
> > > specifies the lock to which the operation should apply? This
> > > would mirror the CLCK and CPWD AT commands, which take the
> > > facility name as an argument. This would correct what seems to
> > > be an oversight in the current API.
> >
> > Not an oversight, just that the main use case is to be able to
> > Enable/Change the SIM PIN, and the idea was to keep it simple. But now
> > that we report if given facility locks are enabled or disabled, it could
> > make sense to also allow trying to enable/disable all reported ones. We
> > would need to move Enable() and Change() out from the SIM object and
> > back to some interface in the Modem object.
> >
> > And now that you talk about EnablePin() and ChangePin(); the same logic
> > could be applied to SendPin() and SendPuk(). SendPin()/SendPuk() should
> > be used only when UnlockRequired says that there is something to unlock;
> > they are actually backed by the same CPIN command. So, UnlockRequired
> > may be saying "ph-sim-pin" (phone-specific PIN required), and we can
> > then use SendPin() to send that specific code to the modem. Therefore,
> > SendPin() is really not related to the SIM, but to UnlockRequired, and
> > so they ought to be in the same interface (in the 0.6 API, SendPin() and
> > SendPuk() are managed in the SIM object).
>
> That makes some sense. They were originally added when the world was a
> simpler place :)
>
If we do move SendPin(), SendPuk, ChangePin(), EnablePin() out of the
SIM object, not sure if it is worth having it around.
> >
> > And a new brainstorm here... given that we're going to break the DBus
> > API, we can try to rework and consolidate all related properties.
> >
> > We could assume that each facility has 2 codes (PIN, PUK), and that the
> > PUK code will only be required once all PIN attempts have been used
> > (didn't look at any documentation, but that seems to me always the
> > case).
>
> That looks to be the case, yes. The non-call-barring CLCK facilities
> have corresponding lock codes that would be reported by +CPIN?.
>
> > If we do assume this, we could then setup a "FacilityLocks" dictionary
> > with signature "a{ubuu}" where:
> > * The uint32 in the first position identifies the facility.
> > * The boolean in the second position tells whether the facility has a
> > lock.
> > * The uint32 in the third position has the PIN retry count.
> > * The uint32 in the fourth position has the PUK retry count.
> >
> > Then, we could have UnlockRequired be just a uint32 where we identify
> > the 'facility' locked (as opposed to identifying which pin code we
> > need).
>
> I assume you're suggesting we do an enum for facilities? (which is
> fine)
>
We already have that enum, MMModemGsmFacility is called in git master.
> > So, if we get "SIM" facility in UnlockRequired, we could then check the
> > corresponding entry in the FacilityLocks dictionary and see how many
> > retry counts we have for PIN and PUK. If retries for PIN is 0; it means
> > we need the PUK code, unless PUK retries is also 0, which would mean we
> > need to buy a new SIM card. Instead of just the key of the dictionary
> > entry, we could also have the UnlockRequired propert
Re: ModemManager [PATCH 2/2] Take 3 of: Improvements to SIM PIN handling - Add EnabledFacilityLocks property
On Wed, 2011-11-23 at 20:14 +0100, Aleksander Morgado wrote:
> Hey hey,
>
> > I guess I don't have a problem with merging them, although strictly
> > speaking they refer to different things - locks vs. the PINs needed to
> > unlock those locks.
> >
> Yeah, you're totally right... but at the end the PIN/PUK codes are
> directly related to facilities. E.g "SIM facility", has "PIN code" and
> "PUK code". But it really seems broken to use the enum of codes as index
> for facilities, not the best idea.
> >
> > Two other points to consider regarding lock/PIN handling in the new
> > API:
> > * PIN, PUK, PIN2, and PUK2 are PINs for SIM locks. The rest are
> > device locks, so having them belong to the *.Sim interface
> > doesn't seem completely right. But 3gpp gloms them all
> > together, so maybe we should just live with this.
>
> In the 0.6 API they are not handled in the SIM interface. UnlockRetries
> and PinRetryCounts are handled in the Modem interface, along with
> UnlockRequired; and the EnabledFacilityLocks one is handled in the 3GPP
> interface. Anyway, I'm not very convinced yet, on why we do keep
> EnabledFacilityLocks in one interface and
> UnlockRetries/PinRetryCounts/UnlockRequired in another one. Shouldn't we
> have all in the 3GPP-specific interface? Are there CDMA-only modems with
> facility locks?
In Russia and Korea there's RUIMs which are basically SIMs for CDMA and
aren't 3GPP at all. They may use the same basic interfaces, but there's
a lot of Qualcomm-iness in there. I kept the PIN/Lock stuff on the
Modem interface so that we could more easily support these types of
devices in the future.
> > * Shouldn't we add an argument to EnablePin and ChangePin that
> > specifies the lock to which the operation should apply? This
> > would mirror the CLCK and CPWD AT commands, which take the
> > facility name as an argument. This would correct what seems to
> > be an oversight in the current API.
>
> Not an oversight, just that the main use case is to be able to
> Enable/Change the SIM PIN, and the idea was to keep it simple. But now
> that we report if given facility locks are enabled or disabled, it could
> make sense to also allow trying to enable/disable all reported ones. We
> would need to move Enable() and Change() out from the SIM object and
> back to some interface in the Modem object.
>
> And now that you talk about EnablePin() and ChangePin(); the same logic
> could be applied to SendPin() and SendPuk(). SendPin()/SendPuk() should
> be used only when UnlockRequired says that there is something to unlock;
> they are actually backed by the same CPIN command. So, UnlockRequired
> may be saying "ph-sim-pin" (phone-specific PIN required), and we can
> then use SendPin() to send that specific code to the modem. Therefore,
> SendPin() is really not related to the SIM, but to UnlockRequired, and
> so they ought to be in the same interface (in the 0.6 API, SendPin() and
> SendPuk() are managed in the SIM object).
That makes some sense. They were originally added when the world was a
simpler place :)
>
> And a new brainstorm here... given that we're going to break the DBus
> API, we can try to rework and consolidate all related properties.
>
> We could assume that each facility has 2 codes (PIN, PUK), and that the
> PUK code will only be required once all PIN attempts have been used
> (didn't look at any documentation, but that seems to me always the
> case).
That looks to be the case, yes. The non-call-barring CLCK facilities
have corresponding lock codes that would be reported by +CPIN?.
> If we do assume this, we could then setup a "FacilityLocks" dictionary
> with signature "a{ubuu}" where:
> * The uint32 in the first position identifies the facility.
> * The boolean in the second position tells whether the facility has a
> lock.
> * The uint32 in the third position has the PIN retry count.
> * The uint32 in the fourth position has the PUK retry count.
>
> Then, we could have UnlockRequired be just a uint32 where we identify
> the 'facility' locked (as opposed to identifying which pin code we
> need).
I assume you're suggesting we do an enum for facilities? (which is
fine)
> So, if we get "SIM" facility in UnlockRequired, we could then check the
> corresponding entry in the FacilityLocks dictionary and see how many
> retry counts we have for PIN and PUK. If retries for PIN is 0; it means
> we need the PUK code, unless PUK retries is also 0, which would mean we
> need to buy a new SIM card. Instead of just the key of the dictionary
> entry, we could also have the UnlockRequired property be a (ubuu); which
> would contain the whole entry of the dictionary.
>
> Thoughts?
Sounds OK to me, any thoughts Eric?
Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager [PATCH 2/2] Take 3 of: Improvements to SIM PIN handling - Add EnabledFacilityLocks property
Hey hey,
> I guess I don't have a problem with merging them, although strictly
> speaking they refer to different things - locks vs. the PINs needed to
> unlock those locks.
>
Yeah, you're totally right... but at the end the PIN/PUK codes are
directly related to facilities. E.g "SIM facility", has "PIN code" and
"PUK code". But it really seems broken to use the enum of codes as index
for facilities, not the best idea.
>
> Two other points to consider regarding lock/PIN handling in the new
> API:
> * PIN, PUK, PIN2, and PUK2 are PINs for SIM locks. The rest are
> device locks, so having them belong to the *.Sim interface
> doesn't seem completely right. But 3gpp gloms them all
> together, so maybe we should just live with this.
In the 0.6 API they are not handled in the SIM interface. UnlockRetries
and PinRetryCounts are handled in the Modem interface, along with
UnlockRequired; and the EnabledFacilityLocks one is handled in the 3GPP
interface. Anyway, I'm not very convinced yet, on why we do keep
EnabledFacilityLocks in one interface and
UnlockRetries/PinRetryCounts/UnlockRequired in another one. Shouldn't we
have all in the 3GPP-specific interface? Are there CDMA-only modems with
facility locks?
> * Shouldn't we add an argument to EnablePin and ChangePin that
> specifies the lock to which the operation should apply? This
> would mirror the CLCK and CPWD AT commands, which take the
> facility name as an argument. This would correct what seems to
> be an oversight in the current API.
Not an oversight, just that the main use case is to be able to
Enable/Change the SIM PIN, and the idea was to keep it simple. But now
that we report if given facility locks are enabled or disabled, it could
make sense to also allow trying to enable/disable all reported ones. We
would need to move Enable() and Change() out from the SIM object and
back to some interface in the Modem object.
And now that you talk about EnablePin() and ChangePin(); the same logic
could be applied to SendPin() and SendPuk(). SendPin()/SendPuk() should
be used only when UnlockRequired says that there is something to unlock;
they are actually backed by the same CPIN command. So, UnlockRequired
may be saying "ph-sim-pin" (phone-specific PIN required), and we can
then use SendPin() to send that specific code to the modem. Therefore,
SendPin() is really not related to the SIM, but to UnlockRequired, and
so they ought to be in the same interface (in the 0.6 API, SendPin() and
SendPuk() are managed in the SIM object).
And a new brainstorm here... given that we're going to break the DBus
API, we can try to rework and consolidate all related properties.
We could assume that each facility has 2 codes (PIN, PUK), and that the
PUK code will only be required once all PIN attempts have been used
(didn't look at any documentation, but that seems to me always the
case).
If we do assume this, we could then setup a "FacilityLocks" dictionary
with signature "a{ubuu}" where:
* The uint32 in the first position identifies the facility.
* The boolean in the second position tells whether the facility has a
lock.
* The uint32 in the third position has the PIN retry count.
* The uint32 in the fourth position has the PUK retry count.
Then, we could have UnlockRequired be just a uint32 where we identify
the 'facility' locked (as opposed to identifying which pin code we
need).
So, if we get "SIM" facility in UnlockRequired, we could then check the
corresponding entry in the FacilityLocks dictionary and see how many
retry counts we have for PIN and PUK. If retries for PIN is 0; it means
we need the PUK code, unless PUK retries is also 0, which would mean we
need to buy a new SIM card. Instead of just the key of the dictionary
entry, we could also have the UnlockRequired property be a (ubuu); which
would contain the whole entry of the dictionary.
Thoughts?
--
Aleksander
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager [PATCH 2/2] Take 3 of: Improvements to SIM PIN handling - Add EnabledFacilityLocks property
I guess I don't have a problem with merging them, although strictly speaking they refer to different things - locks vs. the PINs needed to unlock those locks. Two other points to consider regarding lock/PIN handling in the new API: - PIN, PUK, PIN2, and PUK2 are PINs for SIM locks. The rest are device locks, so having them belong to the *.Sim interface doesn't seem completely right. But 3gpp gloms them all together, so maybe we should just live with this. - Shouldn't we add an argument to EnablePin and ChangePin that specifies the lock to which the operation should apply? This would mirror the CLCK and CPWD AT commands, which take the facility name as an argument. This would correct what seems to be an oversight in the current API. Eric On Wed, Nov 23, 2011 at 9:58 AM, Aleksander Morgado wrote: > Hey Eric & Dan, > > On Fri, 2011-11-11 at 15:10 -0500, Eric Shienbrood wrote: > > Subject: [PATCH] Added new property to track which facility locks are > > enabled. > > > > The property EnabledFacilityLocks on the .Modem.Gsm.Card interface > > is a bit mask that indicates which of the various personalization > > codes from 3GPP TS 22.022, plus the SIM PIN lock and SIM PIN2 lock, > > are enabled. The set of facility locks supported by the modem is > > determined at the time the modem is initialized, and the state of > > each supported lock (enabled or disabled) is determined. When the > > state of a lock changes, a property-change signal is sent out. Note > > that ModemManager only supports enabling and disabling SIM-PIN, via > > the EnablePin method on Modem.Gsm.Card. > > One of the changes I did in the new API was to have a new enum being > reported in the "UnlockRequired" property instead of a string. I called > this "MMModemLock", see: > > http://www.lanedo.com/~aleksander/modem-manager/api-2023/mm-Flags-and-Enumerations.html#MMModemLock > > I also included your new MMModemGsmFacility enum in the new API, as > well, named "MMModem3gppFacility": > > http://www.lanedo.com/~aleksander/modem-manager/api-2023/mm-Flags-and-Enumerations.html#MMModem3gppFacility > > Any problem in merging these both types? It could be just making > MMModemLock be a flags value instead of an enum. As far as I can see > "MMModem3gppFacility" is a subset of "MMModemLock". > > Cheers, > > -- > Aleksander > > ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager [PATCH 2/2] Take 3 of: Improvements to SIM PIN handling - Add EnabledFacilityLocks property
Hey Eric & Dan, On Fri, 2011-11-11 at 15:10 -0500, Eric Shienbrood wrote: > Subject: [PATCH] Added new property to track which facility locks are > enabled. > > The property EnabledFacilityLocks on the .Modem.Gsm.Card interface > is a bit mask that indicates which of the various personalization > codes from 3GPP TS 22.022, plus the SIM PIN lock and SIM PIN2 lock, > are enabled. The set of facility locks supported by the modem is > determined at the time the modem is initialized, and the state of > each supported lock (enabled or disabled) is determined. When the > state of a lock changes, a property-change signal is sent out. Note > that ModemManager only supports enabling and disabling SIM-PIN, via > the EnablePin method on Modem.Gsm.Card. One of the changes I did in the new API was to have a new enum being reported in the "UnlockRequired" property instead of a string. I called this "MMModemLock", see: http://www.lanedo.com/~aleksander/modem-manager/api-2023/mm-Flags-and-Enumerations.html#MMModemLock I also included your new MMModemGsmFacility enum in the new API, as well, named "MMModem3gppFacility": http://www.lanedo.com/~aleksander/modem-manager/api-2023/mm-Flags-and-Enumerations.html#MMModem3gppFacility Any problem in merging these both types? It could be just making MMModemLock be a flags value instead of an enum. As far as I can see "MMModem3gppFacility" is a subset of "MMModemLock". Cheers, -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
ModemManager [PATCH 2/2] Take 3 of: Improvements to SIM PIN handling - Add EnabledFacilityLocks property
From 2594d75ec8535e54afb556708a8e17ab77ed68bd Mon Sep 17 00:00:00 2001
From: Eric Shienbrood
Date: Thu, 11 Aug 2011 13:58:59 -0400
Subject: [PATCH] Added new property to track which facility locks are enabled.
The property EnabledFacilityLocks on the .Modem.Gsm.Card interface
is a bit mask that indicates which of the various personalization
codes from 3GPP TS 22.022, plus the SIM PIN lock and SIM PIN2 lock,
are enabled. The set of facility locks supported by the modem is
determined at the time the modem is initialized, and the state of
each supported lock (enabled or disabled) is determined. When the
state of a lock changes, a property-change signal is sent out. Note
that ModemManager only supports enabling and disabling SIM-PIN, via
the EnablePin method on Modem.Gsm.Card.
---
...org.freedesktop.ModemManager.Modem.Gsm.Card.xml |6 +
.../org.freedesktop.ModemManager.Modem.Gsm.xml | 37 -
src/mm-generic-gsm.c | 213 ++--
src/mm-generic-gsm.h |3 +-
src/mm-modem-gsm-card.c| 10 +
src/mm-modem-gsm-card.h|3 +
src/mm-modem-helpers.c | 145 +
src/mm-modem-helpers.h |7 +
8 files changed, 356 insertions(+), 68 deletions(-)
diff --git a/introspection/org.freedesktop.ModemManager.Modem.Gsm.Card.xml b/introspection/org.freedesktop.ModemManager.Modem.Gsm.Card.xml
index 03c8a9f..9159052 100644
--- a/introspection/org.freedesktop.ModemManager.Modem.Gsm.Card.xml
+++ b/introspection/org.freedesktop.ModemManager.Modem.Gsm.Card.xml
@@ -144,5 +144,11 @@
+
+
+Facilities for which PIN locking is enabled.
+
+
+
diff --git a/introspection/org.freedesktop.ModemManager.Modem.Gsm.xml b/introspection/org.freedesktop.ModemManager.Modem.Gsm.xml
index 1abf915..354ce4a 100644
--- a/introspection/org.freedesktop.ModemManager.Modem.Gsm.xml
+++ b/introspection/org.freedesktop.ModemManager.Modem.Gsm.xml
@@ -4,7 +4,7 @@
-A bitfield describing the specifc access modes and technologies
+A bitfield describing the specific access modes and technologies
supported by a device and the access technology in-use when connected to
a mobile network.
@@ -168,6 +168,41 @@
+
+
+A bitfield describing which facilities have a lock enabled, i.e.,
+requires a pin or unlock code. The facilities include the
+personalizations (device locks) described in 3GPP spec TS 22.022,
+and the PIN and PIN2 locks, which are SIM locks.
+
+
+No facility
+
+
+SIM lock
+
+
+Fixed dialing (PIN2) SIM lock
+
+
+Device is locked to a specific SIM
+
+
+Device is locked to first SIM inserted
+
+
+Network personalization
+
+
+Network subset personalization
+
+
+Service provider personalization
+
+
+Corporate personalization
+
+
diff --git a/src/mm-generic-gsm.c b/src/mm-generic-gsm.c
index da0bf5c..8179737 100644
--- a/src/mm-generic-gsm.c
+++ b/src/mm-generic-gsm.c
@@ -138,6 +138,9 @@ typedef struct {
GHashTable *sms_parts;
guint sms_fetch_pending;
+
+/* Facility locks */
+MMModemGsmFacility enabled_facilities;
} MMGenericGsmPrivate;
static void get_registration_status (MMAtSerialPort *port, MMCallbackInfo *info);
@@ -809,6 +812,29 @@ initial_info_check (MMGenericGsm *self)
}
}
+static void clck_cb (MMAtSerialPort *port, GString *response, GError *error, gpointer user_data);
+
+static void
+initial_facility_lock_check (MMGenericGsm *self) {
+GError *error = NULL;
+MMGenericGsmPrivate *priv;
+
+g_return_if_fail (MM_IS_GENERIC_GSM (self));
+priv = MM_GENERIC_GSM_GET_PRIVATE (self);
+
+g_return_if_fail (priv->primary != NULL);
+
+if (mm_serial_port_open (MM_SERIAL_PORT (priv->primary), &error)) {
+mm_at_serial_port_queue_command (priv->primary, "+CLCK=?", 3, clck_cb, self);
+} else {
+g_warning ("%s: failed to open serial port: (%d) %s",
+ __func__,
+ error ? error->code : -1,
+ error && error->message ? error->message : "(unknown)");
+g_clear_error (&error);
+}
+}
+
static gboolean
owns_port (MMModem *modem, const char *subsys, const char *name)
{
@@ -882,6 +908,9 @@ mm_generic_gsm_grab_port (MMGenericGsm *self,
*/
initial_pin_check (self);
+/* Determine what facility locks are supported */
+initial_facility_lock_check (self);
+
} else if (ptype == MM_PORT_TYPE_SECONDARY)
priv->secondary = MM_AT_SERIAL_PORT (port);
} else if (MM_IS_QCDM_SERIAL_PORT (port)) {
@@ -1699,6 +1728,7
