Ethernet stop working after around 20-60 minutes running
#1
Posted 27 July 2011 - 01:37 AM
#2
Posted 27 July 2011 - 03:04 AM
#3
Posted 09 August 2011 - 01:13 AM
#4
Posted 08 November 2011 - 11:59 PM
Hi Chris,
I tried running a simple webpage polling app as you suggested, and I had the same result. I also tried putting a different network switch down right by the Netduino, but it didn't make any difference. I was able to get it running reliably by keeping it off of our network and connecting it directly to a PC using a crossover cable.
I'd need to do some more testing to be positive, but it really seems like the ambient broadcast traffic on our network causes the network stack to fall down after running for a relatively short period of time. I have another Netduino Plus on order, and I'll see if I can use it to get some more definitive troubleshooting information. I'd like to get it working reliably on our network for some other projects I have in mind.
Thanks for the help, Chris.
I can confirm this bug.
Netduino will stay up for days on a quiet, local LAN. If I take it and plug it into our university's LAN, it freezes within minutes. The board remains responsive to input pin events, but the network connectivity no longer works until you press the reset button.
It seems the Netduino's stack can't handle tons of broadcast traffic created by management services on large lans. (Cisco proprietary, or STP, etc.)
A potential work around would be to put a cheap nat router between the netduino and lan, and port forward 80 on the wan side ip to the netduino. That should block all of the broadcast noise, but let in the http requests.
#5
Posted 11 November 2011 - 07:58 PM
I can confirm this bug.
Netduino will stay up for days on a quiet, local LAN. If I take it and plug it into our university's LAN, it freezes within minutes. The board remains responsive to input pin events, but the network connectivity no longer works until you press the reset button.
It seems the Netduino's stack can't handle tons of broadcast traffic created by management services on large lans. (Cisco proprietary, or STP, etc.)
Exact same behavior in my university, after few seconds of our typical 30-45KB/s background broadcast noise, while it worked fine for weeks at home with low traffic.
A potentials work around would be to put a cheap nat router between the netduino and lan, and port forward 80 on the wan side ip to the netduino. That should block all of the broadcast noise, but let in the http requests.
But this kill the beauty of a tiny electronic to connect something to internet. If an additional router was requited, then is better and far cheaper to buy an OpenWRT compliant router such as Linksys 54G for 60€ and program it in C
I would be just happy if it would be a way to reset the eth interface when N+ detect lose of network connectivity
#6
Posted 12 November 2011 - 03:52 PM
I would be just happy if it would be a way to reset the eth interface when N+ detect lose of network connectivity
I used an external watchdog timer chip to overcome the occasional lockups by the Netduino Plus. On a quiet LAN, it will still lockup, just not as often. In my most recent test, it ran for 2 days before locking up.
#7
Posted 12 November 2011 - 04:00 PM
#8
Posted 13 November 2011 - 09:12 PM
Could you please post this as a bug report at netmf.codeplex.com? Perhaps there are network settings (buffers, sockets, etc.) that could be changed in the .NET MF PK to be able to discard extra traffic?
Generally with microcontrollers running software network stacks, broadcasting a lot of messages at them can cause a denial-of-service type of issue...as they simply can't keep up with processing it all.
Chris
I don't have enough details yet. I'll try to find the time to setup a hub in one of our campus labs and get some wireshark data.
#9
Posted 13 November 2011 - 09:13 PM
I used an external watchdog timer chip to overcome the occasional lockups by the Netduino Plus. On a quiet LAN, it will still lockup, just not as often. In my most recent test, it ran for 2 days before locking up.
Hi. Can you elaborate? I don't know how a watchdog chip could monitor just ethernet response issues? The board's logic, input pins, etc, remains responsive.
#10
Posted 08 December 2011 - 11:17 AM
#11
Posted 08 December 2011 - 05:57 PM
Do you have Wireshark? Can you capture this negotation attempt and then post it as a bug report at netmf.codeplex.com (and copy the link here so we can all take a look at it)?I have the very same problem with my NETduino Plus. It seems that Ethernet link establishment negotiation with a Switch/Router (I have 100Mbs) does not succeed for some reason and NETduino tries and tries it repeatedly. That is why IP over Ethernet does not work either. It is strange that flashing between different firmware versions did not help. I have also updated the bootloader with SAM-BA but Ethernet connectivity remains dead.
Netduino uses the industry-standard lwIP networking stack build into NETMF and used by many products...but part of open source is finding these types of glitches and then contributing to the core libraries. I know that lwIP has been used quite widely in the real world, but I'm sure that there will be issues to work out due to the large number of IP implementations. Let's see if we can get this one sorted out.
Chris
#12
Posted 08 December 2011 - 07:54 PM
#13
Posted 08 December 2011 - 08:17 PM
I studied the NETduino HW a bit and found that DM9161A chip performs autonegotiation for Ethernet link establishment autonomously.
I'm wondering if maybe you've come across something that has always plagued systems. I know in the windows world auto negotiation has always been problem some for devices and I have worked with network technicians who have recommended that it be turned off.
Maybe we should look at adding the capability to set the port speed on the Netduino Plus. If the network folks are having people turn it off, maybe we need to provide similar capabilities to allow the device to coexist with all of the other devices on the network.
http://diybrewery.com
#14
Posted 09 December 2011 - 09:54 AM
Yes, I agree and think that a capability for "manual" Ethernet PHY settings would add the overall reliability in the critical applications in general.Maybe we should look at adding the capability to set the port speed on the Netduino Plus. If the network folks are having people turn it off, maybe we need to provide similar capabilities to allow the device to coexist with all of the other devices on the network.
In my opinion the selection between using DHCP or fixed IP addresses/network settings tackles something similar but residing on the upper layers of the protocol stack.
Best Regards,
Seppo
#15
Posted 14 December 2011 - 09:09 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users