investigate unresponsive app when there's no Internet #268

fkooman commented 2025年05月26日 22:42:40 +02:00

See #266.

It is a bit erratic but IF it becomes responsive again it is between 30s and 2 min - but the bigger problem is that often the window becomes completely unresponsive to mouse and keyboard input even after the timeout is reached and switched to the input dialog...

See #266. > It is a bit erratic but IF it becomes responsive again it is between 30s and 2 min - but the bigger problem is that often the window becomes completely unresponsive to mouse and keyboard input even after the timeout is reached and switched to the input dialog...

fkooman commented 2025年05月27日 09:48:14 +02:00

I tried (unsuccessful) to reproduce this:

1. Modify Windows firewall to block all traffic to the IPs associated with disco.eduvpn.org
2. Modify the Fritz!Box to block traffic to those IPs

Both don't work as it seems with the Windows firewall the traffic gets rejected and not dropped, i.e. the rejection is immediate and so the apps gives up right away instead of triggering a timeout.

The Fritz!Box unfortunately does NOT support blocking traffic to IPs.

So my next option would be (I guess) to get an OpenWRT box where I can control everything and put the Windows machine on its WiFi and test like that...

I tried (unsuccessful) to reproduce this: 1. Modify Windows firewall to block all traffic to the IPs associated with `disco.eduvpn.org` 2. Modify the Fritz!Box to block traffic to those IPs Both don't work as it *seems* with the Windows firewall the traffic gets *rejected* and not *dropped*, i.e. the rejection is immediate and so the apps gives up right away instead of triggering a timeout. The Fritz!Box unfortunately does NOT support blocking traffic *to* IPs. So my next option would be (I guess) to get an OpenWRT box where I can control everything and put the Windows machine on its WiFi and test like that...

fkooman commented 2025年05月27日 10:51:29 +02:00

I managed to set up an OpenWRT WiFi network and can somewhat reproduce it. It is not (yet) clear if the auto update check (of the app) could also be the problem when starting the app. That is also why it may not always be triggered?

Starting eduVPN app now reliably hangs for ~10 seconds before connecting to the previously configured server when starting the app. My app is set to German so it says that "something will take a couple of seconds".

Adding a server doesn't work. It doesn't lock up the UI here, but it also doesn't allow you to add servers without being able to reach the CDN. There should a list of servers "built-in" so it doesn't actually require the network to show them. Obviously this list only contains the servers that were there when the app was released (or if it was able to update the list at some point that list).

I am testing with app version 4.3.99.1.

I managed to set up an OpenWRT WiFi network and can somewhat reproduce it. It is not (yet) clear if the auto update check (of the app) could also be the problem when starting the app. That is also why it may not always be triggered? Starting eduVPN app now reliably hangs for ~10 seconds before connecting to the previously configured server when starting the app. My app is set to German so it says that "something will take a couple of seconds". Adding a server doesn't work. It doesn't lock up the UI here, but it also doesn't allow you to add servers without being able to reach the CDN. There should a list of servers "built-in" so it doesn't actually require the network to show them. Obviously this list only contains the servers that were there when the app was released (or if it was able to update the list at some point *that* list). I am testing with app version 4.3.99.1.

rozmansi commented 2025年07月25日 15:04:30 +02:00

@fkooman wrote in #268 (comment):

I managed to set up an OpenWRT WiFi network and can somewhat reproduce it. It is not (yet) clear if the auto update check (of the app) could also be the problem when starting the app. That is also why it may not always be triggered?

Self-update is spawned in a background thread and has no effect on UI other than displaying an error note on About page, should it fail.

Starting eduVPN app now reliably hangs for ~10 seconds before connecting to the previously configured server when starting the app. My app is set to German so it says that "something will take a couple of seconds".

OK, "hangs" is a strong word. 😅 The UI stays on a generic waiting page because it is doing something in the background. The wording "This might take a couple of seconds" was inspired by big-tech corporations always-overoptimistic progress messages. What the client is really doing is trying to get the profile configuration from the server it is reconnecting on startup. It eventually times out. The really confusing thing was, the error message was hard-coded to report the client "needs to reauthorize". I have upgraded the client to display the true exception message now:

