Not able to open trustedServers.txt if username contains wide characters e.g. Chinese characters #974
Comments
|
Could be related to #976. I made an attempt to fix that one, and it may also fix your issue but am not sure (as I am not familiar with chinese characters, and how they relate to Windows ansi encoding etc). If you are willing to test this beta build, we would find out: |
|
I tested this. trustedServers.txt can be read now. But a new issue is barrier keeps asking me to trust the host signature, again and again. |
Great! Thank you.
It seems the service is misconfigured somehow, leading to the client exiting but being continuously restarted by the process monitoring logic.
I see you also get non-fatal errors like this. I think I can fix this the same way as the original "Unable to open trustedServersFile". |
Pushed a fix for this as well, beta version here: https://dev.azure.com/debauchee/Barrier/_build/results?buildId=359&view=artifacts&pathAsName=false&type=publishedArtifacts The remaining issue is in your configuration, I think? |
What does 'configuration' mean? I was only changing configuration on the GUI. |
|
Sorry for the vague statement, I'm farily new to this project so I wasn't sure how the configuration were handled from GUI.. Looked a bit more into it, and seems the GUI generates a temporary configuration file based on the settings.
And then passes this to the background service, which in turn executes the client/server utilities. There is probably a similar issue, (character encoding related) somewhere along this route, but I cannot see where.. Increasing the log level to DEBUG and posting the log again could help:
Then I will investigate it more... (unless you do not bother, and would rather wait until someone more familiar with this code can take over) |
Log with debug level enabled |
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 10, 2020
|
Thank you! Finally tracked down another one of those character encoding issues, hopefully this was it! If you want to retest your exact case, the beta is here: |
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 10, 2020
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 10, 2020
This build does not work still. It still pops dialog again and again. Logs: |
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 11, 2020
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 11, 2020
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 11, 2020
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 11, 2020
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 11, 2020
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 11, 2020
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 11, 2020
|
Thank you for your patience, and for your valuable input! Fixed yet another couple of issues, Previous fix was more in the server and deamon, I reproduced an issue there and were too convinced that was it, but your issue are in the client mode... And it turns out there were several parts that needed a fix (client, server, deamon). Hopefully I've tracked all down and fixed them this time. But I don't have the exact test setup as you, so can not be 100% certain. Just let me know if there are more issues, I'm determined to get this out of the way now! Edit: Did some additional refactoring, should not change any of the functionality but if not testet previous beta yet, then please use latest: https://dev.azure.com/debauchee/Barrier/_build/results?buildId=396&view=artifacts&pathAsName=false&type=publishedArtifacts |
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 11, 2020
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 11, 2020
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 11, 2020
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 11, 2020
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 11, 2020
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 12, 2020
I tried this build. Not any pop-up dialog. But the connection still failed to be established. Debug log: |
|
That is too bad. And strange. Did you get the fingerprint pop-up, asking you to trust the fingerprint, at all this time?
Does this file exist, and has content? If you delete it (or rename it temporarily) before starting the barrier client, do you get the normal fingeprint pop-up asking you to trust the fingerprint? And when you accept, this same file is created again? (It seems the gui front-end application thinks the TrustedServers.txt exists and is ok, while the client background application is not able to find it). (I retested the beta again in my setup, and it works as it should - fingerprint pop-up once, TrustedServers.txt created, client background application finds the file and matches the fingerprint, connect ok. So your case might still be somewhat different). |
No pop-up for this build.
Yes. The file exists.
I can test this, but may be a few days later. |
|
What I think is an identical issue was solved with that latest beta, so fingers crossed yours will as well..
|
I am back to that configuration. Which is the latest build I can test? |
albertony
added a commit
to albertony/barrier
that referenced
this issue
Dec 28, 2020
|
Forced a new build, artifacts here: |
p12tic
added a commit
to p12tic/barrier
that referenced
this issue
Oct 29, 2021
…ixes debauchee#976, fixes debauchee#974, fixes debauchee#444)" This reverts commit 402801e.
p12tic
added a commit
to p12tic/barrier
that referenced
this issue
Oct 29, 2021
This fixes debauchee#976, fixes debauchee#974, fixes debauchee#444.
p12tic
added a commit
to p12tic/barrier
that referenced
this issue
Oct 29, 2021
This fixes debauchee#976, fixes debauchee#974, fixes debauchee#444. On Windows the standard stream open() functions expect bytes encoded in current system encoding, not UTF8. Since we're dealing with UTF8 throughout the application this results in wrong paths being passed and failure to open files. As a solution, we convert the paths to UTF16 via the WCHAR character type and use the special Windows-specific overloads of open() functions.
p12tic
added a commit
to p12tic/barrier
that referenced
this issue
Oct 29, 2021
This fixes debauchee#976, fixes debauchee#974, fixes debauchee#444. On Windows the standard stream open() functions expect bytes encoded in current system encoding, not UTF8. Since we're dealing with UTF8 throughout the application this results in wrong paths being passed and failure to open files. As a solution, we convert the paths to UTF16 via the WCHAR character type and use the special Windows-specific overloads of open() functions.
This was referenced Nov 10, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
A clear and concise description of what the bug is.
SSL-enabled session failed to start. Barrier is unable to open the right created trustedServers.txt. I am wondering that's because the path contains wide characters, since my username is in wide characters.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Works with username contains wide character
Screenshots
If applicable, add screenshots to help explain your problem.
Please do not link to image hosting sites, as these can be ephemeral. Instead, attach them to the issue.
Error log:
Desktop (please complete the following information):
Additional context
Server is barrier 2.3.3 running on Fedora 32. Connection can be established if SSL-disabled on both sides.
The text was updated successfully, but these errors were encountered: