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 _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
