U_CELL_NET: unable to disconnect. about ubxlib HOT 17 CLOSED

The problem was fixed with #57

from ubxlib.

Hi Alex! That AT log is very weird indeed.

The module has clearly responded to AT+CFUN=4 with OK, which should mean that it has detached and switched the radio off, yet, when the ubxlib code calls the registration status commands to check, the network layer in the module still thinks it is connected.

There's nothing much that ubxlib can do about this; let me try consulting our SARA-R412M-02B support people to see if they have seen anything like this.

from ubxlib.

Unfortunately they've not seen anything like this before: how repeatable is it?

from ubxlib.

It is practical for every connection.

from ubxlib.

Okay, in that case, when you have time, could you possibly modify the function disconnectNetwork() in u_cell_net.c so that, just before the comment line:

                    // Prod the modem to see if it is done

...you have the following:

                    uAtClientLock(atHandle);
                    uAtClientCommandStart(atHandle, "AT+CFUN?");
                    uAtClientCommandStopReadResponse(atHandle);
                    uAtClientUnlock(atHandle);

...i..e we want to query the AT+CFUN state of the module to confirm that it really is in AT+CFUN=4 like we've told it to be. I've attached a .zip file containing the intended modified u_cell_net.c if you prefer to just replace your existing file with that.

Then paste the AT log into a comment here.

from ubxlib.

U_CELL_MQTT: trying to disconnect...
AT+UMQTTC=0

+UMQTTC: 0,1

OK
Taking down network...
AT+COPS?

+COPS: 0,0,"262 01 1nce.net",9

OK
AT+CFUN=4

OK
AT+CFUN?

+CFUN: 4

OK
AT+CREG?

+CREG: 2,3

OK
0: Deny
AT+CFUN?

+CFUN: 4

OK
AT+CGREG?

+CGREG: 2,4

OK
0: OoC
AT+CFUN?

+CFUN: 4

OK
AT+CEREG?

+CEREG: 4,5,"DAD9","10","22A9B06",B,,,"00000000","01100000"

OK
0: RegR
AT+CFUN?

+CFUN: 4

OK
AT+CREG?

+CREG: 2,3

OK
0: Deny
AT+CFUN?

+CFUN: 4

OK
AT+CGREG?

+CGREG: 2,4

OK
0: OoC
AT+CFUN?

+CFUN: 4

OK
AT+CEREG?

+CEREG: 4,5,"DAD9","10","22A9B06",B,,,"00000000","01100000"

OK
0: RegR
AT+CFUN?

+CFUN: 4

OK
AT+CREG?

+CREG: 2,3

OK
0: Deny
AT+CFUN?

+CFUN: 4

OK
AT+CGREG?

+CGREG: 2,4

OK
0: OoC
AT+CFUN?

+CFUN: 4

OK
AT+CEREG?

+CEREG: 4,5,"DAD9","10","22A9B06",B,,,"00000000","01100000"

OK
0: RegR
AT+CFUN?

+CFUN: 4

OK
AT+CREG?

+CREG: 2,3

OK
0: Deny
AT+CFUN?

+CFUN: 4

OK
AT+CGREG?

+CGREG: 2,4

OK
0: OoC
AT+CFUN?

+CFUN: 4

OK
AT+CEREG?

+CEREG: 4,5,"DAD9","10","22A9B06",B,,,"00000000","01100000"

OK
0: RegR
AT+CFUN?

+CFUN: 4

OK
AT+CREG?

+CREG: 2,3

OK
0: Deny
AT+CFUN?

+CFUN: 4

OK
AT+CGREG?

+CGREG: 2,4

OK
0: OoC
AT+CFUN?

+CFUN: 4

OK
AT+CEREG?

+CEREG: 4,5,"DAD9","10","22A9B06",B,,,"00000000","01100000"

OK
0: RegR
AT+CFUN?

+CFUN: 4

OK
AT+CREG?

+CREG: 2,3

OK
0: Deny
AT+CFUN?

+CFUN: 4

OK
AT+CGREG?

+CGREG: 2,4

OK
0: OoC
AT+CFUN?

+CFUN: 4

OK
AT+CEREG?

+CEREG: 4,5,"DAD9","10","22A9B06",B,,,"00000000","01100000"

