UPDATE: Fixed for RC3 -- New Bug discovered in Socket.Connect Method!
#1
Posted 22 August 2011 - 04:58 AM
The Socket.Connect method appears to be completely broken in the 4.2 RC1 firmware.
VOTE HERE: http://netmf.codeple...m/workitem/1181
The issue was discovered by Christopher Gilmore and discussed here
Thanks,
-Valkyrie-MT
#2
Posted 25 August 2011 - 11:54 PM
The Socket.Connect method appears to be completely broken in the 4.2 RC1 firmware.
VOTE HERE: http://netmf.codeple...m/workitem/1181
The issue was discovered by Christopher Gilmore and discussed here
Thanks,
-Valkyrie-MT
I am getting intermittent results. Sometimes my program hangs trying to look up a DNS entry, but most usually it hangs when creating a Socket. On the other hand, it works fine nearly 90% of the time. When it does hang, I get no exception, it just never returns from the methods.
Robert
#3
Posted 26 August 2011 - 07:02 AM
I have worked around the DNS issue by looking up the DNS entry once (I presume we all are requesting the same url consistently) and just re-using it.I am getting intermittent results. Sometimes my program hangs trying to look up a DNS entry
but most usually it hangs when creating a Socket. On the other hand, it works fine nearly 90% of the time. When it does hang, I get no exception, it just never returns from the methods.
Likewise.
#4
Posted 26 August 2011 - 01:31 PM
I have worked around the DNS issue by looking up the DNS entry once (I presume we all are requesting the same url consistently) and just re-using it.
I have also moved the DNS lookup outside the loop, and so I have a lot less errors with that. The strange thing is that the failures seem dependent on the "build". For example, I had a version of my program that froze every time I ran it. Then I removed a blank from a literal string that I was "printing" using the Debug method. This Debug statement was not even called prior to the place the program locks up. But removing that one space char from the literal string and rebuilding, got the program running again. I guess that re-building with that tiny change moved things around in memory a bit. Perhaps the problem relates to the alignment of something in memory.
But to repeat, my program is locking up trying to *create* a socket, not trying to use it to connect. In my case, if the socket can be created, it always connects. Here is the line that freezes:
var connection = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
#5
Posted 26 August 2011 - 04:33 PM
#6
Posted 26 August 2011 - 07:48 PM
Ooh, that's great info! Would you please add that to the CodePlex bug report?This appears to be due to a failure in the connect. If the connect succeeds before the timeout (about 5 seconds, not setable), all is well. If the connect times out then the exception is not thrown and the the thread hangs.
http://netmf.codeple...m/workitem/1181
Also...welcome to the Netduino community!
Chris
#7
Posted 27 August 2011 - 12:30 AM
#8
Posted 30 August 2011 - 02:17 AM
Just noticed that ZachLibby of the Microsoft MicroFramework team reports this issue has been resolved. As soon as a changeset is available, I'll rebuild the firmware and confirm...
-Valkyrie-MT
The fix is in! About 2 hours ago ZachLibby published a new changeset and I have rebuilt a firmware with the changed socket code. It resolves the Socket.Connect issue in my build, so this is a very good indication.
THANKS to everyone who voted! We got up to 15 votes.
-Valkyrie-MT
#9
Posted 30 August 2011 - 05:04 AM
#10
Posted 31 August 2011 - 06:17 AM
It resolves the Socket.Connect issue in my build, so this is a very good indication.
Fantastic news! Thank you. Did it resolve the "Hold Down F5" Socket.Accept issue as well?
#11
Posted 31 August 2011 - 01:41 PM
Fantastic news! Thank you. Did it resolve the "Hold Down F5" Socket.Accept issue as well?
NO. It did not resolve that issue. I was able to crash my server by holding F5 as you mentioned and it was a bit disturbing. The sockets should connect up until the set backlog value (from Socket.Listen(int backlog)), then refuse all additional connections. Unfortunately, that's not what is happening. Basically, a DNoS attack would completely kill the Netduino because it seems to kill that socket and I am not able to recover it, yet. I just built a new firmware last night where I upped the MAX_SOCKETS to a fixed value of 100 and that appears to be an improvement. But, there is still the possibility of it crashing, just at a higher number of sockets... And I haven't looked to see what the memory implications of that are... What we really need is a unit test that reproduces this so we can submit an issue to the .NET MF team. Although, I suspect, we'll be too late to get it into 4.2.
If you want to try out my "extra sockets" firmware build, just send me a PM. Note: it's a 4.1 firmware, but uses the LWIP stack from the 4.2 firmware and has the UDP broadcast fixes.
-Valkyrie-MT
#12
Posted 31 August 2011 - 03:50 PM
NO. It did not resolve that issue. I was able to crash my server by holding F5 as you mentioned and it was a bit disturbing. The sockets should connect up until the set backlog value (from Socket.Listen(int backlog)), then refuse all additional connections. Unfortunately, that's not what is happening
I would not be concerned if it was only on F5 that I lose the listening socket. Would be great to test your firmware. PM on it's way, thanks.
#13
Posted 16 September 2011 - 09:08 AM
Thanks for the update, Valkyrie-MT. We're downloading the updated PK now!
We should have an updated (RC2) firmware release for Netduino Plus by the weekend.
Maybe a stupid question, but is the RC2 N+ firmware already released? Where can I download it from? I could only find the RC1.
tnx
michel
#14
Posted 16 September 2011 - 12:06 PM
#15
Posted 16 September 2011 - 04:46 PM
- Stavros Tekes likes this
#16
Posted 16 September 2011 - 04:58 PM
Michael, Dan:
You are precisely correct. The RTM was scheduled to ship on Monday of this week so we decided it wouldn't make sense to have an RC2 for a week only to replace it by the RTM version. Also, the new AnalogPort/AnalogInput class was still being changed post-RC2 and we wanted that to settle before we integrated in the SAM7X-specific code.
We're going to build an "RC3" firmware to match the .NET MF 4.2 firmware...to make sure that users don't experience any BSOD issues. This should be the first "release-quality" 4.2 firmware. From there, we'll take input from users and get things ready for an official 4.2 firmware release (and pull in the new PWM and AnalogInput objects). We may do a few RCs until the community tells us that we're good to go--but that process should go pretty quickly.
I'm excited about 4.2. In addition to VB support and GC bugfixes, there are also new features and networking enhancements. Thanks to the testing and feedback of the NETMF community, this will likely be the highest quality NETMF release to date.
Chris
Have they fixed the "unplug the USB / replug the USB" everytime you want to deploy bug?
Scott...
#17
Posted 18 September 2011 - 09:25 AM
Michael, Dan:
You are precisely correct. The RTM was scheduled to ship on Monday of this week so we decided it wouldn't make sense to have an RC2 for a week only to replace it by the RTM version. Also, the new AnalogPort/AnalogInput class was still being changed post-RC2 and we wanted that to settle before we integrated in the SAM7X-specific code.
We're going to build an "RC3" firmware to match the .NET MF 4.2 firmware...to make sure that users don't experience any BSOD issues. This should be the first "release-quality" 4.2 firmware. From there, we'll take input from users and get things ready for an official 4.2 firmware release (and pull in the new PWM and AnalogInput objects). We may do a few RCs until the community tells us that we're good to go--but that process should go pretty quickly.
I'm excited about 4.2. In addition to VB support and GC bugfixes, there are also new features and networking enhancements. Thanks to the testing and feedback of the NETMF community, this will likely be the highest quality NETMF release to date.
Chris
Chris, thanks for the update. Is there a 'rough' date for the 'RC3' release?
#18
Posted 27 September 2011 - 09:54 AM
Will this issue be fixed in RC3 - if so when?
Note the code runs ok on the MS Emulator.
My code is pretty identical to this
#19
Posted 27 September 2011 - 04:53 PM
#20
Posted 06 October 2011 - 10:53 AM
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users