25 replies to this topic

[Valkyrie-MT]

Update: This bug was fixed in the Framework and the first firmware release to incorporate the fix will be 4.2 RC3.

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

[Robert L.]

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

[ColinR]

I am getting intermittent results. Sometimes my program hangs trying to look up a DNS entry

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.

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.

[Robert L.]

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);

[Tom S]

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.

[Chris Walker]

Hi Tom,

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.

Ooh, that's great info! Would you please add that to the CodePlex bug report?
http://netmf.codeple...m/workitem/1181

Also...welcome to the Netduino community!

Chris

[Valkyrie-MT]

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

[Valkyrie-MT]

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

[Chris Walker]

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.

[ColinR]

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?

[Valkyrie-MT]

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

[ColinR]

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.

[Michel Tol]

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

[Dan T]

I think Secret Labs was "Testing" the RC2 firmware for so long they decided to skip it and wait for formal release of official 4.2 - due any day now. Firmware with a useful life of only a few weeks and little chance of impacting the release would have been wasteful for all of us. Chris will correct me if I'm wrong.

[Chris Walker]

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

[Scott Green]

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...

[Michel Tol]

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?

[erich]

I am using RC2 and it hangs everytime on Socket.connect() :-(

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

[Chris Walker]

The "RC3" will be published within a few days of .NET MF 4.2 going gold (RTM). Microsoft scheduled their release for two weeks ago, so very soon Chris

[dmelliott]

Any news on RC2 chris? Thanks David