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

2016-02-02 Thread Bjørn Mork 
Dan Williams  writes:

> They always ask for it, in my experience it is never IMEI locked, and
> I've never heard of the "large 4" carriers IMEI locking either.  They
> just want it to "know" if your phone is compatible with the network and
> make sure it's not a stolen phone or stuff like that.

Odd.  Wouldn't they figure that out once you put their SIM into the
phone anyway?  Seems much easier to let the network log such stuff than
doing some manual pre-registration of the IMEI.


Bjørn
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

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

2016-02-02 Thread Aleksander Morgado 
On Mon, Feb 1, 2016 at 9:19 AM, Bjørn Mork  wrote:
>>> 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 :/
>
> Ouch.  Yes, I can see the need to be careful then.  You definitely don't
> want to do any speed testing while roaming.  I see from
> https://en.wikipedia.org/wiki/European_Union_roaming_regulations
> that the current maximum per MB is 0.20 euros.  So that would be 7.50
> euros per second if you max out the MC7455 :)

I'm actually in the US this week; I didn't even bother checking what
the roaming rates here would be. I do have a US t-mobile SIM card, but
looks like it's locked to a single IMEI? Not sure.


-- 
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

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

2016-02-02 Thread Dan Williams 
On Tue, 2016-02-02 at 08:33 -0800, Aleksander Morgado wrote:
> On Mon, Feb 1, 2016 at 9:19 AM, Bjørn Mork  wrote:
> > > > 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 :/
> > 
> > Ouch.  Yes, I can see the need to be careful then.  You definitely
> > don't
> > want to do any speed testing while roaming.  I see from
> > https://en.wikipedia.org/wiki/European_Union_roaming_regulations
> > that the current maximum per MB is 0.20 euros.  So that would be
> > 7.50
> > euros per second if you max out the MC7455 :)
> 
> I'm actually in the US this week; I didn't even bother checking what
> the roaming rates here would be. I do have a US t-mobile SIM card,
> but
> looks like it's locked to a single IMEI? Not sure.

I don't think they do that; none of the TMO US SIMs I've ever had (like
5?) have ever been locked to an IMEI.

Dan
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

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

2016-02-01 Thread Bjørn Mork 
Aleksander Morgado  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.0 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
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

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

2016-02-01 Thread Bjørn Mork 
Aleksander Morgado  writes:

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

Not really.  I did mention it, but I think it might have been hidden in
too much other nonsense I wrote at the same time :)

I'm really hoping for a publicly avaialble firmware soon.


>> 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 :/

Ouch.  Yes, I can see the need to be careful then.  You definitely don't
want to do any speed testing while roaming.  I see from
https://en.wikipedia.org/wiki/European_Union_roaming_regulations
that the current maximum per MB is 0.20 euros.  So that would be 7.50
euros per second if you max out the MC7455 :)


Bjørn
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

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

2016-02-01 Thread 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.0 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
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

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

2016-01-31 Thread 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
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel