Udp with EMX and FW 4.2.5.0

NETMF & Gadgeteer
1

I wrote a small program which creates a simple Tcp server by which I can send commands to it from my PC.
On one of the commands it starts a new thread that connects a Udp port and sends some data until another command is sent via Tcp to stop it.
So far so good, everything works well with my G120HDR and ENC28 (using EthernetENC28J60).
But when I run the same program on my Cobra I with EMX and Builtin ethernet (using EthernetBuiltIn) it looks like as if no data is sent by Udp.
Everything else is working as expected.
I do not get any errors or exceptions or printouts in the output window.
I have tried without Socket.Connect and SendTo and with Connect and Send.
Both do not work.
Here is my Udp code:


private Thread _NWSpeedThread = null;

private int _NWSpeedTestCnt = 0;

private IPAddress _RemoteIp = null;

private void RunNWSpeedTest()
{
   int sz = _NWSpeedTestCnt;
   var socket = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);
   socket.Connect(new IPEndPoint(_RemoteIp, 2000));

   byte[] buffer = new byte[sz];

   Debug.Print("Start sending ...");

   var tStart = DateTime.Now;

   while (_NWSpeedTestCnt > 0)
   {
      var t = DateTime.Now;
      Microsoft.SPOT.Hardware.Utility.InsertValueIntoArray(buffer, 0, 4, (uint)((t.Ticks - tStart.Ticks) & 0xffffffff));
      socket.Send(buffer);
      Thread.Sleep(0); // giver other threads a chance to work
   }
   socket.Close();
   Debug.Print("Sending stoped");
   _NWSpeedThread = null;
}

I already tried to increase my Sleep(0) to several higher values withou any effect.
The Tcp connection which is open in parallel is still working perfect.
I have currently no idea what is wrong here. Any help would be welcome.

2

I don’t see _NWSpeedTestCnt ever getting set to anything greater than zero? Or decremented in loop?

3

_NWSpeedTestrCnt is named a bit wrong. It controls the Bytes per Frame which will be sent.
Before starting RunNWSpeedTest as a Thread it gets set to 10, 1000, 1400 or any package size I want to test.
To stop the test it gets set to 0 from an other thread, and the Performance test is stopped.
As mentioned this works well, also for the Cobra board.
But from the Cobra board not a single Byte is received by my PC.
On my G120HDR the data is sent and I can receive it on my PC.

4

Have you looked at what is coming out of the Cobra with WireShark?

You might also try a Bind() instead of a Connect() for the sending socket.

Are you able to ping the Cobra?

5

I haven’t used WireShark here so far, will do on Monday when I’m back in Office (it’s late here in Germany already).

I can not use a Bind for a specific IP address as far as I know. This is the Sender (Udp Client), so as far as I know I have to use Connect or SendTo (I tried both)
If I use bind with anything else than IPAddress.Any I get an exception. The IP which is used for the remoteEndPoint (_RemoteIp) is taken directly from the Tcp Connection, and since I print it out on Startup I assume that it is correct.

I have not pinged the Cobra, but I have an open Tcp connection from my PC to the cobra where I send the start and stop signals to to it, so I assume that the Network works in General.

The code can also not be totally wrong, because it is working on my G120.

6

now there’s a non-beta SDK I’d go and re-test after installing it and after updating firmware everywhere

7

sure, 1st thing tomorrow morning is installing the new SDK/Firmware and test again.
Then I will use WireShark to see where my data is lost.

8

The update to FW 4.2.7.0 made no difference
.
But WireShark had some supprises for me:
Sending 10 data Bytes with the same code creates a
60 Byte long telegram when send by EMX (cobra) with builtin but a
64 Byte long telegram when sent by G120 (HDR) with ENC28
I’m not an expert on IP stack, but I think this might be the reason why my receiving application on my PC does not get the telegrams from the EMX board

Here are the HEX-Strings of two telegrams containing 10 Bytes of data:
EMX: 782bcbe82f610021030000010800450000263dd40000ff11a762c0a82a94c0a82aab100107d000121f5341e3278950187fd842720000000000000000
G120:782bcbe82f61002103000002080045000026119e0000ff11d398c0a82a94c0a82aab100107d0001227cf2994c005000000000000374637453737323336303443

The data is not exactly the same because I always send a timestamp in the 1st 4 Bytes. The remaining 6 Bytes are not initialized, but should be zeros.
When I take a closer look at the 10 Byte data:
For G120 I get an increasing number in the 1st 4 bytes (my timestamp) and zeros for the remaining 6 Bytes (as expected)
For EMX the data looks wrong. The remaining 6 Bytes need to be identical in each telegram, because i re use the same byte array. only the 1st 4 bytes are updated.

here are a fiew samples of EMX data:
41:e3:27:6b:50:18:7f:f6:45:84
41:e3:27:75:50:18:7f:ec:44:7e
41:e3:27:89:50:18:7f:d8:42:72
41:e3:27:89:50:18:7f:d8:42:72
00:00:00:00:00:00:00:00:00:00
41:e3:27:89:50:18:7f:d8:42:72
41:e3:27:89:50:18:7f:d8:42:72
00:00:00:00:00:00:00:00:00:00
41:e3:27:89:50:18:7f:d8:42:72

and here the data from G120:
7d:03:00:00:00:00:00:00:00:00
02:f6:00:00:00:00:00:00:00:00
15:4d:01:00:00:00:00:00:00:00
25:a2:01:00:00:00:00:00:00:00
a2:f8:01:00:00:00:00:00:00:00

Is it possible that there is some bug in the Udp implementation for the EthernetBuiltIn interface?

9

I did some more research:
1st I connected it directly by an X-over cable to make sure nothing else has any influence.
2nd I changed my sent data to a series of bytes from 0x01 to 0x0a to make it easier to identify it within the telegrams.

The reason for the different telegram length seems to be that EMX does not send the Frame Check Sequence, which is 4 Bytes long. I don’t know if this is optional or not.
G120 does send the Frame Check Sequence, but it is wrong all the time, sometimes it is zero, sometimes some random value.
The EMX telegram does not contain my sent data at all. I can not find the 10 Bytes in the whole telegram.
Attached 2 screenshots from WireShark showing a EMX and a G120 telegram next to each other.

As mentioned the problem is not that the Data received from EMX is wrong, but that my .NET Windows App does not receive anything at all from EMX.

10

So I’m at the end with my knowledge here.
The only thing I can add is that I just read that the shortest Ethernet Package is 64 Bytes long.
This points me more and more in the direction that there is soething wrong with Udp on EMX with 4.2.x. I know that Udp worked with 4.1.x.
May be the TimeServer Problems on EMX are related too:
http://www.tinyclr.com/forum/topic?id=9672&page=1#msg97737

@ GHI: could you check this please?

11

I also have UDP failures on EMX. It was working fine on MFW 4.1, but as I migrated to the various 4.2 RC’s and now the 4.2 release (29th-Nov), I’ve had this problem. Sounds like it’s going to need a GHI patch.

12

We are investigating still.

13

I’ve built a CLR UDP implementation using raw-sockets (have to manage UDP and IP v4 layers manually).
I’ve tested it on the emulator and it’s working OK - will test on EMX soon.

It provides an option to work around this until the underlying problem is fixed.

As soon as I’ve verified operation on EMX, I’ll post the code.

14

Sorry this is taking longer than usual but this is on the top of our list

15

This has been fixed and will be in the next release.

16

Any idea about when that update will be released?

17

Few weeks