Easy GPRS talking UDP with several hosts

9 thoughts on “Easy GPRS talking UDP with several hosts

  1. Hi all,

    We would like our 865 GPRS modules to act as listeners that allow mutiple hosts in the public internet to send UDP packets and get responses (for management, config, and other type services). We will have a static-ip server in between, and in effect, the clients will connect via this server which will have a table of the dynamic IP addresses for the 865 based modules. (The modules themselves log to the server and update the table).


    Using GPRS commands I can set and activate a PDP context (CGDCONT + CGACT) and listen for UDP(SLUDP). Firewall configured (FRWL). Fine, I can now recv an incoming UDP packet using SA + SI to see bytes + SS to see remote sender IP:Port. Now I can respond using SSENDUDP.Still ok. BUT. What happens if more than one host is talking at the same time. Now my SI shows the total bytes in the buffer and SS only shows ONE sender IP:Port. So I cannot use this model / command set to achieve my goal of allowing multiple simultaneous UDP based sessions. (The UDP itself of course is connectionless, by session here I mean higher level session).


    What is the recommended route to implement this kind of functionality? Thanks for your help.

    Ciarán Mac Aonghusa HKC.

  2. Hi Cosmin,

     Do you mean define two sockets that listen on two different port numbers?


    socket 1:  IP Addr : Port A

    socket 2:  IP Addr : Port B



    1. Something like this but will complicate your logic.

      On the same port: as soon as data arrives stop & restart listening.


  3. Indeed I heard that in a new version of SW Telit will allow the kind of listening I require. The SRING: will become


    SRING so that each time a host comes in with packet the easy gprs tcp/ip stack will tell the TE who the remote host is.


    Another Use-case I will require is the following. I need to be able to open up a UDP based exchange with a remote static ip address and port number (a server, with which I want to exchange some data over a proprietary protocol). Now, at the same time, I need to be able to listen for a UDP connection on my own IP address (as assigned when the context is activated) and a fixed port number. In this way, my application on my TE will be able to communicate with our server and, at the same time, allow a remote host to request information over UDP on the listening socket of the module.


    The problem I see here at the moment is that I don’t know how to talk to the server in a way that doesn’t involve a CONNECT where I am no longer in command mode and therefore cannot repond to SRING messages from the host which will talk to my IP:port. Any ideas?

      1. Thanks Cosmin. Yes, I see – command mode is the key to my application.


        One other question – though it is not directly related to my original question of multiple UDP sessions. 


        I know that the Class B device cannot handle Voice calls and data simultaneously. My understanding was that an open socket would be suspending for a voice call and then become live again when the call is finished. I had thought (and hoped!), however, that the socket would not be suspended until the call was answered. But my experiments suggest that the socket gets suspended when the module starts flagging the call with RING RING. So I have no way of sending a message out on my socket that tells my server (or whoever I’m talking to) that  “I’m going to be busy now for a while but I’ll be back soon”. Instead I see this:


        Voice call arrives..



        #SENDUDP ……  (I send a udp packet)





        and only now is the UDP packet that I submitted sent out to my server.


        Is there any way to send a packet (or packets) before answering the incoming call?

        Thanks again,


        1. Hi Ciaran,


          a data connection is suspended as soon as a voice call is received, that means a TCH (traffic channel) is assigned to the module. it is not important if the call is answered or not.

          You should drop the call, send the message that you’ll be busy and receive the new call.

          Of couse the remote side has to know that  a new call as to be originated a second time.