image

Adding a server doesn't work. It doesn't lock up the UI here, but it also doesn't allow you to add servers without being able to reach the CDN. There should a list of servers "built-in" so it doesn't actually require the network to show them. Obviously this list only contains the servers that were there when the app was released (or if it was able to update the list at some point that list).

The search works instantly for manually entered servers (hostnames containing at least three dots "."). It also kind-of-works for searching organizations for Secure Internet:

image

The DiscoOrganizations() in eduvpn_common.dll triggers discovery once, and it takes about 10 seconds before it reverts to returning search results based on cached/built-in disco data. The DiscoServers() however panics after 10 seconds and returns an error. So, maybe @jwijenbergh could take a look?

@fkooman wrote in https://codeberg.org/eduVPN/windows/issues/268#issuecomment-4882020: > I managed to set up an OpenWRT WiFi network and can somewhat reproduce it. It is not (yet) clear if the auto update check (of the app) could also be the problem when starting the app. That is also why it may not always be triggered? Self-update is spawned in a background thread and has no effect on UI other than displaying an error note on About page, should it fail. > Starting eduVPN app now reliably hangs for ~10 seconds before connecting to the previously configured server when starting the app. My app is set to German so it says that "something will take a couple of seconds". OK, "hangs" is a strong word. 😅 The UI stays on a generic waiting page because it is doing something in the background. The wording "This might take a couple of seconds" was inspired by big-tech corporations always-overoptimistic progress messages. What the client is really doing is trying to get the profile configuration from the server it is reconnecting on startup. It eventually times out. The really confusing thing was, the error message was hard-coded to report the client "needs to reauthorize". I have upgraded the client to display the true exception message now:  > Adding a server doesn't work. It doesn't lock up the UI here, but it also doesn't allow you to add servers without being able to reach the CDN. There should a list of servers "built-in" so it doesn't actually require the network to show them. Obviously this list only contains the servers that were there when the app was released (or if it was able to update the list at some point _that_ list). The search works instantly for manually entered servers (hostnames containing at least three dots "."). It also kind-of-works for searching organizations for Secure Internet:  The `DiscoOrganizations()` in `eduvpn_common.dll` triggers discovery once, and it takes about 10 seconds before it reverts to returning search results based on cached/built-in disco data. The `DiscoServers()` however panics after 10 seconds and returns an error. So, maybe @jwijenbergh could take a look?

rozmansi commented 2025年07月25日 15:18:04 +02:00

When Institute Access or Secure Internet servers are pre-configured using the registry, the DiscoServers() and DiscoOrganizations() are called initially to populate the UI correctly. Again: those two calls block for about 10 seconds. The DiscoServers() errors after that, the DiscoOrganizations() returns cached data.

So, I assume this was the case described in #266.

When Institute Access or Secure Internet servers are pre-configured using the registry, the `DiscoServers()` and `DiscoOrganizations()` are called initially to populate the UI correctly. Again: those two calls block for about 10 seconds. The `DiscoServers()` errors after that, the `DiscoOrganizations()` returns cached data. So, I assume this was the case described in #266.

rozmansi commented 2025年08月06日 14:42:27 +02:00

https://codeberg.org/eduVPN/windows/releases/tag/4.4.99.3 should work much better offline now.

https://codeberg.org/eduVPN/windows/releases/tag/4.4.99.3 should work much better offline now.

Lukas-UAUX commented 2026年05月18日 18:28:05 +02:00

As we still have this issue with the complete lockup with 4.5 - did this change land in the released Version? Or was it on "waiting for response"?

As we still have this issue with the complete lockup with 4.5 - did this change land in the released Version? Or was it on "waiting for response"?

Lukas-UAUX commented 2026年05月18日 18:55:50 +02:00

(See attached video snippet) - Hint: our server is Pre-Configured via registry InstituteAccessServers

(See attached video snippet) - Hint: our server is Pre-Configured via registry InstituteAccessServers

rozmansi commented 2026年05月20日 11:37:13 +02:00

Confirming there is a client stall on start when computer is offline and InstituteAccessServers is in place.

