Re: [PATCH 0/3] PIN operations with UIM service for the MC7455
> > 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. > > Cheers! > > Aleksander Morgado (3): > broadband-modem-qmi: implement unlock retries loading with UIM service > sim-qmi: implement SIM verify/unblock/change/enable with UIM service > qmi: just one InvalidCommand error is enough to avoid all DMS UIM > commands > > configure.ac | 2 +- > src/mm-broadband-modem-qmi.c | 369 ++-- > src/mm-sim-qmi.c | 573 > ++- > src/mm-sim-qmi.h | 17 +- > 4 files changed, 767 insertions(+), 194 deletions(-) > I've merged all these to git master. Still haven't tried to reproduce Bjørn's issue with my MC7455, though, but it's in my TODO list :) -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: [PATCH 0/3] PIN operations with UIM service for the MC7455
On Sat, 2016-01-30 at 20:14 -0800, Aleksander Morgado wrote: > 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. Old and new ways work fine on my MC7700 and EM7355. I don't have a 7455 though, so I'm not able to test a device that rejects DMS UIM. Behavior is the same on an uninitialized SIM too; the modem moves to 'failed' state because unlock tries cannot be read. LGTM. Dan > Cheers! > > Aleksander Morgado (3): > broadband-modem-qmi: implement unlock retries loading with UIM > service > sim-qmi: implement SIM verify/unblock/change/enable with UIM > service > qmi: just one InvalidCommand error is enough to avoid all DMS UIM > commands > > configure.ac | 2 +- > src/mm-broadband-modem-qmi.c | 369 ++-- > src/mm-sim-qmi.c | 573 > ++- > src/mm-sim-qmi.h | 17 +- > 4 files changed, 767 insertions(+), 194 deletions(-) > > -- > 2.7.0 > ___ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel ___ 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
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
On Tue, 2016-02-02 at 09:41 -0800, Aleksander Morgado wrote: > On Tue, Feb 2, 2016 at 9:28 AM, Dan Williams wrote: > > > 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. > > They did get my IMEI during the validation process, that's why I > assumed that. I should retry... 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. 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
On Tue, Feb 2, 2016 at 9:28 AM, Dan Williams wrote: >> 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. They did get my IMEI during the validation process, that's why I assumed that. I should retry... -- 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
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
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
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
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
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
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
