Misfit not reporting completed tasks

[De Wandelaar]

Same problem, Windows update not yet done.

Problem started a few hours after PrimeNet server Maintenance.

[Madpoo]

Originally Posted by srow7

same. stopped working after server reboot a few days ago.

Unfortunately I know zero about Misfit and how it communicates - is it just automating the process of sending results to the manual upload page? It's not using the API, is it?

One thing that I can think of is that the maintenance and server reboot may have finally deprecated some of the old, insecure security protocols (TLS 1.0 and 1.1). If Misfit is using some old libraries that don't support TLS 1.2, I could see that being an issue.

[Flaukrotist]

Originally Posted by Madpoo

[...] is it just automating the process of sending results to the manual upload page? It's not using the API, is it?
[...] If Misfit is using some old libraries that don't support TLS 1.2, I could see that being an issue.

Of course, it is up to Scott to properly answer this. I don't know about the support of TLS 1.2 by Misfit, but a quick look into the source code of version 2.11 (the latest afaik) reveals that this endpoint is called with POST:

Originally Posted by MISFIT v2.11

string url = "https://www.mersenne.org/manual_result/misfit.php?uid=" + userID;

and the file contents are sent to that as multipart/form-data. I hope that this at least helps in checking if the problem is related to the server side.

(I hope, I am allowed to post these details here (without asking Scott for permission) as the source code is publicly available. If not, please tell me, correct me and delete this post if necessary.)

[Madpoo]

Originally Posted by Flaukrotist

Of course, it is up to Scott to properly answer this. I don't know about the support of TLS 1.2 by Misfit, but a quick look into the source code of version 2.11 (the latest afaik) reveals that this endpoint is called with POST:

and the file contents are sent to that as multipart/form-data. I hope that this at least helps in checking if the problem is related to the server side.

(I hope, I am allowed to post these details here (without asking Scott for permission) as the source code is publicly available. If not, please tell me, correct me and delete this post if necessary.)

Well, that's just posting form data to the web side of things - that's a specialized version of the manual result page, in essence, just for misfit usage.

It's calling https which is great and all, but the error message indicates it's some problem misfit itself is encountering during the connection. so it probably does come down to how exactly it's making that https request, like what web library is it using and does it support TLS 1.2.

I don't know if the server logs would show the failed connection attempts but I'll see. Okay, just checked, and I see a bunch of successful (200) POST connections to /manual_result/misfit.php - so that tells me it's connecting okay but then if the app is still encountering something else unexpected, I couldn't say what exactly. The logs don't capture the form data being POSTed, just the URL info.

[Flaukrotist]

Misfit is using the C# library HttpWebRequest for the request. A quick search revealed https://stackoverflow.com/questions/...-4-0-framework that (maybe dependent on the .NET version) TLS 1.2 must be explicitely enabled in the code and I cannot find any such line in the source code. So maybe (grasping straws) this is the path to the solution but needs action from Scott to fix it. I don't know what else would be affected by such a change. Also, maybe I am completely wrong here as I am relying on crude C# knowledge.

[Madpoo]

Originally Posted by Flaukrotist

Misfit is using the C# library HttpWebRequest for the request. A quick search revealed https://stackoverflow.com/questions/...-4-0-framework that (maybe dependent on the .NET version) TLS 1.2 must be explicitely enabled in the code and I cannot find any such line in the source code. So maybe (grasping straws) this is the path to the solution but needs action from Scott to fix it. I don't know what else would be affected by such a change. Also, maybe I am completely wrong here as I am relying on crude C# knowledge.

That would be unfortunate. On the server side, I could re-enable at least TLS 1.1 (definitely not 1.0 though) and it would require a server reboot.

Ideally someone familiar with misfit and its creation could look at the TLS 1.2 possibility and do a test to see if that's even the issue, and then people would have some window of time in which to upgrade their misfit before we purposefully disable TLS 1.1.

And I don't even know if that's the issue, but besides the typical Microsoft patches, that is something that changed. We actually changed the TLS 1.0/1.1 support a long time back but had to revert in order to make sure PHP and SQL were talking to each other okay. We got that fixed and I probably just forgot that I'd made the registry changes to re-disable (is that a thing?) those old protocols, which took effect when it finally rebooted.

That's what happens when we go 6 months between reboots - I forget things like that.

[Madpoo]

Originally Posted by Flaukrotist

Misfit is using the C# library HttpWebRequest for the request. A quick search revealed https://stackoverflow.com/questions/...-4-0-framework that (maybe dependent on the .NET version) TLS 1.2 must be explicitely enabled in the code and I cannot find any such line in the source code. So maybe (grasping straws) this is the path to the solution but needs action from Scott to fix it. I don't know what else would be affected by such a change. Also, maybe I am completely wrong here as I am relying on crude C# knowledge.

Reading more through that thread, and following up, it sure does seem like .NET Framework 4.0 does not support TLS 1.1 even. If that's how misfit is compiled, then we have a problem. (EDIT: the fix is to up it to 4.5 at least)

That would mean Misfit required TLS 1.0 on the server in order to work, and due to the many security implications of TLS 1.0, I would be very hesitant to add that back in.

But maybe it's not using .net framework calls? I didn't really look at misfit's source code even though I downloaded it and did a cursory look (which meant searching for "tls", which were all related to smtp, so hey, it has that at least).

[Flaukrotist]

Originally Posted by Madpoo

Reading more through that thread, and following up, it sure does seem like .NET Framework 4.0 does not support TLS 1.1 even. If that's how misfit is compiled, then we have a problem. (EDIT: the fix is to up it to 4.5 at least)

A small update: From the .csproj file in the source code, I read the TargetFrameworkVersion is .NET Framework 4.0 which would support your fear.

I separated the file uploading function into a new C# project using .NET 5.0 and feeding it one of the staged files from my Misfit folder. It worked like a charm with the endpoint. No connection abortions, no errors, but just the result text from the manual upload page that one can see in the communication logs of Misfit when it succeeded. So for this extracted scenario, a compilation using .NET 5.0 might do the trick, also with TLS 1.2 which I suspect was still enabled when I tested at 9/7/21, 9 pm UTC. Unfortunately, I couldn't try the same function using .NET framework 4.0 to see if it fails there. And I will most likely not have time for that during the weekend.

I don't know if that recompilation would be the solution or if it breaks other things then.
(If you are looking for the function I talk about: It is in WebIO.cs, UploadResultsFileToGIMPS() )

[Madpoo]

Originally Posted by Flaukrotist

A small update: From the .csproj file in the source code, I read the TargetFrameworkVersion is .NET Framework 4.0 which would support your fear.

I separated the file uploading function into a new C# project using .NET 5.0 and feeding it one of the staged files from my Misfit folder. It worked like a charm with the endpoint. No connection abortions, no errors, but just the result text from the manual upload page that one can see in the communication logs of Misfit when it succeeded. So for this extracted scenario, a compilation using .NET 5.0 might do the trick, also with TLS 1.2 which I suspect was still enabled when I tested at 9/7/21, 9 pm UTC. Unfortunately, I couldn't try the same function using .NET framework 4.0 to see if it fails there. And I will most likely not have time for that during the weekend.

I don't know if that recompilation would be the solution or if it breaks other things then.
(If you are looking for the function I talk about: It is in WebIO.cs, UploadResultsFileToGIMPS() )

That's a great test. I'd suggest that .NET 4.5 be targeted, if this were rolled up into a new compiled build. Reason being, most people are (probably?) going to have 4.5 installed on their Win10 boxes already, but 5.0+ would be an additional download & install. 5.0 is available for other OS's though so I guess that could play into it, making it possible to port it easily to Linux/Mac or whatever.

But that is definitely interesting. I did see that there's a way to make it work with Framework 4.0 by specifying the protocol # directly or something like that. LOL
EDIT: From here: TLS 1.2 in Framework 4.0

The server is still setup with just TLS 1.2 enabled - I was waiting 'til the weekend here to check with George and see if re-enabling 1.1 (and maybe 1.0 if Misfit needs it?) is something we'd want or need to do for the sake of the users. But most likely with a drop-dead date in the future of getting Misfit working with 1.2 and enough time for people to update.

[Madpoo]

I was reading more about this issue with Framework 4.0 apps and TLS 1.2 support.

If the machine has Framework 4.5+ installed, then it sounds like you can tell it to use TLS 1.2 by default with the addition/modification of a couple of registry keys. This avoids having to recompile an old app, since you're just telling your framework to use a stronger crypto by default.

If someone wants to try this out - just make sure your system does already have 4.5 installed. Windows 10 does, by default, so that should be fine. For older systems (Win7/8/8.1) just be sure to check.

From an admin command prompt (or add the keys to the registry yourself if you're so inclined):

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f

Those commands add the reg entries that will tell .NET Framework 4.x targeted apps to use stronger crypto by default. I saw conflicting info about whether you actually need Framework 4.6+ installed, or if 4.5 is good enough.

If getting 4.6+ installed and adding some reg keys does the trick, I'd be on board with just recommending that for any misfit users, over the downside of re-enabling the older protocol versions.

[1997rj7]

The registry entries seem to have fixed it for me.