In case somebody is interested, I came across one reason for the internet connection to permanently freeze at WebRequest.GetResponse and other similar socket calls.
Be carefull when doing internet calls from within different threads. It appears one of the internet connections can permanently hang (without raising an exception) if they try to access the Wifi interface at the same time.
I’ve now worked around it by using a semaphore (using lock(object)) when doing internet communications from different threads. This might be a known issue, but I could not find any mention of it in the community site.
This is a new one on me.
Do you have a small example that reproduces the problem?
Regards,
Mark
Unfortunately not. I’ll see what I can do.
However… what I did was to have the Netduino Maple Server’s broadcaster send out its IP address continuously (which runs on its own thread), and I had the app thread posting periodically to another server . It then happens that at undetermined intervals, the app post failed with a hard freeze at [WebRequest.GetResponse] (this is where the program stops when hitting break). I obviously tried the WebRequest timeouts setting to counter this, but it appears webrequest timeouts does not work once it crashed. I also changed the app to post using direct sockets instead, but it then froze at the call [socket.Poll].
The problem only cleared for both post techniques when I created a lock semaphore and had the app main thread and broadcaster thread negotiate access to their internet calls. I was able to change the code in Maple because I’m running its from its source code.
Regards
Heinrich
I’m not sure if this is related, but wanted to mention in case helpful: I encountered an issue w/ the N3E that would crash our network - not the board - the entire network! I have Wi-Fi in my home, but also ethernet-over-power (not PoE) for the areas where I need wired connections. My entire office’s wired network would get taken down regularly during my N3E dev sessions - and to be clear, it’s only ever done this a handful of times over the span of a decade plus prior to the N3E - whereas it would get flooded/overwhelmed/unusable regularly while the N3E was plugged in, and healed/stayed up flawlessly when the N3E was unplugged…! 
