On 08/28/2012 07:09 AM, Ben Chan wrote:
>> For (1), the 'Modem' interface has a generic 'modem_after_sim_unlock'
>> step which allows plugin implementations to provide a method to (try to)
>> ensure that the SIM access is valid. Some plugins may just provide a N
>> second timeout to be run in that
> On 08/27/2012 12:19 PM, Mathieu Trudel-Lapierre wrote:
> > On Sat, Aug 25, 2012 at 5:05 PM, Gene Czarcinski
> > wrote:
> > [...]
> >> 1. Is it already in use? I am running "current" Fedora 17 and a
> >> "ps ax"
> >> shows no "extra" dnsmasq ... just all the ones for my virtual
> >> networks.
>
> Do you mean that you still need the timeout even if the PIN request is
> not enabled?
>
> If the code tries to load Sim properties before unlocking the PIN and
> those fail, they will anyway get retried after the successful PIN unlock.
Yes, the issue happens on a SIM without PIN locked. One scen
>> Do you mean that you still need the timeout even if the PIN request is
>> not enabled?
>>
>> If the code tries to load Sim properties before unlocking the PIN and
>> those fail, they will anyway get retried after the successful PIN unlock.
>
> Yes, the issue happens on a SIM without PIN locked
Hey Ben,
>>> Do you mean that you still need the timeout even if the PIN request is
>>> not enabled?
>>>
>>> If the code tries to load Sim properties before unlocking the PIN and
>>> those fail, they will anyway get retried after the successful PIN unlock.
>>
>> Yes, the issue happens on a SIM wit
412c412
< if (driver && !strcmp (driver, "bluetooth")) {
---
> if (driver && strcmp (driver, "bluetooth")) {
That`s it.
As far as I can see, that IF-statement should evaluate TRUE only when
the driver is something other than Bluetooth.
This fix shall solve
https://bugs.launchpad.net/u
> Attached is a patch which makes the after-sim-unlock step get run also
> when PIN request is disabled. Could you give it a try with your use case
> and a proper implementation of the modem_after_sim_unlock() callback? I
> would actually try the ZTE way (running +CPMS? retries), as IIRC you
> were
