Strange TCP/IP connection behaviour

4 thoughts on “Strange TCP/IP connection behaviour

  1. Hi,

     

    We are in the process of field testing a device where an external microprocessor uses an 864PY module to create a TCP/IP connection to a remote server using AT#SKTSET and AT#SD commands in on-line mode.  The software in the device keeps trying to make the connection until it is successful.  The server software has been developed by ourselves and all TCP connection requests are logged in a file.  In 95 – 99% of cases the connection is successfully created, and data can be transferred.

     

    There are two devices on test which are at times unable to make the connection: by which I mean that the server receives no TCP connection request.  The devices are in the field in different locations, and we don’t have easy access for debugging.  Looking at the billing information for the SIM, we see moments where 9kb or 16kb of data has been transferred and billed even though the server has not received a connection request.  No useful data has been received.

     

    Please could  you suggest what this data transfer means, and whether there are AT commands that would help debug this scenario?

     

    Best Regards,

    Brian Butler

    1. Hi Brian,

       

          First of all, without having any means of debug we can only guess, which is not very productive but at least we can be prepared when will have access to the device.

         Some operators bill by default a minimal charge at GPRS opening, some force the minimum charge at GPRS closure, some round the volume at certain values; now for the actual traffic, the module can send DNS requests packets or even initial TCP packets (which may not reach the server) which are of course accounted and billed even no finalization is seen. 

  2. Hi Cosmin, 

     

    Thank you very much for the quick response.

     

    At present I have been using the AT+CGATT? command to check if the modem has GPRS attached.  This information is used to choose the location for the device.

     

    In future versions of the software I plan to use AT+CSQ to check for poor signal quality to choose the location for the device.  When we are able to update the software in the field, could you suggest some debug options to understand why a connection has been dropped.

     

    I see that there are some “easy gprs” related errors such as:

    407 — cannot setup socket 

    409 — timeout in opening socket

     

    Would these codes be reported if a TCP connection using AT#SD failed?  If not, are there other ways to identify why a connection has dropped?

    Best Regards,
    Brian
    1. To debug a no-connect situation one should check: SIM status, network and GPRS registration, signal quality (note CSQ values are valid only during calls, try #MONI), GPRS attach status, DNS queries, maybe a ping, TCP connection trial.

      In my opinion such particular result codes are hard to treat particulary, simply consider that stage (TCP) unusable and act accordingly.