The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
I've run across some strange behavior with the ND+ and the RC4 firmware. If the ethernet port is not active when the ND+ boots up, it never recovers.
To recreate what I'm describing:
Start with the ND+ powered on with the ethernet cable connected. If it matters, my Netduino is configured with a static IP and DNS servers.
On a separate computer, start a continuous ping to the Netduino. Pings should be successful.
Unplug the ethernet cable.
Reboot the ND+.
After a few seconds, plug in the ethernet cable.
Note that all 3 lights turn on.
Note that the pings started failing as soon as the cable was unplugged (expected).
Wait several minutes, but the pings will continue to fail.
Reboot the ND+. Note that the pings now begin succeeding.
I used MFDeploy to capture a bootup sequence with the ethernet cable unplugged (steps 4 through 8) and captured the following:
[9:59:36 AM 2/19/2012] DM9161_DSCSR = 0xF200
[9:59:36 AM 2/19/2012] DM9161_BMCR = 0x3100
[9:59:36 AM 2/19/2012] DM9161_DSCR = 0x414
[9:59:36 AM 2/19/2012] Error: AutoNegotiate TimeOut
[9:59:36 AM 2/19/2012] PHY AutoNegotiate ERROR!
[9:59:36 AM 2/19/2012] ip address from interface info: 192.168.0.104
[9:59:36 AM 2/19/2012] SSL initialize failed!
[9:59:36 AM 2/19/2012] .NetMF v4.2.0.0
[9:59:36 AM 2/19/2012] NetduinoPlus, Build Date:
[9:59:36 AM 2/19/2012] Feb 2 2012 09:38:00
[9:59:36 AM 2/19/2012] ARM Compiler version 410713
[9:59:36 AM 2/19/2012]
[9:59:36 AM 2/19/2012] TinyCLR (Build 4.2.0.0)
[9:59:37 AM 2/19/2012] Starting...
[9:59:37 AM 2/19/2012] Found debugger!
[9:59:37 AM 2/19/2012] Create TS.
[9:59:37 AM 2/19/2012] Loading start at 155b88, end 16e8e0
[9:59:37 AM 2/19/2012] Attaching file.
[9:59:37 AM 2/19/2012] Attaching file.
[9:59:37 AM 2/19/2012] Attaching file.
[9:59:37 AM 2/19/2012] Attaching file.
[9:59:37 AM 2/19/2012] Attaching file.
[9:59:37 AM 2/19/2012] Attaching file.
[9:59:37 AM 2/19/2012] Attaching file.
[9:59:37 AM 2/19/2012] Attaching file.
[9:59:37 AM 2/19/2012] Attaching file.
[9:59:37 AM 2/19/2012] Attaching file.
[9:59:37 AM 2/19/2012] Attaching file.
[9:59:37 AM 2/19/2012] Attaching file.
[9:59:37 AM 2/19/2012] Loading Deployment Assemblies.
[9:59:37 AM 2/19/2012] Attaching deployed file.
[9:59:37 AM 2/19/2012] Attaching deployed file.
[9:59:37 AM 2/19/2012] Resolving.
[9:59:37 AM 2/19/2012] Ready.
[9:59:39 AM 2/19/2012] IP Address: 192.168.0.104
[9:59:39 AM 2/19/2012] Setting Date and Time from Network
[9:59:44 AM 2/19/2012]
[9:59:44 AM 2/19/2012] Link Update:
[9:59:44 AM 2/19/2012] IP: 192.168.0.104
[9:59:44 AM 2/19/2012] GW: 192.168.0.1
[10:00:12 AM 2/19/2012] LWIP Assertion "DNS response for wrong host name" failed at line 1251 in C:\MicroFrameworkPK_v4_2\DeviceCode\pal\lwip\lwip_1_3_2\src\api\api_msg.c
[10:00:41 AM 2/19/2012] LWIP Assertion "DNS response for wrong host name" failed at line 1251 in C:\MicroFrameworkPK_v4_2\DeviceCode\pal\lwip\lwip_1_3_2\src\api\api_msg.c
[10:01:09 AM 2/19/2012] LWIP Assertion "DNS response for wrong host name" failed at line 1251 in C:\MicroFrameworkPK_v4_2\DeviceCode\pal\lwip\lwip_1_3_2\src\api\api_msg.c
[10:02:20 AM 2/19/2012] LWIP Assertion "DNS response for wrong host name" failed at line 1251 in C:\MicroFrameworkPK_v4_2\DeviceCode\pal\lwip\lwip_1_3_2\src\api\api_msg.c
You can see at 9:59:36, it fails to negotiate the ethernet link. Expected (it was unplugged). At 9:59:37, the bootup cycle finished and my application started running. My app logged the messages at 9:59:39 (current IP address and starts trying to query NTP server).
At 9:59:44 the ND+ itself knew that I had plugged in the cable ("link update"). However, pings never responded. And the DNS lookups built into the NTP code fail.
I thought this was a known issue. I remember seeing a reference in the latest 4.2 firmware that says ethernet can not be plugged in at any time and is no longer required to be connected at boot-up. If I am remembering correctly, this means the 4.1 releases require the connection at boot time.
EDIT:
Oops, I didn't realize the latest 4.2 was up to RC4 and since I didn't see an explicit version mentioned, I assumed you were using 4.1 - looking at the error more closely I see you are using 4.2.0.0. Looking over the 4.2 RC4 features and sure enough that's where the first mention of plugging in the ethernet at any time is mentioned.
This firmware also includes the following previous updates:
... 5. Network cable may now be plugged in at any time
I thought this was a known issue. I remember seeing a reference in the latest 4.2 firmware that says ethernet can not be plugged in at any time and is no longer required to be connected at boot-up. If I am remembering correctly, this means the 4.1 releases require the connection at boot time.
EDIT:
Oops, I didn't realize the latest 4.2 was up to RC4 and since I didn't see an explicit version mentioned, I assumed you were using 4.1 - looking at the error more closely I see you are using 4.2.0.0. Looking over the 4.2 RC4 features and sure enough that's where the first mention of plugging in the ethernet at any time is mentioned.
Sorry, I should have clarified - I am on RC4. The RC4 wasn't the first time it showed up in the release notes. Looking at the RC3 post, it also includes the same text about being able to plug it in any time (http://forums.netdui...3-all-editions/).
I'm running 4.1.0.6 and I use a relay to switch a high powered wireless 3g router on and off as required. My N+ uses DHCP and happily alternates between having the addresses 10.0.0.1 and 10.0.0.2
I've just upgraded my SDK to 4.2-QFE1 and have ND firmware 4.2 RC4 on a couple of ND+ and can confirm that ethernet connections still do not recover if the cable is connected AFTER application startup. This happens with both DHCP and static IP, and the MFdeploy debug output shows that the ND+ is detecting the cable removal/insertion.
This is a bit of a setback since I was hoping to be able to use ethernet for an application where the system would need to tolerate cable disconnections.
On the plus side there's a slight improvement, because ND+ firmware 4.2RC3 would actually lock up at socket.connect() after reconnecting the cable if it was not connected during boot. 4.2RC4 seems to continue working, although the timeout for a socket connection attempt is quite long if the cable is absent during boot.
After further investigation, I've discovered another ethernet issue - probably related. If Netduino's internet connection is lost during normal operation but its ethernet connection is still OK, then connection attempts hang but don't seem to cause a total lockup. It does not seem to recover if the internet connection is restored.
I'm connecting the Netduino Plus (firmware 4.2 RC4) to an ethernet switch, and from there to a main router. I can't disconnect the internet/WAN side of the router so I havent tried that. I've tried with DHCP and static IP on the Netduino - same results.
If the Netduino's ethernet cable is plugged in and the switch is connected to the router (ie Netduino has a connection to the internet) then everything is fine.
If Netduino has an ethernet connection to the switch, but no internet access during boot, internet requests time out gracefully after 30 secs. If the internet connection is restored, Netduino discovers the connection after a few seconds and internet activity resumes as expected.
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.
Unplugging the Netduino ethernet cable in this state immediately triggers a link status update debug message, and the connection attempt immediately fails with an exception. Reconnecting the internet (switch-router cable) and Netduino ethernet cable allows internet connection attempts to succeed.
I too have also seen similar results with 4.2 RC4. Has this situation been addressed in RC5?
Chris, how is this handled gracefully by the companies that use the Netduino Plus as part of their commercial product? Surely a robust Ethernet connection is an absolute must?
Hi emg,
There are quite a few bugfixes, many related to networking, in the upcoming RC5 firmware (made in NETMF 4.2 QFE1). If this hasn't been addressed, let's open a bug report on it and try to debug it using a Netduino Go (where we enough flash to load a debug version of networking alongisde everything else).
Chris
Samjones, yeah I spotted your info about the network behaviour in your watchdog post http://forums.netdui...vailable-in-42/ but only a while after I posted here.
I hadn't tried disabling the internet connection but leaving ethernet connected until yesterday, but it looks like it was a problem before.
We have a messy workaround in the form of a timer event that triggers a reset after a period of network inactivity/failures, but it's not nice to be resetting the system every time the network connection drops.
Hopefully this will make it into the RC5 fixes. We'll be trying that whenever it's available.
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.
Outstanding work kluger! Please continue with RC4 on "B". The whole point to purchasing/using the Netduino+ was for it's ethernet port. If that is not rock solid and robust (or at the very least reliably recoverable) it makes it pretty much a 'toy' and difficult/impossible to use for any serious application.
Kluger's work explains why I've had no trouble: my code starts the router and then idles. It is the network availability event that causes my code to attempt to connect a socket. And therein, I suppose, lies a reasonable workaround: don't try to use the network until it is ready.
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.
This is in fact the same problem I encountered and created this about. I only have one Netduino, but if that Netduino is unplugged on bootup, it is done. It cannot use the network (until the network connection is restored and it is then rebooted).
I've done no intentional testing with losing the connection at runtime, so I cannot say I replicated those scenarios.
I'm anxiously waiting for RC5 to see how much of this is fixed. Chris referenced multiple bufixes related to networking in post #9 above, so I'm hoping that resolves this.
The whole point to purchasing/using the Netduino+ was for it's ethernet port. If that is not rock solid and robust (or at the very least reliably recoverable) it makes it pretty much a 'toy' and difficult/impossible to use for any serious application.
Kluger's work explains why I've had no trouble: my code starts the router and then idles. It is the network availability event that causes my code to attempt to connect a socket. And therein, I suppose, lies a reasonable workaround: don't try to use the network until it is ready.
Arbiter,
I almost follow you.... but not quite!
How do you test:
a) For physical connection (e.g. that enet port is plugged into a powered up hub)
and
For ip connectivity to the net
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.
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?)