[PATCH 0/3] PIN operations with UIM service for the MC7455

[Aleksander Morgado]

Hey hey,

>>
>> This next series of patches includes support for the PIN/PUK operations that were missing in the MC7455 (all except for checking status).
>>
>> libqmi bumped to 1.13.7 (git master), as that contains the required new messages.
>>
>> Comments/tests welcome.
>
> Great! Thanks. Tested on the MC7455 and it works for me - sort of.
>

Thanks for testing! :)

> That is: It works perfectly wrt everything we can expect ModemManager to
> do.  But by using it I am able to trigger some unexpected behaviour from
> the driver and/or firmware.  This may be caused by the early non-GA
> firmware I'm still using (01.09.06.00), so it is likely irrelevant. But
> it is good to have this documented in case someone else encounter the
> same problem.
>
> If I enable and connect in one go, by using --simple-connect with a pin,
> then I am unable to transmit any IP packets over the interface.  MM
> connects just fine, and the bearer gets all the expected IP addresses
> etc. But DHCP just times out.  And so does any other IP packets when I
> configure the addresses manually.  Even weirder is that this problem
> seems to be persistent and affect *both* QMI interfaces.  Disconnecting
> and reconnecting does not fix the problem.  Neither does connecting the
> other QMI interface using another APN.  The modem appers dead until
> reset.  But QMI commands work fine.
>
> If I manually enter the pin with 'mmcli -i 0 --pin=...' and then enable
> the modem with 'mmcli -m 0 -e', then everything works just fine. Doing a
> simple-connect appears to behave exacly like the first case, but DHCP
> etc works as expected.
>
> I have repeated these tests a few times, resetting the modem between in
> every way I can imagine, and it seems to behave consistently like
> described above:  Enabling and connecting in one go makes the modem fail
> to transmit any IP packets.
>
> The fact that MM connects fine and the bearer looks all good, really
> makes this a firmware and driver issue.  But I am unable to figure out
> how to handle it.  Or even debug it.  So any help is appreciated...
>
> I'm attaching MM debug logs from a working and a failing session. There
> are no major difference AFAICS.  They both look fine to me.
>

I've compared both logs and they really are mostly similar.

The only notable difference between the two is an extra "NAS Get
Serving System" happening in the middle between the WDS client CID
allocation request and response during the connection attempt:

--> CTL Allocate CID(WDS) request
--> NAS Get Serving System request
<-- NAS Get Serving System response
<-- CTL Allocate CID(WDS) response

I have no idea if that could trigger a bug in the firmware somehow.

Note also that in the failing case, the WDS stats do say that you
received some bytes:
>>>>>> TLV:
>>>>>>   type       = "Rx Bytes Ok" (0x1a)
>>>>>>   length     = 8
>>>>>>   value      = 58:00:00:00:00:00:00:00
>>>>>>   translated = 88
>>>>>> TLV:
>>>>>>   type       = "Tx Bytes Ok" (0x19)
>>>>>>   length     = 8
>>>>>>   value      = 00:00:00:00:00:00:00:00
>>>>>>   translated = 0

-- 
Aleksander
https://aleksander.es