Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gui client - websocket encoding issue #5467

Closed
gleam-ru opened this issue Jun 20, 2024 · 7 comments · Fixed by #5628
Closed

gui client - websocket encoding issue #5467

gleam-ru opened this issue Jun 20, 2024 · 7 comments · Fixed by #5628
Labels
needs triage Issues opened by the public or need further labeling

Comments

@gleam-ru
Copy link

Describe the bug

On some macos-devices connection stucks at "Loading resources...".
In logs I see strange message:

{"time":"2024-06-20T14:38:32.031742Z","target":"phoenix_channel","logging.googleapis.com/sourceLocation":{"file":"phoenix-channel/src/lib.rs","line":"357"},"severity":"DEBUG","backoff":"535.529012ms","maxElapsedTime":"Some(86400s)","message":"Reconnecting to portal on transient client error: websocket connection failed: UTF-8 encoding error"}

To Reproduce

Connect to firezone on macos device ¯_(ツ)_/¯
Problem reproduces on one macos device and not reproduces on another one.
Versions of fz-client are same - 1.0.5 (1718231772)

Expected behavior


Screenshots / Logs

connlib.2024-06-20-14-38-31.log
2024-06-20T14:38:31.744Z.log

Platform (please complete the following information)

  • macOS client
  • server - 1.0.5, client - 1.0.5 (1718231772)
  • macos ventura 13.5.1
  • server - self-hosted, client - app store

Additional context

Firezone is under nginx reverse proxy.
Config:

proxy_read_timeout 90s;
proxy_connect_timeout 90s;
proxy_send_timeout 90s;
proxy_redirect off;
proxy_busy_buffers_size 64k;
proxy_set_header Host $host;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Proxy "";

@gleam-ru gleam-ru added the needs triage Issues opened by the public or need further labeling label Jun 20, 2024
@gleam-ru
Copy link
Author

UPD: issue reproduces if main language of OS is different than "English"

@jamilbk
Copy link
Member

jamilbk commented Jun 20, 2024

Thanks for the report! We've tested with a few different languages successfully. Could you share the language/region setting in macOS that's causing the issue for you?

@gleam-ru
Copy link
Author

region - Russia, language - Русский.

@jamilbk
Copy link
Member

jamilbk commented Jun 28, 2024

@gleam-ru thanks. This is a strange one. UTF-8 should support virtually any language, so the fact that the system is non-English is probably a red herring, and the actual issue may be related to TLS certs, some proxy in between, or some other issue localized to that machine.

@gleam-ru
Copy link
Author

gleam-ru commented Jun 28, 2024

@jamilbk
there are several machines with the same issue.
Proxy settings attached in my first message :)

If you need additional info - feel free to ask.

UPD: after change OS language to English everything works as expected (proxy settings and other settings are same).

@jamilbk
Copy link
Member

jamilbk commented Jun 28, 2024

Thanks for the added info. I've managed to replicate the issue. Will have a fix out shortly.

@jamilbk
Copy link
Member

jamilbk commented Jun 28, 2024

Issue stems from an upstream library. refs hyperium/http#706

github-merge-queue bot pushed a commit that referenced this issue Jun 28, 2024
…5628)

The [HTTP 1.1 RFC](https://datatracker.ietf.org/doc/html/rfc2616) states
that HTTP headers should be US-ASCII. This is not the case when the
macOS Client is run from a host that has a non-English language selected
as its system default due to the way we build the user agent.

This PR fixes that by normalizing how we build the user agent by more
granularly selecting which fields compose it, and not just relying on
OS-provided version strings that may contain non-ASCII characters.

fixes #5467

---------

Signed-off-by: Jamil <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs triage Issues opened by the public or need further labeling
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants