2 replies to this topic

[Nobby]

Not sure if this is an issue or not but I'm looking at trying to get around a certain type of behaviour with the NIC. -If I boot/power up the device with the netduino connected to a switch/router everything is fine -If I boot/power up the device with the netduino initially unplugged, I run into issues. -Currently using static IP Plugging the device into a network after startup negotiates fine with the hardware. I cannot ping the netduino at its IP address though. I can ping it if I hit the reset button or re-power the netduino My software binds a listener which constantly throws socket exceptions when calling Socket.Accept() while it is disconnected(as expected). When the exception occurs, I close the listener, rebind the socket(using IPAddress.Any) and retry to called Socket.Accept(). When I plug the netdunio into a switch, the socket rebinds and stops throwing socket exceptions from calls to Accept(). I still can't ping the Netduino or make a TCP connection to the device unless I reboot/re-power the netduino with the network cable plugged into a switch. I've tried various things such as reseting the static IP settings once the netduino is plugged into a switch, before and after binding the listener to 0.0.0.0:portNum. Anyone else had similar behaviour?

[Nobby]

I saw this issue with an attached debugger in this thread http://forums.netdui...tartup-problem/ .

[Nobby]

I finally found some time to create analysis tools to investigate NIC behaviour. The initial results were fairly conclusive.

---Netduino Software---

A threaded socket listener accepting TCP connection requests. It's a non-blocking approach utilising Socket.Poll to check for pending connection requests before calling Socket.Accept. Detection of NIC being up or down is monitored using the WinSock socket exception code 10050. Once the network status is up, I tried two methods that involve either retaining the existing listening socket object or recreating the listening socket.

• Netduino is using static IP and gateway (192.168.1.95, 255.255.255.0, 192.168.1.1)
• Experiment involved starting a debugger on the netduino with the network cable plugged in or unplugged
• A separate thread does a Debug.Print of the current IP address and default gateway of the Netduino every three seconds

---PC Software---

A simple app which allows you to enter an ip address and port number. A "Connect" button which attempts to create a TCP connection to the remote host at the defined address and port. A "Ping" button which broadcasts an IMCP echo request to the defined address. All connection and ping results displayed in a listBox.

---Results---

Starting the debugger with the network cable initially plugged in produces positive results. The device is pingable and TCP connections can be made. Unplugging the device from the network results in WinSock 10050 exceptions on Socket.Poll as expected. Plugging the Netduino back into the network and recreating the listener socket resumes desirable behaviour. The device is pingable and TCP connections can be made.

Starting the debugger with the network cable initially unplugged is where it all goes wrong. The frequently displayed IP address of the Netduino is correct. After any length of time, the netduino is plugged in, all related link/activity etc lights come on. WinSock 10050 errors cease to occur when calling Socket.Poll as expected. However, the device is unpingable and TCP connections cannot be made to 192.168.1.95. No amount of time changes the conditions of connectivity without restarting the device.

Is anybody familiar with the inner workings of the .Net Microframework runtime startup in the Netduino and how NICs are affected by it? Fortunately, the only vulnerability of the product I'm developing is that it must be plugged in and active at both ends of the network cable before the product is powered up. I would like that to not be a requirement.

This thread http://forums.netdui...?showtopic=3420 alerted me that sometimes the Netduino needs to be rebooted. Is there any other functionality that isn't as brutal as a reboot?

I'm now using Socket.Poll to detect the initial NIC connection state and rebooting the device upon the NIC status changing to up, if it was originally down. I can't exactly do this if the product is in the middle of being used.