Hydra and ENC28 networking issues

Archive
1

Hi all,

I’m new to Hydra, but have dabbled with Netduino and netmf a bit. I’m developing an ethernet connected data logging and protocol sniffing system and like Hydra’s resources and openness. However, I have come across a couple of issues related to ethernet.

My Hydra currently has ethernet-enabled firmware 4.1.2821.0 (solution ver 4.1.3.1) and that’s what I’ve been experimenting with. I started updating to the 4.2 beta firmware then realised it does not have ethernet support yet, so am back to 4.1.

I can get Hydra communicating nicely with a webserver (only doing POSTs for now) using the ENC28 module. I’ve only got it working with static IP yet, but DHCP functionality is a requirement for this application. I’ve tried setting that up through MFDeploy but had no luck. Does it need to be done programmatically (in application code) or is it just not fully supported yet?

I also notice that Hydra works fine UNTIL the ethernet cable is disconnected from the ENC28, and then it seems to lock up. I have a heartbeat LED flash in a separate thread, and I do the ethernet connection (endpoint and then socket.connect) in another thread in a try/catch, but everything locks up when I try socket.connect() after pulling the cable out. No heartbeat or debug activity. Only a reset (button or poweroff) gets it working again.

If the ethernet cable is not present at bootup, the connection attempt fails immediately with an exception and there’s no lockup.

I wonder if anyone else has similar issues, or if there’s a better way to do things. I’ll try to post some code once I’ve got a sample organised.

Also, what’s the status or timescale for ethernet/ENC28 support on 4.2 firmware. Is that likely to be dynamic ethernet instead of the 4.1 style compiled-in support? I’m afraid I don’t yet have the experience to be contributing much to the firmware but that may come in time…

2

Not enough testing was done on Ethernet support as we started the switch to 4.2 right after. The good news is that we are near done with 4.2 move and will be concentrating on perfecting all features after.

Welcome to the community.

3

Hi Gus,

Thanks for the welcome and the update on status. I’ll be experimenting some more, and will try any new firmware when it’s available.

I’ve also been playing with Netduino Plus, and it appears to have related networking issues so this could be a netmf problem rather than specific to ENC28 or the hydra port.

PS I meant to post this thread in the Gadgeteer section instead of beta, but I guess it might relate to more products. Move it if you want.

4

You could contribute to this open source project.

If you aren’t up for helping, buy the Spider, and instead donate the Hydra to somebody on this forum or a local hackerspace.

5

Hydra and ENC28 networking issues -> CerbuinoBee , ENC28, NETMF 4.2

I experience the same problem with my configuration: pulling out the ethernet cable results exceptions from which I am not able to recover, the system locks
… for this reason this platform is unfortunately not suited yet for commercial projects. Only a power-reset recovers the system.
Is there any chanche this problem will be tackled?
Thanks,
Freeck

6

Much been done since then so if you have a problem then ease show exact steps to repro.

7

Gus, Sorry for my impatience…I was puzzled by the behaviour of the connections…

My source code is structured like this:
the main thread waiting for client-request for a socketconnection.
on each accepted connection a socket receive thread is created.
It works fine with 1 and 2 and perhaps more client threads (not tested more than 2 yet).
Connections are served and data is received.
Now:
1: In case I pull out the ethernet cable trap-messages occur on the listening method, and not the data receive method in the thread…!?
2: In case I pull in the ethernet cable the listening process recovers…So that is the good news…your software behaves pefectly in that respect.

One thing still puzzles me, how to detect a disconnect on the reciever thread and method?

main loop:
while (1 == 1)
{
Debug.Print(“Listening to clients”);
try
{
listenSocket.Listen(5);
}
catch (Exception e)
{
Debug.Print(e.Message + “listenSocket.Listen(1) trap”);
};
// wait for request from clients
while (1==1)
{
try
{
Socket newSock = listenSocket.Accept();
Debug.Print("Accepted a connection from " + newSock.RemoteEndPoint.ToString());
new ProcessClient(newSock);
}
catch (Exception e)
{
Debug.Print(e.Message);
Debug.Print(“listenSocket.Accept() trap”);
Thread.Sleep(1000);
//break;
}
}

internal sealed class ProcessClient
{
private Socket internalSocket;
public ProcessClient(Socket mySocket)
{
internalSocket = mySocket;
new Thread(ProcessRequest).Start();
}
private void ProcessRequest()
{
byte[] Data = new byte[1000];
int Rec = 0;

            while (1 == 1)
            {
                try
                {
                    Rec = internalSocket.Available;
                    if (Rec > 0)
                    {
                        Debug.Print(internalSocket.Poll(1000, SelectMode.SelectRead).ToString());
                        internalSocket.Receive(Data, SocketFlags.None);
                        Debug.Print("Received:" + Rec.ToString() + "bytes");
                    }
                }
                catch (Exception e)
                {
                    Debug.Print(e.Message + "Socket.Receive catch"); 
                    break;
                }
                Thread.Sleep(10);
            }
            return;
        }
    }
}
8

Please use code tags so teh code is readable and also provide a complete test setup/code that we should use to see the problem.

9

pulling out an Ethernet cable will not result in a socket read command terminating with an exception. if you want to detect this, an
application normally includes some type of heartbeat message between the end points of the connection.

you could also have another thread that monitors the state of the cable, and if it is removed, closes the session socket, which will terminate
the read with an exception. but, I am not sure if the ENC28 supports cable state detection.

10

I understand that a read does not result in a trap in case the cable is pulled out, but I got a listen trap on the listen.method in the mainloop…that puzzles me…
In the mean time I will test my configuration with 2 clients on different machines, and see what the behaviour will be…

Your suggestion to monitor the connection in the receiver thread: OK thats a solution I have to consider.

11

@ freeck - the accept code may be checking the state of the cable?

12

That correct, in my previous message I made a mistake

[quote]Now:
1: In case I pull out the ethernet cable trap-messages occur on the listening method, and not the data receive method in the thread…!?
2: In case I pull in the ethernet cable the listening process recovers…So that is the good news…your software behaves pefectly in that respect.

One thing still puzzles me, how to detect a disconnect on the reciever thread and method?[/quote]

Should have been
1: In case I pull out the ethernet cable trap-messages occur on the accept method

13

What I observe is that I get a trap on disconnecting the cable, there are more traps generated from the socket.acceptmethod.

this is what happens:

[quote]listenSocket.Accept() trap
A first chance exception of type ‘System.Net.Sockets.SocketException’ occurred in Microsoft.SPOT.Net.dll
Exception was thrown: System.Net.Sockets.SocketException[/quote]

The debugger says e.Message code is 10050. See MSDN [quote]Windows Sockets Error Codes (Winsock2.h) - Win32 apps | Microsoft Learn [/quote] it says:

[quote]WSAENETDOWN (10050)
•Translation: Network is down.
•Description: A socket operation encounters a dead network. This error may indicate a serious failure of the network system (that is, the protocol stack that the Windows Sockets DLL runs over), the network interface, or the local network itself.
[/quote]

Sounds reasenable, not?