Question 1

How to prevent Yandex Telemost from detecting and blocking OpenFlux by participant name?

Accepted Answer

OpenFlux used to join Yandex Telemost meetings with the fixed participant name "OpenFlux", which made the tunnel easy to detect and block by username. This was fixed in core v0.5.1 and app v2.4.1: Telemost lanes now join as "Гость" (Guest) with a randomized browser-like RTCP CNAME, so the participant list no longer reveals the tunnel. Update to core v0.5.1+ and app v2.4.1+ to get the fix. As a temporary workaround on older versions, remove Telemost from your node's transport list.

Question 2

How to fix 'WebSocket dial failed (http 409): websocket: bad handshake' error with the mailru transport?

Accepted Answer

Mail.ru's nginx rejects WebSocket upgrade requests that don't offer the `Sec-WebSocket-Extensions: permessage-deflate` header, returning `HTTP 409 Conflict`. This affects OpenFlux core v0.4.2 (node-v1.2.2) where the gorilla/websocket dialer in `transport/mailru/mailru.go` is built without compression. Fix: in `connectToDoc`, set `EnableCompression: true` on the `websocket.Dialer`:

```go
dialer := websocket.Dialer{
    EnableCompression: true, // nginx answers 409 without permessage-deflate offer
    HandshakeTimeout:  15 * time.Second,
    NetDialContext:    netbind.Wrap(&net.Dialer{...}).DialContext,
}
```

gorilla/websocket only sends the `Sec-WebSocket-Extensions` header when `EnableCompression` is true. After this one-line change and rebuild, the handshake returns `101 Switching Protocols`, the carrier connects (`[M-DOCS] WebSocket connected`), and traffic flows. Compression is negotiated at the WebSocket level and handled transparently by the library, so the tunnel protocol is unaffected. User-Agent, Origin, and cookies are irrelevant — only the compression header matters.

Question 3

How to fix Mail.ru Docs transport failing with 'API returned status 500' and WebSocket close 1005 errors in OpenFlux?

Accepted Answer

Mail.ru changed their API (r7/edit endpoint / WebSocket behavior) around October 12, 16:00 UTC, breaking compatibility with node-v1.3.1. Symptoms: `[M-DOCS] cannot open the document: API returned status 500` and `websocket: close 1005` reconnect loops every ~60 seconds, with the client stuck on direct transport. Fix: update the exit node to the latest release — the developer patched the Mail.ru API compatibility and users confirmed it works after updating. With auto-update enabled the node upgrades itself; otherwise pull and restart the latest node version manually. No config or document changes are needed — recreating the document/channel does not help since the issue is server-side API change, not your document or IP block.

Question 4

How to fix Yandex transport captcha errors (HTTP 400 or 'config not found: no client-config script') on non-.ru domains like docs.yandex.kz?

Accepted Answer

This was a bug in the captcha-handling code (introduced in commit 38782b2), now resolved by the maintainer — update to a build newer than main@d13aa5b. Two root causes: (1) `transport/yandex/captcha.go` hardcoded `https://docs.yandex.ru` in the `Origin` header and form action, so the first-tier `showcaptchafast` PoW solve returned HTTP 400 on regional domains (e.g. `docs.yandex.kz`). The fix derives the host dynamically: parse `url.Parse(captchaURL).Host` and use it for both the `Origin` header and the `formAction` prefix (~10-line patch in one file), after which the POST returns 302 (solved). (2) The second-tier challenge `showcaptcha?cc=1&...` (a ~14KB page without the `window.__SSR_DATA__`/`tmgrdfrend-form` markers) was not handled, causing `fetchDocInfo` to fail with `config not found: no client-config script`. Note: this is not IP reputation/rate-limit related — it reproduces on the first request from a fresh IP. Updating to the latest release fixes both issues; there is no config-flag workaround on affected builds.

Question 5

Why does the OpenFlux VPN session handshake time out when using the Yandex transport?

Accepted Answer

Root cause: the native Yandex transport (`transport/yandex/yandex.go`) and the bundled Yandex JS transport hardcode the cursor payload length prefix to `18` for every packet, regardless of actual binary size. Yandex's servers do not relay cursor messages whose declared length doesn't match the real payload, so handshake packets never reach the peer and the session fails with `handshake FAILED after 20s: handshake timed out` even though the WebSocket stays connected.

Fix: patch `transport/yandex/yandex.go` (and the JS transport) so the cursor prefix equals the actual binary packet length before Base64 encoding (e.g., `16;<base64>` for a 16-byte packet) instead of the constant 18. Controlled tests confirmed mismatched prefixes get 0/3 delivery while correct prefixes get 3/3 delivery in both directions, including 64/512/1500-byte packets.

Workaround: keep a Direct transport fallback enabled (e.g., `--transports=yandex:100,direct:50`) so the session can complete over Direct when Yandex relay drops the packets. Note a working Direct path can mask the Yandex failure, so verify with Direct disabled when testing the fix.

OpenFlux

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects