UDP Client Socket message sent with wrong Port No

Module: FXT009 (Q2687RDG)
-“Developer Studio”,“2.1.0.201108080830-R7547”
-“Open AT Embedded Software Suite package”,“2.33.0.201009161739”
-“Open AT OS Package”,“6.32.0.03”
-“Firmware Package”,“7.43.0.201009151513”
-“WIP Open AT Plug-in Package”,“5.30.0.2040”

I started with the sample “UDP_Client” code and verified that the server was receiving the message sent from the Wavecom.

I then modified that code to receive a response using the same socket. I presumed I could just set the “WIP_COPT_PORT” option and expect a “WIP_CEV_READ” event to occur when the response was sent from the server.

The problem is that I don’t receive a WIP_CEV_READ event at all, at least not on the port I’m expecting it on.

The remote server is set to respond on the port set on the originating Client (i.e. the Client’s local port). When creating the socket on the Wavecom I set the local port number to 11000 using the “WIP_COPT_PORT” option however apparently the server sees the message as coming from port 1025, not 11000 as expected. On that basis it responds to the Wavecom using port 1025, hence the reason I never receive a WIP_CEV_READ event.

I haven’t changed any other WIP options so defaults are used for all but the local port, destination IP address and destination port number. There appears to be some kind of port translation happening ?

I must have some fundamental error here in both my understanding and code so would appreciate some help in resolving it.

Code for the modified “entry_point.c” module of the sample is included below:

//***************************************************************************
// entry_point.c  (modified) -  Copyright Wavecom S.A. (c) 2006
//***************************************************************************

/****************************************************************************
 * File    :   entry_point.c
 *
 */


//These constants have been set for the System
#define PEER_PORT         12500                     // Remote server port
#define PEER_STRADDR      "testserver.dfs.fred.com" // Remote server name
#define LOCAL_PORT         1000                     // Local listening port
#define MESSAGE           "\x00\x09\x01\x00\x00\x20\x00\x02\x0D\xFF\x8B\x77"

#define RCV_BUFFER_SIZE   512

#define INTERVAL          30
#define WAIT_TIME	      5                      // Wait time before transmit (secs)

#include "adl_global.h"
#include "wip.h"

//**************************************************************************
//  Globals
/***************************************************************************
static wip_channel_t socket = NULL;


/***************************************************************************
//  Function prototypes
/***************************************************************************
static void evh( wip_event_t *ev, void *ctx);
static void evh_timer( u8 tmr_id);	                 // For Tx interval


//**************************************************************************
//  Function   : appli_entry_point
//--------------------------------------------------------------------------------------------
//  Object     : Called once the WIP IP stack is fully initialized.
//**************************************************************************
void appli_entry_point()
{
  // Create the socket and set for read mode.
	socket = wip_UDPCreateOpts( evh, NULL,
                               WIP_COPT_PORT, LOCAL_PORT,
                               WIP_COPT_END );
}


//**************************************************************************
//  Function   :  evh_timer
//--------------------------------------------------------------------------------------------
//  Purpose    : Sends a packet, upon reception of this timer
//                    event subscribed by [evh].
//--------------------------------------------------------------------------------------------
//  Variable Name     |IN |OUT|GLB|  Utilisation
//--------------------+---+---+---+-------------------------------------------------------
// tmr_id             |   |   |   | unused
//--------------------+---+---+---+--------------------------------------------------------
//**************************************************************************
static void evh_timer( u8 tmr_id)
{
	int	nwrite;

	TRACE(( 1, "[evh_timer] Write MESSAGE\n" ));
	nwrite = wip_writeOpts( socket, MESSAGE, sizeof(MESSAGE),
					            WIP_COPT_PEER_ADDR, PEER_STRADDR,
					            WIP_COPT_PEER_PORT, PEER_PORT,
					            WIP_COPT_END );
}


/**************************************************************************
//  Function   : evh
//-------------------------------------------------------------------------------------------
//  Purpose    : Handles events happening on the UDP socket.
//	              When a packet is received, its sender address
//  		      and port are gathered, together with its content
//-------------------------------------------------------------------------------------------
//  Variable Name     |IN |OUT|GLB|  Utilisation
//--------------------+---+---+---+------------------------------------------------------
//  ev                | X |   |   |  WIP event
//--------------------+---+---+---+------------------------------------------------------
//  ctx               |   |   |   |  unused
//--------------------+---+---+---+------------------------------------------------------
//*************************************************************************
static void evh( wip_event_t *ev, void *ctx )
{
  switch( ev->kind )
  {
    case WIP_CEV_OPEN:
    {
      static int tmr_handler;

      wip_debug ( "[evh] UDP socket ready and waiting (WIP_CEV_OPEN event).\n\n" );

      // Start a 2-second timer and send the message in its event handler.
      wip_debug( "[evh_udp_tx] (WIP_CEV_OPEN event), starting the timer\n\n");
      tmr_handler = adl_tmrSubscribe( TRUE, 10*WAIT_TIME,
                                      ADL_TMR_TYPE_100MS, evh_timer);
      break;
    }

    case WIP_CEV_READ:
    {
      // a [WIP_CEV_READ] event is received every time an UDP datagram is
      // received by the UDP socket.
      wip_debug ( "[evh] A datagram arrived (WIP_CEV_READ event).\n\n" );
    }

    case WIP_CEV_DONE:
    {
      wip_debug ( "[evh] WIP_CEV_DONE event on UDP socket event handler.\n\n" );
      break;
    }

    case WIP_CEV_WRITE:
    {
      wip_debug ( "[evh] WIP_CEV_WRITE event on UDP socket event handler.\n\n ");
      break;
    }

    case WIP_CEV_ERROR:
    {
      wip_debug( "[evh] Error %i on socket. Closing.\n\n",
                               ev->content.error.errnum );
      wip_close( ev->channel );
      break;
    }

    default:
    {
      wip_debug( "[evh] Some other event received\n\n");
      break;
    }
  }
}

May I raise some points for networking/protocol point of view…

  1. Are you getting internet IP or intranet IP from ISP? in later case data may passed through NAT from ISP in which the source port number may vary.
    You may check the actual IP address via AT+CGPADDR

  2. When using UDP, you better start a dedicated UDP server socket for incoming data.

  3. reminded, UDP is unreliable service…

(we can easily overcome all these limitation with TCP socket :smiley: if you dont have concern on overhead, etc…)

Thank you for the response. :slight_smile:

Private IP connection via network provider (Vodafone).

Have checked IP as 192.168.32.xx using this code:

case WIP_BEV_IP_CONNECTED :
            wip_bearerGetOpts(GPRS_Bearer_ID, WIP_BOPT_IP_ADDR, &LocalIP);
            wip_inet_ntoa(LocalIP,LocalIPAddStr,sizeof(LocalIPAddStr));
            sprintf(&MessageString[0],"WIP_BASIC -> Local IP Address : %s",LocalIPAddy);
   	    SendDebugString(&MessageString[0]);

The Client has several hundred custom embedded devices already in the field that transmit and receive responses correctly using same setup as I am using with the Sierra Wireless modem (same destination server address and port, same local port number and same APN and SIM programming). Their protocol incorporates error checking, message sequence number checking etc. They have specifically asked me to use UDP,

I did originally try this without success. However, my code might have been incorrect so I will start from the beginning again in re-implementing dual sockets.

OK,

I’ve now confirmed that there’s either an undocumented option for UDP sockets or there’s an “unintended software feature” (i.e. a sofware defect or bug). I’ve implemented exactly the same functionality in two completely different ways, one using ADL and the other using WIPSOFT AT commands, and the result is identical - no indication that any packets are being received.

Also, I’ve monitored at the remote sever end and have observed the server responding to the correct IP address and port number for the modem’s UDP Client socket. I also see the firewall passing the response packet through to the Vodafone APN for GPRS transmission to the modem. Here’s the monitoring log from a TELNET session on the server (Note that the assigned IP address and port for the modem’s UDP Client socket was 192.168.32.55:11000 in this test):

INFO 2012-02-08 11:14:05,766 503418642ms SendReceiveLogger StartListener - Received: 00-09-01-00-00-20-00-02-0D-FF-8B-77

INFO 2012-02-08 11:14:07,094 503419970ms SendReceiveLogger SendToDevice - Sending: 00-09-01-00-00-20-00-00-E8-AA To 192.168.32.55:11000

INFO 2012-02-08 11:14:13,344 503426220ms SendReceiveLogger StartListener - Received: 00-09-01-00-00-20-00-02-0D-FF-8B-77

INFO 2012-02-08 11:14:14,547 503427423ms SendReceiveLogger SendToDevice - Sending: 00-09-01-00-00-20-00-00-E8-AA To 192.168.32.55:11000

I can implement send receive clients in both Delphi( using INDY) and .NET with a single socket and I know that the TELIT modem can operate a single UDP Client socket in send and receive mode so why doesn’t the OpenAT UDP socket work??

I’ve now lost over three weeks on investigating this by trying various “suggestions” and permutations and combinations and I cannot recover my costs from the customer. The unfortunate reality is that If I can’t process responses from the remote server then clearly any product development using Sierra Wireless modem for the heart of this project is dead! Not only that, the schedule is now so far behind that I don’t know how I’ll ever recover it. I’d therefore appreciate Sierra Wireless engineers making a concerted effort to resolve this issue urgently please!!!

I have included both the IP module code and the WIPSOFT AT Commands log below for reference.

/****************************************************************************
 * File    :   entry_point.c
 *
 * UDP Client Socket Test
 *
 * A SINGLE UDP SOCKET IS USED.  SOURCE PORT SET BY THE APPLICATION = 11000.
 *
 * Send a data packet to the Test Server on the private APN every [INTERVAL] seconds;
 * the packet contains the string [MESSAGE1].
*/


// UDP Socket parameters for the customer's remote Test server
#define SERVER_DATA_ADDR    "toutest.pda.dfs.dcnz.com"
#define SERVER_DATA_PORT    12500

// UDP Socket parameters for local Machine (Fastrack Xtend Modem)
#define LOCAL_DATA_PORT   	11000

// Test data to be sent in the UDP packet to the server
#define MESSAGE1 "\x00\x09\x01\x00\x00\x20\x00\x02\x0D\xFF\x8B\x77"

// Interval between sending packets to the server (in seconds)
#define REPORT_INTERVAL      10

// Maximum allowable size for the received packet data
#define RX_BUFFER_SIZE       256


/***************************************************************************/
/*  Globals                                                                */
/***************************************************************************/
static wip_channel_t tx_socket = NULL; // Transmit socket (channel)

/***************************************************************************/
/*  Function prototypes                                                    */
/***************************************************************************/
static void evh_udp_tx(wip_event_t *ev, void *ctx);
static void evh_report_timer(u8 tmr_id);

/***************************************************************************/
/*  Function   : appli_entry_point                                         */
/*-------------------------------------------------------------------------*/
/*  Object     : Called once the WIP IP stack is fully initialised.        */
/*               This is the starting point of the user application.       */
/*-------------------------------------------------------------------------*/
/***************************************************************************/
void appli_entry_point()
{
	// Create a UDP transmit socket, pseudo-connected to [PEER_STRADDR]:[PEER_PORT].
	// The source port is set by the application to the DataCol default.
	wip_debug("[appli_entry_point] Creating UDP transmit socket\n");
	tx_socket = wip_UDPCreateOpts( evh_udp_tx,
								   NULL,
								   WIP_COPT_PEER_STRADDR, SERVER_DATA_ADDR,
								   WIP_COPT_PEER_PORT, SERVER_DATA_PORT,
								   WIP_COPT_PORT, LOCAL_DATA_PORT,
								   WIP_COPT_END);
}

/***************************************************************************/
/*  Function   : evh_udp_tx                                                */
/*-------------------------------------------------------------------------*/
/*  Object     : When the UDP socket is initialised (reception of          */
/*   [WIP_COPT_OPEN]), a cyclic timer event is created, to send the        */
/*   Datagram regularly. The timer event triggers the handler [evh_timer]. */
/*-------------------------------------------------------------------------*/
/*  Variable Name     |IN |OUT|GLB|  Utilisation                           */
/*--------------------+---+---+---+----------------------------------------*/
/*  ev                | X |   |   |  WIP socket event                      */
/*--------------------+---+---+---+----------------------------------------*/
/*  ctx               |   |   |   |  unused                                */
/*--------------------+---+---+---+----------------------------------------*/
/***************************************************************************/
static void evh_udp_tx( wip_event_t *ev, void *ctx )
{
	static int tmr_handler;

	switch (ev->kind)
	{

		/* A [WIP_CEV_READ] event should be generated every time a Datagram is
		 * received by the UDP socket. */
		case WIP_CEV_READ:
		{
			TRACE(( 2, "[evh_udp_tx] A Datagram arrived\n" ));
			break;
		}

		case WIP_CEV_WRITE:
		{
			TRACE(( 2, "[evh_udp_tx] WIP_CEV_WRITE event triggered on socket." ));
			break;
		}

		case WIP_CEV_ERROR:
		{
			wip_debug( "[evh_udp_tx] Error %i on socket.\n",
					   ev->content.error.errnum );
			if ( wip_getState(ev->channel ) != WIP_CSTATE_READY)
			{
				wip_debug("[evh_udp_tx] Error is fatal, closing\n");
				adl_tmrUnSubscribe(tmr_handler, evh_report_timer,
						ADL_TMR_TYPE_100MS);
				wip_close( ev->channel);
			}
			break;
		}

		case WIP_CEV_OPEN:
		{
			TRACE(( 2, "[evh_udp_tx] UDP transmit socket opened, starting the reporting timer" ));
			tmr_handler = adl_tmrSubscribe(TRUE, 10 * REPORT_INTERVAL,
					ADL_TMR_TYPE_100MS, evh_report_timer);
			DUMP( 3, MESSAGE1, sizeof(MESSAGE1)-1);
			TRACE(( 2, "[evh_udp_tx] TThe content of the DATA section of the UDP packet is:" ));

			break;
		}

	}
}


/****************************************************************************/
/*  Function   :  evh_report_timer                                          */
/*--------------------------------------------------------------------------*/
/*  Object : Regularly sends a report packet, upon reception of a timer		*/
/* 			 event subscribed by [evh_udp].                                 */
/*--------------------------------------------------------------------------*/
/*  Variable Name     |IN |OUT|GLB|  Utilisation                            */
/*--------------------+---+---+---+-----------------------------------------*/
/* tmr_id             |   |   |   | unused                                  */
/*--------------------+---+---+---+-----------------------------------------*/
/****************************************************************************/
static void evh_report_timer( u8 tmr_id )
{
	wip_debug( "[evh_report_timer] Sending packet to server.\n" );
	wip_write( tx_socket, MESSAGE1, sizeof(MESSAGE1) - 1 );

	TRACE(( 3, "[evh_report_timer] %d bytes sent to server.", sizeof(MESSAGE1)-1 ));
}

