Ethernet Socket Fails over time

I have code on a fez Cobra (mf 4.1) that I am trying to port over to any of the Gadgeteer boards (Cerb,Hydra, Spider) with mf 4.2.

I have a fairly simple app that reads short messages (@ 10 Bytes) from a serial port, Converts the messages into XML, and writes them to a TCP Socket (@ 1000 bytes).

I have run the cobra for months and not had any issues.

On every single gadgeteer I have the same issue, @ the 1.5 hour mark, the entire system just hangs mid write of my XML (as viewed in teraterm)

Is there something different about the Gadgeteer ethernet or the 4.2 code that I should be aware of?

I have been chasing this for a while now And it is really becoming a project ender for me.

Here is how I am implementing the Ethernet on a Cerberus:

        private NetworkInterface _networkInterface = NetworkInterface.GetAllNetworkInterfaces()[0];
        private Socket _clientSocket 
        private Thread _listener;

        private void ProgramStarted()
            //unrelated code goes here
            while (_networkInterface.IPAddress == "")
                Debug.Print("Awaiting IP Address");

            _hostSocket = new System.Net.Sockets.Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
            IPAddress hostIP = IPAddress.Parse(_networkInterface.IPAddress);
            var localEndPoint = new IPEndPoint(IPAddress.Any, Utility.LISTENING_PORT);

            _listener = new Thread(ListenerLoop);

        private void ListenerLoop()
            while (true)
                    _clientSocket = _hostSocket.Accept(); 
                catch (Exception e)

        private void MediumTimer_Tick(Timer timer)
            var message = GetMessage();
            if (_clientSocket != null)

Any ideas would be helpful, thanks


AFAIK there were a lot of IP related changes in 4.2, but since you’re going to 4.2 + Gadgeteer you also have a large change from going just from a core 4.1 implementation to a 4.2 (new IP) plus Gadgeteer (newish). Have you tried keeping Gadgeteer out of the equation for the time being?

As far as thoughts on your actual issue, the only one I have is that you’re using a timer in the code above but I can’t see your declaration of it. There is a need to use the Gadgeteer timers rather than the netmf timers as the Gadgeteer code wants to do all the dispatching so perhaps you’re hitting an issue there. If the issue is always coming up at 90 minutes, there’s a good chance it’s not memory exhaustion or some other “more random” event causing the issue, it’s potentially some form of timer clash.

Yes I am using timers, they are gadgeteer timers, and the crash time is random somewhere between 1 and 2 hours.

by eliminate gadgeteer, do you mean code with the .netMF classes only?

@ Tal_McMahon - Given the code you have posted, there seems to be a possible issue. You keep replacing your _clientSocket instance when a new connection comes in. You are not able to gracefully clean up the orphaned instance which will put the client socket in a wait state, I do not know if this is the route cause, but the code seems suspicious.

Thanks for the Idea @ taylorza. Unfortunately it did not help. I have made a new post that fully describes the problem at
Thanks for your comment