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

[Bjørn Mork]

Aleksander Morgado <aleksander at aleksander.es> writes:

> 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.

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?

> 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.

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



Bjørn