Confirming there is a client stall on start when computer is offline and InstituteAccessServers is in place.

Lukas-UAUX commented 2026年05月20日 14:50:39 +02:00

I tried analyzing the connections with the sysinternals process explorer - but the picture is so weird that i am unsure if process explorer actually displays real connections.

While starting the client supposedly connects to around a dozent IPs and sites like stuff from Akamai and so on - the only thing i could think of is that this may part of the WebViewe implementation (if there is even any)...

Wireshark is sadly so full of other spam that connects that i can not filter out what comes from the client...

We did even try allowing disco.eduvpn.org - but that also does not seem to do the trick...

I tried analyzing the connections with the sysinternals process explorer - but the picture is so weird that i am unsure if process explorer actually displays real connections. While starting the client supposedly connects to around a dozent IPs and sites like stuff from Akamai and so on - the only thing i could think of is that this may part of the WebViewe implementation (if there is even any)... Wireshark is sadly so full of other spam that connects that i can not filter out what comes from the client... We did even try allowing disco.eduvpn.org - but that also does not seem to do the trick...

rozmansi commented 2026年05月20日 18:32:56 +02:00

@rozmansi wrote in #268 (comment):

Confirming there is a client stall on start when computer is offline and InstituteAccessServers is in place.

Correction: A broken** InstituteAccessServers in place blocks the client from starting. This was a separate bug, also having a fix for it in the pipeline now.

** invalid URI, or URI not starting with https://.

@Lukas-UAUX wrote in #268 (comment):

While starting the client supposedly connects to around a dozent IPs and sites like stuff from Akamai and so on - the only thing i could think of is that this may part of the WebViewe implementation (if there is even any)...

Now, this sheds some light what might be the issue here... The .NET Framework appears to verify Authenticode signatures of the dependent assemblies really thoroughly. Trying to download CRLs to do the revocation check. I have turned this off now and planning to make a release tommorrow. Have some other commits in the queue that need testing first.

Thanks for reporting this!

@rozmansi wrote in https://codeberg.org/eduVPN/windows/issues/268#issuecomment-15401447: > Confirming there is a client stall on start when computer is offline and InstituteAccessServers is in place. Correction: A broken** InstituteAccessServers in place blocks the client from starting. This was a separate bug, also having a fix for it in the pipeline now. ** invalid URI, or URI not starting with `https://`. @Lukas-UAUX wrote in https://codeberg.org/eduVPN/windows/issues/268#issuecomment-15407924: > While starting the client supposedly connects to around a dozent IPs and sites like stuff from Akamai and so on - the only thing i could think of is that this may part of the WebViewe implementation (if there is even any)... Now, this sheds some light what might be the issue here... The .NET Framework appears to verify Authenticode signatures of the dependent assemblies really thoroughly. Trying to download CRLs to do the revocation check. I have turned this off now and planning to make a release tommorrow. Have some other commits in the queue that need testing first. Thanks for reporting this!

Lukas-UAUX commented 2026年05月20日 18:41:37 +02:00

Yeah i did already fall into that trap with the InstituteAccessServers onece before ;-)

But the other thing sounds promissing - i did think of CRLs too (only in verifying disco.eduvpn.org and app.eduvpn,org) but the URLs were so random so i was not sure...

Yeah i did already fall into that trap with the InstituteAccessServers onece before ;-) But the other thing sounds promissing - i did think of CRLs too (only in verifying disco.eduvpn.org and app.eduvpn,org) but the URLs were so random so i was not sure...

rozmansi commented 2026年05月21日 11:45:37 +02:00

I've made a release that disables revocation checks: https://codeberg.org/eduVPN/windows/releases/tag/4.5.99.4

@Lukas-UAUX, can you test it, please?

I've made a release that disables revocation checks: https://codeberg.org/eduVPN/windows/releases/tag/4.5.99.4 @Lukas-UAUX, can you test it, please?

Lukas-UAUX commented 2026年05月21日 14:15:32 +02:00

This looks very good - our testers reported it now opens instantly and till now no lockup anymore...

This looks very good - our testers reported it now opens instantly and till now no lockup anymore...