Error fetching data

[voidburn]

Can't find any logs, does anyone know what could cause this?

[knoxfighter]

That is something that happens too often for me to just leave it. Unfortunatly i still have no idea what is the cause of that error. Some information is shown in the normal arcpds log: <Guild Wars 2>/addons/arcdps/arcdps.log

[voidburn]

I assume you're interfacing with some remote HTTP API? Have you tried dumping the response headers/body to see whether they include a hint as to what's going on? Maybe there's a rate limiting issue, it seems to be completely random as to where it starts happening and/or starts working again.

[knoxfighter]

The format of that output is: username: -- httpCode -- response.
The actual error message can be found in the arcdps log: Status: 0 -- Response: -- ErrorMessage: schannel: next InitializeSecurityContext failed: SEC_E_INTERNAL_ERROR (0x80090304) -- Reason: -- StatusLine:
Unfortunatly i don't know what that error message means :(

[voidburn]

What library are you using to build the https requests? Smells like an SSL issue..

[voidburn]

SEC_E_INTERNAL_ERROR 0x80090304 | The Local Security Authority cannot be contacted

I guess your best bet is try asking the guys that made CPR and see if they can help. I checked their issues' page and there's no mention of this though.

You can always try using curl instead (doubt it has nicer APIs than Cpr though)

[knoxfighter]

The biggest problem i have is: I cannot reproduce it at all. Everybody has this error from time to time, mostly only once and after the retry it is gone again. I know of only two people that have this error all the time and for one it got fixed by itself :/

[voidburn]

It's been pretty consistent on mine lately, I'll try to dig into it.

[voidburn]

Ok, I cleaned up the logs and fired it up, my error turned out to be quite different:

schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) - The revocation function was unable to check revocation because the revocation server was offline.

With curl there is a flag to disable the revocation check, I'm looking into CPR to see if you can provide such configuration flag to the request. This is most likely due to their certificate authority (Let's Encrypt), which issues very short lasting certs (3 months). You should probably disable the revocation, but also the verification of the certificates in your client instance, this application is not mission critical, and I doubt any harm can come from someone attempting to impersonate the remote server to provide arbitrary data.

Check this out: https://whoshuu.github.io/cpr/advanced-usage.html#https-options (section "Verify SSL/TLS Certificate and Status") and disable all three checks. Connections will still be encrypted, but your client will effectively stop caring about the validity of the certificate, it could be self signed for all it cares.

I'm trying to understand why this happens, I bet there's some caching involved within windows that causes this to become a permanent issue until the cached data expires and for a period the certificate is validated once again.

I don't feel like installing visual studio and setup the dev env to compile the dll, I would appreciate if you could make a build with those options disabled and send a dll my way for testing!

[voidburn]

Tested with the strict SSL options off and, as expected, it works. Deploy at your discretion, I made myself a working dll.

cpr::SslOptions sslOpts = cpr::Ssl(cpr::ssl::VerifyPeer{ false }, cpr::ssl::VerifyHost{ false }, cpr::ssl::VerifyStatus{ false });
cpr::Response response = cpr::Get(cpr::Url{link}, cpr::Header{{"User-Agent", userAgent }}, sslOpts);

[hk3wx]

@voidburn can you link the working dll?
I'm not downloading VS just for this ;D

[voidburn]

Wait a bit and see if Knox decides to disable the certificates validation (I haven't tried but just the host verification turned off might be enough), I'd have to fork to upload a prebuilt binary, and like you I despise VS so I uninstalled those 9GB the moment I was done with building my version of the dll :D

[hk3wx]

OK.
Thank you anyway.

[knoxfighter]

I will not disable SSL checks, that would just make it useless... I still have no clue, what exactly is going on :(

[knoxfighter]

I have made some adjustments which could make it work correctly. Can you please test it once again (you can still downgrade, if it still doesn't work).

[voidburn]

I did, it still has the same problem.

I found a workaround though that (of my specific error, which is unlikely to be the one others reported to you). In order to allow the verification process to work I need to whitelist "Local Security Authority Process - C:\windows\system32\lsass.exe" in my application firewall. I guess CPR delegates to it.

This is the first time I've ever seen it being an issue. Maybe @hk3wx has a similar problem?

[voidburn]

By the way, I think it would be neat to have those 3 flags toggle-able via an ".ini" file auto generated on first run beside the ".dll" (pretty much like other addons do). On by default obviously, but at least people can decide themselves if no other solution works.

[knoxfighter]

I already have ini files, where i save my settings, so adding that is not that big of a task, i can surely do that :)

I found a workaround though that (of my specific error, which is unlikely to be the one others reported to you). In order to allow the verification process to work I need to whitelist "Local Security Authority Process - C:\windows\system32\lsass.exe" in my application firewall. I guess CPR delegates to it.

Do you use the standard windows defender firewall or something else?

[voidburn]

Netlimiter 4.

Still boggles my mind how that request is routed through that windows service out of process... If it was a direct Win32 API call this would've never happened since the Gw2 process was whitelisted.

[matteobosc]

Hi,

I have this issue too, in attachment you can find my full log. The issue started few days ago and it's persistent, I have latest builds for both arcdps and kpme addon. @voidburn can you explain how to whitelist that process? @knoxfighter tell me if you need more details

arcdps.log

[voidburn]

@matteobosc Your error is actually different than mine. If you're using a software firewall which is not Windows Firewall then simply whitelist the process I specified above to be able to connect to the internet. If you have such tool installed and you don't know how to do that, you probably should ask google for help, or try to disable it temporarily to see if it fixes the issue.

Another possibility is that your copy of Windows has not received updates for Certificate Authorities and therefore lacks the ability to validate.