FEZ Spider UDP sockets

FES Spider
NETFW = 4.2
J11D connector - wired ethernet
Good 5v PSU
MAC = Sticker on module


I have spent many hours trying to get a very simple UDP socket to listen and respond to a client using mimimal code at this point. In the emulator everything works fine and my client on a different PC can talk to the emulator without problems at all. When I load the code into the Spider again things seem normal and the Spider receives the UDP message from the client and responds with the 4 byte response message. At this point it seems things are very wrong but no errors are generated at all. Here is what happens:

The Spider listens for a UDP incoming message (fine it comes and content looks good).
The Spider responds with SentTo(…) with 4 bytes (all sems fine, SendTo reports 4 bytes sent).
I can see the UDP packet with WireShark on my client machine but the 4 byte data is corrupt (every time and the bytes could contain any rubbish).
My C# client code never see’s any data arrive at all.
The source, destination and port numbers all seem fine in WireSharks capture.

I also have an EMX dev board and loaded the same project on that (NETFM 4.0.1). Now everything works absolutely fine within a couple of seconds.

Either there is something fundamental I am not doing for the FEZ Spider, it is faulty or NETFM 4.2 is buggy, I just don’t know.

Please can you help.


Hi, Just for info. I did a firmware update again just to be clean and I still have corrupt data coming out of the FEZ Spider.


code please

Hi Mike,

I have extracted some code from my project as requested. I am trying to use the minimum code at the moment just to prove everything. Like I mentioned, the problem is with data corrupted coming out of the Spider (SendTo) and it all works fine in the emulator and on an EMX dev board with 4.0.1 NETMF.

                     m_server = new Socket(AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp);

                    m_localEndPoint = new IPEndPoint(IPAddress.Any, 6213);
                    m_remoteEndPoint = new IPEndPoint(IPAddress.Any, 0);


                    if (m_server.Poll(-1, SelectMode.SelectRead))
                        byte[] buffer = new byte[m_server.Available];

                        m_server.ReceiveFrom(buffer, ref m_remoteEndPoint);

                        IPEndPoint ipe = (IPEndPoint)m_remoteEndPoint;
                        byte[] response = new byte[4];

                        response[0] = 45;
                        response[1] = 77;
                        response[2] = 45;
                        response[3] = 77;

                        m_server.SendTo(response, m_remoteEndPoint);

The response array is just test data to prove things.


@ Derek -

What is the date of the 4.2 firmware you are using?
How big is the IP packet in WireShark?
To what values are the four bytes you sent being changed to?

Could you post the WireShark data for the packet?

@ Derek -

You can auto format your code snipet (easier to read) if you use “Format as code” button in the toolbar.

Ok Architect thanks, couldn’t see the button though.


Here is a pic of the Wireshark screen with the data selected. The data changes between calls so its random corrupt data. From what I can tell the UDP packet is ok to an extent.

I just updated the firmware on my EMX dev board to 4.2.4 (from 4.0.1) and now the same code has the problem on this board too. From this I think there is no hardware issue with the Spider board. It seems there is a problem with the firmware as I can demonstrate it consistently.


Forgot to mention the program used for the firmware update on the Spider and EMX board.

FEZSpiderMainboardUpdater.exe - 24.08.2012

EMXUpdater.exe - 24.08.2012


@ Derek -

I am puzzled. I do not have access to an Ethernet module or EMX dev system where I am now.
I will try to remember to bring one or both to work and try out this code tomorrow.

Hi Mike,

Thanks. I am trying to develop a product with the EMX but I am spending so much time on basic issues like this. My confidence is this type of product is decreasing rapidly right now. I would have been quicker to get a PIC ethernet device up and running.

In summary:

UDP sending works without corruption in 4.0.1 but is corrupt on 4.2.4. Tested with an EMX gadgeteer and EMX dev board. Both show the same problem. My impression is that 4.2.4 is the problem.

It might also explain why the static/dhcp side of things does not feel right to me, sometimes the dhcp works and sometimes not, it’s all a bit frail.


Hi Mike,

I just installed firmware 4.1 on my EMX and the UDP sending is fine. So 4.0.1, 4.1 work ok but 4.2.4 does not send UDP data correctly.

This is such a fundamental thing to do, send a few bytes in response to an incoming UPD packet, could this have ever been tested do you think?




Yes, this is with the appropriate GHI SDKs and uploader programs for the firmware.



I meant that someone from GHI should look into this issue.


Yes I think so. I have installed v4.1 on my Gadgeteer and EMX dev board and all is good. My Android devices and PC’s can all talk to the EMX stuff now but I don’t want to be stuck on an old release :-(.

How do GHI get to take a look, do we rely on them reading these posts?



There is an SDK coming out this week with many changes. Please try and let us know.

Hi Gus,
ok I will try the new SDK. Is this 4.3 or an update to 4.2?

I am really trying to adopt the EMX and NetMF for serious product development. How can I be confident that fundamental mechanisms like basic tcp and udp work properly. The problem is the time required to sort things like this out.

Should I only consider netmf as a hobby type development rather than serious product development?


4.2 is in beta so issues are somewhat expected. If your product ships before January then 4.1 is the way to go.

GHI does multi-million dollar in the sale of NETMF devices to companies/professionals around the world. Yes it is very much developer friendly that it is used by non-professionals but this does not mean NETMF quality or GHI product quality and support are anything less that what you would expect from similar offers/companies.