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

[Aleksander Morgado]

Hey,

>
>> I've compared both logs and they really are mostly similar.
>
> Yes.  Thanks for confirming that.  It's so easy to miss something..
>
>> 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.
>
> I did some more experimenting and found that an "USB reset" somehow
> resolves this problem as well.  It will reset the USB bus connection,
> causing drivers to unbind and rebind and therefore a full new modem
> discovery by MM.  But it doesn't actually reset the modem, so the SIM
> state is unlocked.
>
> My working theory at the moment is that this is just another symptom of
> the firmware issue that makes the AT port go unresponsive. That problem
> is also "fixed" by an USB reset. There is certainly something fishy
> going on there, but it is not something we can fix on the host side of
> the equation.  So please ignore.
>

Did you talk to Sierra already about the reset needed for the AT port?

> FWIW, the issue could be either the now outdated firmware (which I
> believe is not distributed widely enough to be a real problem), or the
> missing USB3 bus connection.  But you haven't seen anything similar,
> have you?
>

I have not actually tested the patches with a full connection attempt;
I'm roaming without a proper data sim card to test with :/

>> 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
>
> Yes, that seems to happen consistently as well. Snooping a bit I see
> that we get an RA:
>
>   1 0.000000000 fe80::c568:4842:8f70:4662 -> ff02::1      ICMPv6 120 Router Advertisement from 02:50:f3:00:01:00
>   2 0.001230156 fe80::13a2:9f9:d6ae:fc0c -> ff02::2      ICMPv6 64 Router Solicitation
>   3 0.045356617      0.0.0.0 -> 255.255.255.255 DHCP 344 DHCP Discover - Transaction ID 0x81fd020
>   4 3.077396565      0.0.0.0 -> 255.255.255.255 DHCP 344 DHCP Discover - Transaction ID 0x81fd020
>   5 4.009308107 fe80::13a2:9f9:d6ae:fc0c -> ff02::2      ICMPv6 64 Router Solicitation
>   6 6.105465361      0.0.0.0 -> 255.255.255.255 DHCP 344 DHCP Discover - Transaction ID 0x81fd020
>   7 8.017334354 fe80::13a2:9f9:d6ae:fc0c -> ff02::2      ICMPv6 64 Router Solicitation
>   8 29.169514400      0.0.0.0 -> 255.255.255.255 DHCP 344 DHCP Discover - Transaction ID 0x3c001a32
>
>
> This is ignored for some reason though, as you can see from the RS
> packets following it.  I cannot explain why. It is delivered to the next
> layer since I was able to capture this as IP packets. Maybe it is just
> too early?
>
> But this is a bit strange, I must admit.  I don't see the same on a
> *working* connection.  There are no RAs before we start sending RS's on
> that one.
>
> Still, I'd like to just sweep this under the carpet for now, hoping that
> it goes away with "real" firmware.  Thanks a lot for looking at the
> logs, though.
>

I'll test with my MC7455 and a full connection next weekend, and let you know.

> And thanks for the nice work on the UIM SIM handling!
>

Thanks for testing it :) At least I know it works with more than 1 SIM.

-- 
Aleksander
https://aleksander.es