OK
0: RegR
AT+CFUN?

+CFUN: 4

OK
AT+CREG?

+CREG: 2,3

OK
0: Deny
AT+CFUN?

+CFUN: 4

OK
AT+CGREG?

+CGREG: 2,4

OK
0: OoC
AT+CFUN?

+CFUN: 4

OK
AT+CEREG?

+CEREG: 4,5,"DAD9","10","22A9B06",B,,,"00000000","01100000"

OK
0: RegR
AT+CFUN?

+CFUN: 4

OK
AT+CREG?

+CREG: 2,3

OK
0: Deny
AT+CFUN?

+CFUN: 4

OK
AT+CGREG?

+CGREG: 2,4

OK
0: OoC
AT+CFUN?

+CFUN: 4

OK
AT+CEREG?

+CEREG: 4,5,"DAD9","10","22A9B06",B,,,"00000000","01100000"

OK
0: RegR
AT+CFUN?

+CFUN: 4

OK
AT+CREG?

+CREG: 2,3

OK
0: Deny
AT+CFUN?

+CFUN: 4

OK
AT+CGREG?

+CGREG: 2,4

OK
0: OoC
AT+CFUN?

+CFUN: 4

OK
AT+CEREG?

+CEREG: 4,5,"DAD9","10","22A9B06",B,,,"00000000","01100000"

OK
0: RegR
AT+CFUN?

+CFUN: 4

OK
AT+CREG?

+CREG: 2,3

OK
0: Deny
AT+CFUN?

+CFUN: 4

OK
AT+CGREG?

+CGREG: 2,4

OK
0: OoC
AT+CFUN?

+CFUN: 4

OK
AT+CEREG?

+CEREG: 4,5,"DAD9","10","22A9B06",B,,,"00000000","01100000"

OK
0: RegR
U_CELL_NET: unable to disconnect.

from ubxlib.

Thanks for doing that so quickly. Putting it simply, it should not be possible for the module to do this. Would you be able to capture the full AT log, from startup, and attach it to a comment as a .txt file here? Then we can see if we can reproduce it.

from ubxlib.

Hi Rob,

attached the txt file
i just deleted the ip address and user with password in the log

unable to dissconnect.txt

from ubxlib.

Excellent, thanks, we'll take a look.

from ubxlib.

While we're doing that, the guys have requested a little more information. When you get the chance, could you possibly try using the attached u_cell_net.c and pasting the AT log output into here? This version queries a few more things while waiting for the registration status.

If one of those returns a better indication then we could potentially use that additional information to determine that the disconnect has occurred, rather than relying solely on +CEREG.

from ubxlib.

here is the log with the integrated u_cell_net.c from the zip file.

Is it ok because I somehow don't see any difference?

unable to dissconnect with new u_cell_net file.txt

from ubxlib.

Hmm, strange, maybe uploading a .zip file here with the same name twice didn't work?

Here's u_cell_net.c again, zipped with a different zip-file name this time.

from ubxlib.

now the new log

unable to dissconnect with new u_cell_net file.txt

from ubxlib.

Excellent!!!! That shows that when we are getting "connected" responses from +CEREG, the other indications:

AT+CGATT?
+CGATT: 0
OK
AT+CGACT?
+CGACT: 1,0
OK
AT+CGDCONT?
+CGDCONT: 1,"IP","iot.1nce.net","0.0.0.0",0,0,0,0
OK

...all show that there is no connection. What I am going to do is to modify the "disconnect" code to also check AT+CGATT? and, if that says we're disconnected, it will override and accept that we are disconnected. I will try to do this today and let you know when it's available.

from ubxlib.

I have pushed a test branch here with the changes to the disconnect code. I have verified that the changes cause no problems but we have not been able to reproduce your issue here so, when you get a chance, could you try it out please? You can either pull the branch or you can just replace the contents of your current u_cell_net.c with the one from the branch.

Let us know what happens and, if at all possible, paste an AT log of the outcome into a comment here.

from ubxlib.

Great, thanks for raising it and begin so patient/helpful in resolving it.

from ubxlib.

The fix has now been pushed to the master branch here and the temporary test branch has been deleted.

from ubxlib.