Here’s the WIPSOFT AT version log - NOTE the complete lack of any response on the temrinal in data mode (the equivalent packet data is sent as a binary file using the terminal.

AT                                                                              
OK                                                                              
AT+WOPEN?                                                                       
+WOPEN: 1                                                                       
                                                                                
OK                                                                              
AT+WIPCFG=1                                                                     
OK                                                                              
AT+WIPBR=1,6                                                                    
OK                                                                              
AT+WIPBR=2,6,11,"pda.dcnz.com"                                             
OK                                                                              
AT+WIPBR=4,6,0                                                                  
ERROR                                                                           
AT+WIPBR=4,6,0                                                                  
ERROR                                                                           
AT+WIPBR=4,6,0                                                                  
ERROR                                                                           
AT+WIPBR=4,6,0                                                                  
OK                                                                              
AT+WIPBR=3,6,15                                                                 
+WIPBR: 6,15,"192.168.32.120"                                                   
                                                                                
OK                                                                              
AT+WIPCREATE=1,1,11000,"toutest.pda.dfs.dcnz.com",12500                    
OK                                                                              
                                                                                
+WIPREADY: 1,1                                                                  
AT+WIPDATA=1,1,2                                                                
CONNECT                                                                         
                                                                                
OK

Hi,

With refer to your WIPSoft log, I tried to replicate using Q2687 with WIPSoft v542 connecting to an UDP echo server on public domain:

Case 1: (public IP from carrier)

Case #2 (internal IP)

Not sure if that helps…

From your telnet monitoring, server is actually sending to correct IP and port, 192.168.32.55:11000…
It is really weird if modem cannot receive it…

Thank you for the response and for your test efforts.

I used WIPSoft 5.30 for the AT command testing as requested by the agent so will try again with WIPSoft 5.42.

Can you please send me a PM with the access details for the UDP echo servers you used in your test? I can then try additional tests from here to try to isolate the source of the problem.

I have re-run the tests with WIPSoft 5.42 but have not seen any improvement. Still no receive traffic reported.

If you supply details of the UDP echo server on the public domain I will try that.

What else can we do to isolate the source of his problem?

Hi all,

The issue here seems to be setting up the listening “socket”.

Using AT+WIPCREATE=1,1,10000,“IP Addess”,5000 provides the details of the sendign port as 10000, but does not setup a listening port. To setup the listening port, the command AT+WIPCREATE=1,2,10000 has to be issued. This all works fine individually, however the sequence of events seems to play a significant role.

Failed sequence.

AT+WIPBR=4,6,0
AT+WIPCREATE=1,1,10000 (setup listening port 10000 on Idx 1)
AT+WIPCREATE=1,2,10000,“IP address”,5000 (Attempt to connect to the server IP on port 5000 using idx 2, however this fails)

Successful sequence.

AT+WIPBR=4,6,0
AT+WIPCREATE=1,2,10000,“IP address”,5000 (Create a “connection” to the server IP on port 5000 using idx 2, and this works)
AT+WIPCREATE=1,1,10000 (setup listening port 10000 on idx 1)
AT+WIPDATA=1,2,1 (Using the normal sequence to send data works well and the server receives the client IP with the correct port 10000)

The server acan then respond to the received IP and port, however the client has to exit data mode on idx 2 and will receive the information from the server on idx 1.

Hope the above makes sense.

Cheers,
Tyrone

OK,

Sorry, this is rather a lengthy response but hopefully of use to other developers.

Firstly, in the case of WIPSoft Tyrone is correct about having to exit data mode on the transmit socket before you can receive packets on the listening socket. However, I believe that observation is only pertinent for WIPSoft, not for coding using WIPLib with ADL. There’s a couple of sentences of relevant (but not super obvious) information in the WIPSoft manual which relate to that, one being section 6.3.2 on “Leaving Continuous /Continuous Transparent Mode” and the other (perhaps more relevant) section is 6.2.11.5. “Packet Segmentation in UDP Socket”.

But back to the original problem… The issue is substantially solved now with the help of several people along the way. I’m grateful for the knowledge snippets contributed by the FAE (Tyrone) plus Louis (Sierra Wireless) but I’d especially like to thank DavidC who has acted as a fellow brainstormer and tirelessly contributed a large amount of time doing prototyping of code and independent testing. I would also like to thank those who made available UDP echo servers so that I could test across the public internet rather than on a private APN network. This was a difficult issue to solve and to be perfectly frank the protracted and painful process of homing in on the issue and resolving it was a direct consequence of:

  • inadequate and confusing documentation of UDP sockets communications in WIPLib (and WIPSoft) manuals,
  • a lack of appropriate code examples,
  • being constrained to work on through the forum and a sometimes less than responsive vendor support system,
  • lack of cooperation and adequate capture tools at the server site during the initial phases.

Anyway, moving right along, hopefully we can all learn something from this exercise and Sierra Wireless can make support improvements for the future. :slight_smile:

For those who’ve missed it here are the original requirements for the project using the Xtend modem:

The Overall System Architecture

The scenario is many hundreds (or more) of remote field telemetry devices (Xtend modems for this project) communicating with a central server using UDP sockets across a GPRS bearers. The GPRS service uses a private APN for connection of the modem devices. Each device must report in to the server at regular intervals, e.g. 15 minutes, and transfer its accumulated data records. The remote device must initiate the communications dialogue and will receive response messages from the server (acknowledgements and configuration data).

Each remote device assigns a fixed (local) port number (11000) to its UDP socket(s) and must specify that in the “Source Port” field of the UDP packet sent to the server. The same port number (11000) is used as the receive port by the remote device.

The server checks the received packets for validity (using both the checksum and command integrity incorporated in encapsulated protocol) and if valid will respond to the remote device. The receive packet’s Source Port number (11000) is transferred to the Destination Port field of the UDP response packet returned to the remote device.

The server may be multi-homed (multiple IP addresses on transmit NICs) and will always spawn a new transmit socket (with a different port number) for each new communications sequence with a remote device.

In addition to regular reporting, the application running on the remote device must either scan and log inputs data, perform local control of other intelligent devices (PLCs etc) or transfer serial data from other devices through the GPRS link to the server (depending on the particular industry application).

The Core Issue and Subsequent Fault Diagnosis

The problem was that no receive event was ever generated in WIP/ADL. On checking with the IT contractor at the server end it was confirmed that the server was replying to the packet that the modem sent.

Initially the modem’s packets contained the wrong port number (1025 instead of 11000) but this was easily rectified.
NOTE: I don’t think its specified in any of the Sierra Wireless manuals but 1025 appears to be the first of the default port numbers if you don’t set the option for the “local port number” on socket creation (if you look at the IANA port list you’ll understand why)

However, even after the correct local port number was specified on socket creation, the response packets generated by the server were still not being recognised by the IP stack in the modem and thus were not received in the application by means of WIP read events. There was initially no visibility of exactly what was happening inside the modem firmware however we were able to obtain Wireshark captures at the server end and verify the IP and UDP port settings for packets in each direction. (refer to the attached image file - you can see the server’s source port incrementing.)

Subsequently I discovered that one could turn on the “NET” traces (I wasn’t aware of this and no one had mentioned it along the way except Dave in the latter stages). With the NET traces enabled almost all was revealed. We could see the packets arriving, being passed through the IP layer but being rejected at the UDP layer. The reason was that the modem appeared to be filtering on the source port number contained in the server’s response packet (see the “no match” NET traces below:

2012/02/27;19:55:33:494;001;NET;16;  IP-INP  192.168.32.125:1025 < 192.168.3.202:60247 pr:17 len:38 id:10748 off:0 
2012/02/27;19:55:33:504;001;NET;20; UDP-INP  192.168.3.202:60247 -> 192.168.32.125:1025
2012/02/27;19:55:33:504;002;NET;20; UDP-INP  No match

The code was modified to include a second “listening” socket (this was actually tried a month or so earlier but without the visibility afforded by the NET traces feature it was not obvious why it didn’t work). The creation of the second (Receiver) socket was tied to the firing of the WIP_CEV_OPEN event on the Transmitter socket. It was believed that this particular event signalled completion of the creation of the Transmitter socket. However, this time a different failure mode was exhibited - the Receiver socket was generating an error on creation and being closed:

2012/03/05;00:14:44:691;002;ADL;1;[appli_entry_point] Creating UDP Transmitter socket.
2012/03/05;00:14:44:701;001;NET;16;  IP-OUT  192.168.32.162:1024 > 192.168.7.5:53 pr:17 len:67 id:1 off:0
2012/03/05;00:14:44:701;002;ADL;1;[WIP] new UDP 0x18104358
2012/03/05;00:14:44:711;002;ADL;1;Creating UDP Receiver socket.
2012/03/05;00:14:44:721;001;ADL;1;ERRLOG ../src/ch_udp.c:401: returned wipint_sockError( res)
2012/03/05;00:14:44:871;001;ADL;1;[WIP] closing UDP 0x18104478

Further up in the trace it was evident that DNS activities were still active. The code was modified to insert a time delay after the WIP_CEV_OPEN event to allow DNS activities to complete. In addition the wip_write() API call was moved from from the Transmitter socket event to the Receiver socket’s WIP_CEV_OPEN event. Finally, SUCCESS! :smiley:

2012/03/05;00:27:14:289;001;ADL;2;- GPRS bearer started.
2012/03/05;00:27:14:289;002;ADL;1;[appli_entry_point] Creating UDP Transmitter socket.
2012/03/05;00:27:14:299;001;NET;16;  IP-OUT  192.168.32.162:1024 > 192.168.7.5:53 pr:17 len:67 id:1 off:0
2012/03/05;00:27:14:299;002;ADL;1;[WIP] new UDP 0x18104358
2012/03/05;00:27:14:309;001;ADL;1;[appli_entry_point] Waiting to allow DNS activities to complete.
2012/03/05;00:27:15:311;001;NET;16;  IP-INP  192.168.32.162:1024 < 192.168.7.5:53 pr:17 len:83 id:17802 off:0  
2012/03/05;00:27:15:311;002;NET;20; UDP-INP  192.168.7.5:53 -> 192.168.32.162:1024
2012/03/05;00:27:15:321;001;NET;20; UDP-INP  Socket found
2012/03/05;00:27:15:321;002;ADL;1;'WIP_CEV_OPEN' event fired on Transmitter socket.
2012/03/05;00:27:15:331;001;ADL;1;'WIP_CEV_WRITE' event fired on Transmitter socket.
2012/03/05;00:27:24:223;001;ADL;1;Creating UDP Receiver socket.
2012/03/05;00:27:24:233;001;ADL;1;[WIP] new UDP 0x18104478
2012/03/05;00:27:24:524;001;ADL;1;'WIP_CEV_OPEN' event fired on Receiver socket.
2012/03/05;00:27:24:534;001;ADL;1;'WIP_CEV_WRITE' event fired on Receiver socket.
2012/03/05;00:27:54:537;001;ADL;1;Writing MESSAGE to Transmitter socket...
2012/03/05;00:27:54:547;001;NET;16;  IP-OUT  192.168.32.162:11000 > 192.168.3.202:13000 pr:17 len:41 id:2 off:0
2012/03/05;00:27:54:557;001;ADL;1;13 bytes of data written to Transmitter socket
2012/03/05;00:27:55:959;001;NET;16;  IP-INP  192.168.32.162:11000 < 192.168.3.202:57325 pr:17 len:38 id:1059 off:0  
2012/03/05;00:27:55:959;002;NET;20; UDP-INP  192.168.3.202:57325 -> 192.168.32.162:11000
2012/03/05;00:27:55:969;001;NET;20; UDP-INP  Socket found
2012/03/05;00:27:55:969;002;ADL;1;Packet received - 10 bytes of data

This was a “kludge” for testing but it proved the point - with a 10 second delay the Receiver socket was successfully created and a WIP_CEV_READ event was generated for the received packet. This however is a temporary “kludge” and the proper means of ascertaining completion of the Transmitter socket creation still needs to be ascertained and implemented.

The current code module (a modified version of the entry_point.c module) is attached.

SUMMARY OF LEARNING

  1. Ensure that the following are available for testing:
  • Wireshark or other capture tools at the server site
  • a UDP echo server on the public Internet
  1. Two sockets are required for a system with this architecture (many clients each initiating UDP communications, one server responding to clients).
  • When creating the Transmitter socket specify the local port and pseudo-connect to the server by specifying the peer address and peer port.
wip_debug( "[appli_entry_point] Creating UDP Transmitter socket.\n");
  txSocket = wip_UDPCreateOpts( evh_udpTransmit,
		  	  	  	  	    NULL,				// Context not used
		  	  	  	  	    WIP_COPT_PORT, LOCAL_PORT,
		  	  	  	  	    WIP_COPT_PEER_STRADDR, PEER_STRADDR,
		  	  	  	  	    WIP_COPT_PEER_PORT,    PEER_PORT,
		  	  	  	  	    WIP_COPT_END);
  • Ensure that the DNS etc activities associated with creation of the Transmitter socket have completed before creating the Receiver socket (proper method to be advised). Note that the WIP_CEV_EVENT cannot be used to guarantee this.

  • When creating the Receiver socket specify only the local port.

wip_debug("Creating UDP Receiver socket.\n");
	rxSocket = wip_UDPCreateOpts( evh_udpReceive,
		  	  	  	  	  	  NULL,			// Context not used
		  	  	  	  	  	  WIP_COPT_PORT, LOCAL_PORT,
		  	  	  	  	  	  WIP_COPT_END);
  • Once the Receiver socket has been created, use the wip_write API call to write to the Transmitter socket.
wip_debug("Writing MESSAGE to Transmitter socket...\n");
	nwrite = wip_write( txSocket,			// the socket to write to
				     MESSAGE, 			// pointer to data in buffer
				     sizeof(MESSAGE) );	// number of bytes to be written
  1. Turn on the NET level traces to see the events in the WIP stack. Send the WIP traces to the serial port by using the options when initialising the WIP stack:
r = wip_netInitOpts( //WIP_NET_OPT_DEBUG_PORT, WIP_NET_DEBUG_PORT_UART1,  //WIP traces on UART1
		  	  	  	   //WIP_NET_OPT_DEBUG_PORT, WIP_NET_DEBUG_PORT_UART2,
		  	  	  	   WIP_NET_OPT_DEBUG_PORT, WIP_NET_DEBUG_PORT_TRACE,
		  	  	  	   WIP_NET_OPT_END );
  1. Always check the return values of API calls.

  2. Getting Support
    For initial questions the forum can be of some help but the response time is quite variable and the contribution of SW engineers in the forum has in the past been fairly rare. Leverage the the experience of your FAE and use him/her as the initial front-line support. Remember, though, that the FAE’s cannot reasonably be expected to provide full-time support due to involvement in their own training sessions, customer visits or installation work. When the going gets really tough then its time to either :

  • enlist direct support from the SW product support engineers - but don’t leave it too late! , and/or
  • contact a fellow developer via the forum who is obviously very experienced - but don’t waste their time if you haven’t either made a reasonable effort at fault-finding or done your homework beforehand by trying to read the manuals!
    entry_point.c (8.73 KB)

Hi all.

Can anyone tell me if this issue has been resolved?
Are Sierra Wireless even looking at the issue?
When will new firmware be released?
Any info at all…???

I need to use the IP stack and implement transparent mode for a current project - am I wasting my time with this modem?

Thanks…

Good morning,

This issue seemed to be related to the actual server that is being connected to rather than the IP stack. The reason I say this is that doing the same test, connecting to different servers with the same device and software, yields different results.

Regards,
Tyrone

Wez,

There were a number of “issues” in this case:

  1. Technical - no UDP receive event was generated for the case where the source port of the received message did not match the source port of the transmitted UDP message. This has been resolved and the reasons and code have already been presented.

I am of the firm belief that the code base of the IP stack should be modified to preclude this issue in the future. Tyrone’s 2 May 2012 post is essentially referring to port numbers in received messages and whiilst that’s correct, the fact of the matter is that this problem does not occur with either .NET or DELPHI UDP communications and neither does the issue occur with a well-known competitive M2M product. Unfortunately the simplistic SW code sample does not cover the cases that can be expected under the UDP RFP so this needs to be urgently addressed by either modifying the code base of the IP stack (the preferred approach) or generating additional samples and documentation.

  1. Vendor Support - The jury is out on whether this will improve, but I don’t believe that in excess of two months to resolve an issue of this type is commercially acceptable. As I understand it the SW policy is that all communications related to support must be directed through the local FAE. I would suggest that it would be prudent to qualify that with a time period for the issue to be resolved, i.e. if not resolved within an acceptable period (say a week) and its clearly not a case of coding errors then a channel direct to SW engineering should be established. SW engineers may well be watching the forum posts but they sure as heck took a long time to get involved, and furthermore they didn’t initiate that involvement themselves.

  2. Documentation and Applicability of Sample Code - there’s no question that this is an area that Sierra Wireless needs to expend considerably more effort on. The problem was inherited from Wavecom however subsequently there appears to have been little or no revision of either manuals or samples. In our case knowledge of an undocumented trace feature could have shaved many weeks off the fault resolution time. The word is that the undocumented trace features (e.g. the NET traces) were only ever intended for SW internal debugging use however the reality is that many of these traces features would be invaluable for developers - TIME IS MONEY for developers!. The more information you can glean from the system the better the chance of resolving the problem quickly.

My comments above should be viewed in the context that I am confident that the Sierra Wireless hardware platform is excellent but I am concerned that the software documentation and support hasn’t yet matched that level of hardware excellence. Experience with embedded products over an extended period teaches that you cannot achieve success with a product unless all of the elements of hardware, software and support are properly addressed by the vendor.

In summary, there is no good reason not to use the product but I’d strongly recommend that you liaise with your supplier to ensure that some guarantee of acceptable support arrangements if you are contemplating a serious commercial development project.

Eric

Hi Eric

I just wanted to thank you for writing this example for UDP - perhaps SW will fund you to write a section for the WIP manual.

For anyone else struggling I found an additional bug:

WIP_COPT_PEER_ADDR, PEER_INT_ADDR,

Causes:
ERRLOG …/src/ch_udp.c:386: returned WIP_CERR_INVALID

So it looks like we need to use (as per Eric’x example):
WIP_COPT_PEER_STRADDR, PEER_STRADDR,

Ted