I believe my earlier report about 4.1.0.6 is incorrect. Socket.Connetc() is not so troubled after all. Yesterday I cleaned up my code and noticed that Socket.Connect() would recover if I gave it time. Was this due to me being impatient to wait for a proper timeout???? Maybe. Was this due to some small changes to the code? I doubt it. My observations regarding 4.2 hold. All the same, waiting for RC5 still seems like the right move. In the mean time, a person might want to consider 4.1.0.6 over RC4, as it is more forgiving about powering up without ethernet. -kluger (does anyone have "ping" code so that I can ping the gateway from the netduino to test for network connectivity?)

I did a little more testing today:
Recall I have two N+s on my network:

1) Netduino+ "A" is sending http request to "B" upon a button press (uses Socket.Connect())
2) Netduino+ "B" is listening for http requests (uses Socket.Listen())

I have already described the behavior with 4.1 (yesterday).

Today I had both Netduino's running 4.2 RC4.
For "A" I have confirmed what I found yesterday, opperation is only upset when the cable is unplugged during boot. Odd, if I pull the ethernet cable to "B" and restore it, "A" seemingly locks up internally but responds to pings. If instead I power cycle "B", "A" behaves well. I suspect this is due to either my code or my switch.

For "B" things are a little different:
If the ethernet cable is unplugged after Socket.Listen() is called, the Netduino+ seemingly locks up internally, not just the network port. When the ethernet cable is restored, external pings are acknowledged, however internally the Netduino+ remains locked up.
-I did not test unplugging the ethernet cable without a call to Socket.Listen(), this would require me to modify further the twisted code I've been using to test this. I suspect that just as "A" would not work if booted withough the ethernet cable, so would "B".

I noticed other potential investigations, but it makes more sense to wait for RC5 and retest.
If I were able to contribute to RC5 (or RC6), I would, but frankly my coding skills need development.

Is there anything ALPHA? I could test? I'm brave.

I more carefully read the forums and have found several threads from the past regarding these problems.

Is there a bug board???

Anyway, I'm going to let this rest for now.

-kluger

I am having the same problems.
The title of this thread is not completely correct.

I have two N+s on my network:
1) Netduino+ "A" is sending http request to "B" upon a button press (uses Socket.Connect())
2) Netduino+ "B" is listening for http requests (uses Socket.Listen())


While Running 4.1:
"A" hangs on calls to Socket.Connect() while the network is unplugged.

mattcro: If Netduino has an internet connection at boot, but the internet connection is lost after boot (ie router-switch cable unplugged while application is running), then the next connection attempt does not succeed (obviously) but neither does it time out. It gets stuck at socket.Connect(). The Netduino does not seem to be locked up completely, because my app has a timer event driven LED blink that keeps working.

I have confirmed mattcro's experience, except I find that the network cable may be unplugged during boot, as long as Socket.Connect() is not called. If I unplug "B" so that the Socket.Connect() fails, an exception is thrown (which is caught) and "A" recovers as expected. The failure is specific to calling Socket.Connect() while the ethernet cable is unplugged. Edited on 2012-04-25.

"B" can have the network unplugged at ANY time and recovers well when the network is restored.

This problem is specific to Socket.Connect(). Edited on 2012-04-25.

With Running 4.2 RC4 on "A":
If "A" is booted without the Ethernet cable, the network port does not work. This is different from 4.1.
If "A" is allowed to boot with the Ethernet cable, the ethernet cable may be pulled at any other time, consistent with mattcro's experience.

I must go to bed, otherwise I would try 4.2 RC4 on "B", I suspect that booting without Ethernet will cause the ethernet port to not work. Maybe I can test this tomorrow.

There is another unrelated network issue with busy networks causing the network port to shut down. I have found this to be true with 4.1 and 4.2.
A similarity with the Socket.Connect() problem is that when the busy network shutdown happens, internally the N+ is unaware. Even "pings" to the "localhost" are returned, while externally... nothing. I have one fairly busy network that causes the N+ network to die withing minutes, and then I have a very quiet network and have had a pair of N+'s running for days.

Sure would be great if there were a fix for both these problems.
Wish I knew enough to help with fixing the problem, maybe someday I will be more skilled.

-kluger

