Since my HP EliteDesk 800 is not an option for me due to the problem with the Intel LAN connection for the eBlocker4, I switched to a new (used) thin client (Lenovo ThinkCentre M75n with Ryzen 3 Pro 3300U, 8GB and 128 GB SSD).
First, I used eBlocker3 on this hardware for three weeks to have a basis for comparison.
With eBlocker 4.0.2, I observed the following issues.
Threema: does not connect initially (red line). Only after briefly disabling HTTPS activation for the smartphone does the connection work and remain active with HTTPS activation until the next new network connection. Manual logging of the HTTPS connection did not result in any entries, and HTTPS connection errors were not displayed either.
Feeder: The preview images on the right side of the feeder are initially filled with placeholders only. The preview images appear gradually (20–40 seconds).
Tusky: Some of the preview images are displayed as placeholders only.
I hope my description is clear enough.
In general, I have the impression (compared to eBlocker3) that eBlocker4 is “sluggish.”
Thank you for the report!
That is strange: Threema on iOS works without any problems with my test eBlocker 4.0.3, but the Android app does not want to connect (red line).
I have enabled the Threema HTTPS exception list, so threema.ch and all its sub-domains are whitelisted.
There is a debug log option in Threema's settings at Settings / About Threema / Advanced Options / Logging. But the error is not really shown in the log:
INFO ThreemaApplication: ServerConnection state changed: CONNECTING INFO ServerConnection.CspSocket: Connecting to g-a0.0.threema.ch/203.56.112.204:443 ... INFO ProxyAwareSocketFactory: No proxy configured INFO ThreemaApplication: ServerConnection state changed: CONNECTED INFO ConnectionLock.PURGE_INCOMING_MESSAGE_QUEUE: Acquiring lock #76 with 60.00s timeout INFO ServerConnection.CspSocket: Reading stopped INFO ServerConnection.CspSocket: Writing stopped WARN ServerConnection.BaseSocket: IO processing stopped exceptionally java.io.EOFException...
The server (or the proxy on the eBlocker) just seems to close the connection.
I will have to do some network level debugging with Wireshark...
I have looked more into the issue with Threema on Android.
The issue occurs with both eOS 3.2.3 and 4.0.3.
Threema's chat server protocol is a custom binary protocol using the NaCl library.
The Threema app uses ports 5222 and 443 for chats. Port 443 is used as a work-around for outbound firewalls that block port 5222.
However, port 443 cannot work with eBlocker because the Threema chat protocol is not TLS. In this case whitelisting the threema.ch domain does not work, because splicing the connection (pass-through) on the eBlocker would require a TLS handshake with SNI (server name indication).
Port 5222 seems to work only if eBlocker is in individual network mode (DHCP on eBlocker). It seems that masquerading on the firewall is required (which is not enabled in automatic network mode).
So it seems the best strategy currently is to run eBlocker in individual network mode. At least the Android Threema app works as long as it does not switch to port 443.
Hi Boris,
Thank you very much for the in-depth analysis.
Since the beginning (white cube), my eBlocker configuration has been set to “expert” in network mode, and my network management software handles the DHCP service. For years, there were no issues when using Threema—however, other software components can now also cause connection problems when used in combination.
In addition to my statements about Feeder and Tusky, I can now report with eBlocker 4.0.3 that the previews now load within about 2 seconds and only appear as placeholders in about 5% of cases with Tusky.
Btw: I still have the reported anomaly with the timestamp for HTTPS connection errors (now only one hour in the future) and the strange evaluation of the external DNS servers.