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