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'm also having ethernet issues with the latest firmware. Although, I can't confirm if the issue exists with older versions. I discovered that the ethernet interface never works at all if a network connection doesn't exist on boot. I made a thread here:
There appears to be a bugfix in lwIP to correct this type of issue. .NET MF 4.3 is getting an lwIP upgrade, so we're hoping to have a fix for this soon. [lwIP is a big complicated project and 10,000s of boards rely on it working properly...so introducing the update in beta firmware should help it get some good in-field testing.]
I think you need to look to your router for DHCP issues and stop blaming Netduino for arcane problems. For ethernet connected or not,
you need a try-catch in your listener code in order to recover. Upon startup, in Main I am calling the NIST DayTime TCP client to set
the Netduino clock. Without an ethernet connection an exception is thrown. Catching it allows a graceful recovery.
The issue is:
If you do NOT enable DHCP in MFDeploy, and enable it on the NetworkInterface in code, the NetworkInterface will ALWAYS report a 0.0.0.0 as an IP, even though the device was given an IP from the DHCP server.
Got that? I don't think I can spell it any easier..
As was repeated in several posts now - Enabling DHCP in MFDeploy Works. That is not the problem.
There appears to be a bugfix in lwIP to correct this type of issue. .NET MF 4.3 is getting an lwIP upgrade, so we're hoping to have a fix for this soon.
Injteresting - does that mean you'll try to work any code-changes in before-hand, or should we just wait for MF 4.3?
There appears to be a bugfix in lwIP to correct this type of issue. .NET MF 4.3 is getting an lwIP upgrade, so we're hoping to have a fix for this soon. [lwIP is a big complicated project and 10,000s of boards rely on it working properly...so introducing the update in beta firmware should help it get some good in-field testing.]
I am using a cheap refurb Cisco-Linksys E2000 router running DD-WRT.
Then you are quite lucky, as i have had nopthing but grief with DD-WRT, but it really depends on the make model of you DHCP infrastructure. (Part of my job is networks, and i can say from first hand experience you can get DHCP issues using identical bits of kit, with the same firmware etc.)
I think you need to look to your router for DHCP issues and stop blaming Netduino for arcane problems. For ethernet connected or not,
you need a try-catch in your listener code in order to recover. Upon startup, in Main I am calling the NIST DayTime TCP client to set
the Netduino clock. Without an ethernet connection an exception is thrown. Catching it allows a graceful recovery.
This is a firmware issue, its not blaming a device when you report an error, by the same logic any one who had bsod's prior to 4.2 being released should have looked at their computer and wondered why that wasnt working properly with the netduino, personally i think natep has done an excellent job in documenting his findings and sharing them with the community. Yes you can (and should) code defensively, but that does not change the underlying problem of the networkinterface classes not reflecting the acquired ip address, and if you have a reliance on knowing your network configuration for your app no amount of try catching will help if the underlying data is wrong, as that is a data validation issue, not a runtime exception, and if you are using try catch blocks for validation or program flow you are doing it wrong and should consider investing the time in educating your self on data validation methodology.
This is a really good conversation to be having.
Networking enhancements is our #1 goal with the NETMF 4.3 upgrade.
With .NET MF 4.3 alpha/beta, we have the opportunity to get patches for any networking issues into the NETMF core. I'm saving this thread, and we should make sure to test and address these during the 4.3 release.
Chris
Networking enhancements is our #1 goal with the NETMF 4.3 upgrade.
With .NET MF 4.3 alpha/beta, we have the opportunity to get patches for any networking issues into the NETMF core. I'm saving this thread, and we should make sure to test and address these during the 4.3 release.
Chris
Hi Chris - An odd slightly off-topic question. Being new to the MF framework - what's the overall time cycle of releases? has it been one a year, or faster than that?
Networking enhancements is our #1 goal with the NETMF 4.3 upgrade.
With .NET MF 4.3 alpha/beta, we have the opportunity to get patches for any networking issues into the NETMF core. I'm saving this thread, and we should make sure to test and address these during the 4.3 release.
Chris
I think it has something to do with the intialisation of the netduino. I did a test and also always got ip address 0.0.0.0 back, UNLESS one of the first things I did in my Main() was a Thread.Sleep(5000). Then everything works as expected...
Maybe this helps for the 4.3 NETMF
Now Baxter, I can exactly tell you what is wrong.!
The Netduino will hang when you have a internet connection but after a while the IP provider stops the connection for a reason.
Do While True
Try
Debug.Print("begin " & DateTime.Now.ToString)
OnboardLed.Write(True)
Dim IPEndPoint As New IPEndPoint(Dns.GetHostEntry("api.pachube.com").AddressList(0), 80)
Using Host As Socket = New Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp)
Host.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.NoDelay, True)
Host.SendTimeout = 3000
Host.ReceiveTimeout = 1000
'WITH internet connection it wil run perfect, but now without internet (after you had a connection)'
' and still on the local network then..........'
Debug.Print("WHEN INTERNET connection fails after a time, than the NETDUINO HANG!!!!")
Host.Connect(IPEndPoint) 'It will hang here.!'
Debug.Print("Oké, stil connection")
End Using
Catch ex As Exception
Debug.Print("error " & ex.Message) 'no error will show here'
End Try
OnboardLed.Write(False)
Debug.Print("sleep")
Thread.Sleep(10000)
Loop
I have the exact same issue with my Netduino Plus 1. DHCP works fine as long as the ethernet cable is plugged in at boot, otherwise the IP is stuck at 0.0.0.0.
Any chance for a 4.3 beta release for the Netduino Plus 1?
With Netduino Plus 1, especially with the older firmware, I highly recommend plugging in the Ethernet cable before powering up your Netduino.
We have a link-detect fix around this for the upcoming 4.3.2 firmware on Netduino Plus 2, but we haven't been able to free up enough room in Netduino Plus 1's limited flash space to squeeze newer firmware onto it.