Thanks for your response emg, I have been thinking about how to implement something like you have described, but in my case I have several N+ talking with each other. What I may try is to have the N+ ping the gateway, and resets itself if the gateway becomes unreachable, but this solution seems sloppy to me. I've looked around a little, has anyone written a "ping" for the N+? The best solution would be a software test I can do to see if the network is alive. Any other ideas??? -kluger

I wrote a program that -sends "pong" to address 127.0.0.1:51110 -blinks the onboard led -listens on port 51110 and prints whatever is recieved to the Debugger. I ran this overnight on a network with some traffic, while simultaniously pinging the device from another computer. When I checked this morning: -The program was still running and printing "pong" to the Debugger. -pinging the device from another computer had failed. Here's the code: using System.Net; using System.Net.Sockets; using System.Threading; using Microsoft.SPOT; using Microsoft.SPOT.Hardware; using SecretLabs.NETMF.Hardware.NetduinoPlus; using System.Text; namespace PingLocalhost { public class Program { private static OutputPort onboardLED = new OutputPort(Pins.ONBOARD_LED, false); public static void Main() { new Thread(TCPServer).Start(); Thread.Sleep(500); while (true) { TCPClient(); Debug.Print("Main() I'm still alive! memory available: " + Debug.GC(true)); onboardLED.Write(!onboardLED.Read()); Thread.Sleep(1000); } } #region Test TCP Methods static void TCPClient() { using (System.Net.Sockets.Socket clientSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp)) { IPEndPoint remoteEndPoint = new IPEndPoint(IPAddress.Parse("127.0.0.1"), 51110); clientSocket.Connect(remoteEndPoint); clientSocket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.NoDelay, true); clientSocket.SendTimeout = 3000; byte[] message = Encoding.UTF8.GetBytes("pong"); clientSocket.Send(message); } } /// <summary> /// TCPServer() Largerly ripped off from SirPoonga /// </summary> static void TCPServer() { using (System.Net.Sockets.Socket socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp)) { socket.Bind(new IPEndPoint(IPAddress.Any, 51110)); socket.Listen(1); while (true) { using (Socket newSocket = socket.Accept()) { if (newSocket.Poll(-1, SelectMode.SelectRead)) { byte[] bytes = new byte[newSocket.Available]; int count = newSocket.Receive(bytes); char[] chars = Encoding.UTF8.GetChars(bytes); string str = new string(chars, 0, count); Debug.Print(str); } } } } } #endregion } }

I have been having issues with the network dying on my Netduino Plus. This poster seems to be having same/similar prob: http://forums.netdui...vailable-in-42/ -Being on a busy network is what is killing it (it seems). -I have found this on 4.1 and 4.2 firmware. -Seems independ of code. -When "dead", the rest of the Netduino still works. --If a debugger is running, the program can report things like network address. --onboard LED will continue to blink in a continuous loop. --Pinging the Netduino ceases to work. While on a busy network, it takes between 5minutes and an hour for the Netduino's net to stop responding. While on a very quiet network, the Netduino seems to live a great deal longer... I just started a test setup and will let it run for a day. My question: From within the C# program, can I detect when the network port is no longer responsive? I just had an idea!!!! maybe I could ping the localhost???? Anyways, I'd prefer to not have a watchdog. I prefer that the network port be dependable, or barring that, be able to detect in software when the network port had died and so have the software decide when to smartly do a reset. Any ideas? -kluger

Hello DataCrypt, I thought about doing what you want to do, but partly I stopped persuing building my own Netduino Plus because I was not able to source the network stuff from the usual sources. Tell me where to source the parts (in the U.S.A.) and I'll take this up again. Clearly building your own will not be cost effective, but fun just the same. I'm all for it. -kluger

Hello All, Here is a detailed five page guide for how to update the firmware on a Netduino Plus, and what to expect durring each stage. For example: some of the steps take less than a second while some take a great deal more time. I hope you find this document useful. -dusty

Hello Niko, I made the same mistake as you made! The good news is that I got a MAX232 chip to inteface between the Netduino and the RS232 interface and now all is well. There has been no apparent damage to the Netduino Plus. I am able to Rx as well as Tx! Hurray! Thanks all for your help. -dusty