Re: nm_setting_gsm_get_pin() retuns null

[Dan Williams <dcbw redhat com>]

On Sat, 2011-10-01 at 02:41 +0200, Anders Feder wrote:
> Thanks. I've left you a question in the bug report. I may be
> interested in taking a stab at this if it isn't overwhelmingly
> difficult.

Responded.  It shouldn't be too difficult; there's already code there to
track the modem object from ModemManager and do the right thing.  So in
addition to the UnlockRequired property, you'd also want to grab and
watch the SimIdentifier and DeviceIdentifier properties, and use those
to look in the keyring for the right PIN.

Dan

> Anders Feder
> 
> On 30-09-2011 07:31, Dan Williams wrote: 
> > On Wed, 2011-09-21 at 08:34 +0200, Anders Feder wrote:
> > > Hi,
> > > 
> > > I'm trying to write a fix for this bug. I've been experimenting with
> > > testing whether a given connection is configured to autoconnect, using
> > > this code (inside applet-device-gsm.c):
> > >         NMSettingConnection *setting =
> > >         nm_connection_get_setting_connection (connection);
> > >         NMSettingGsm *setting_gsm = nm_connection_get_setting_gsm
> > >         (connection);
> > >         if ((autoconnects = autoconnects ||
> > >         (nm_setting_connection_get_autoconnect (setting) &&
> > >         nm_setting_gsm_get_pin (setting_gsm))))
> > >             break;
> > > However, nm_setting_gsm_get_pin (setting_gsm) seems to always return
> > > null, even when a PIN is set for the connection. Can someone pelase
> > > tell me why this might be? Under what circumstances may this function
> > > return null even when a PIN is set?
> > PIN codes in the connection data are deprecated because PINs are
> > specific to the SIM card, not to the connection.  If you lose your SIM
> > and get another from the same provider, the PIN will be different, and
> > the PIN in the connection data will be wrong.  I've written up some
> > notes on what I think should be done in the GNOME bug report for this
> > issue:
> > 
> > https://bugzilla.gnome.org/show_bug.cgi?id=618532
> > 
> > Happy to help if there are more questions.
> > 
> > Dan
> > 
> > 
> > 
> > 
>