GL865-QUAD Socket issue

6 thoughts on “GL865-QUAD Socket issue

  1. Hello,


    Occasionally we’re running in to an issue where a socket connection state at our server is FIN_WAIT2 (waiting for client to finish) while our module thinks the socket is still active and keeps trying to send data to it. AT#SS reports an open socket and MDM2.getDCD() returns 1 (all our socket activity is in MDM2). We never formally close the socket in our module’s code, but we detect if the socket has been closed and reopen it with AT#SD.


    Rebooting the module works as well as dropping network with AT+CFUN, but I would like to avoid any recovery methods because we would like to stream data to the server as fast as possible.


    Is this a known issue, is there a quick fix or a best practice on how to avoid the situation?


    Module GL865-QUAD, Firmware version 10.00.146.


    Best Regards,

    Mikko Valkonen 


    1. Hi Mikko,


      does it mean you receive just the ACK, not FIN ACK from the module?

      What is the socket configuration #SCFG?


      Is not closed even after socket inactivity timeout?


      I assume a quicker way to close and reopen the socket is with  AT#SH command, intead of AT+CFUN or AT#REBOOT

    2. Hi Mikko,


      does it mean that the module sends the ACK but not the ACK FIN packet to close the socket after the server has sent the FIN? 

      What is the configuration used for AT#SD and AT#SCFG ?


      I assume it would be better to close the socket with AT#SH instead of robooting the module or use AT+CFUN=4 to disconnect it from the network.

      1. Hello Andrea,


        I have not analyzed the TCP frames which are sent, I’m only relying on the information I get from the server. The state FIN_WAIT2 however indicates that it has not received the ACK_FIN from module.


        We open with AT#SD=1,0,2222,"",255


        Socket is configured with AT#SCFG=1,1,300,0,90,50

        and  AT#SCFGEXT=1,0,0,5,0


        Socket inactivity timeout does not have any effect. The module thinks the socket is still OK, so we keep sending data to the socket thus losing the data. This apparently clears the inactivity timer.


        Also, it’s not possible to use AT#SH in this case. The socket was opened with MDM2.send(), and sending the close-command to MDM2 will lead to losing it (as above). Sending the close-command with MDM.send() will lead to an ERROR. The only way I’ve managed to recover from this programmatically is to kill the network with AT+CFUN or reboot the module.  

        1. Hi Mikko,


          with the following configuration, <closuretype> = 255 and  <maxTo> = 0 the socket is not closed receiving a [FIN] packet or for inactivity timeout.

          It is only closed locally with +++ or when remote socket is aborted and [RST] is sent.

          So above issue is the normal behavior of the socket, from what I can understan.

          Try setting <closuretype> = 0

          1. Hi,


            Thanks for the answer, we will try to use the settings you provided.


            However, ideally we would not like to close the socket in the module side at all. It should only close, if the server kills the connection. This usually works ok, but sometimes when the socket remains in the FIN_WAIT2 state, the server software which handles socket connections is already killed. The module simply does not recognize this. I must double check that the RST is sent correctly.