BBline-X

Troubleshooting

Start here

bash
sudo blinex-agent status    # enrolled? which version?
sudo blinex-agent peers     # who does this device know about, and over what path?
journalctl -u blinex-agent -f

On Windows the log is at %ProgramData%\blinex\agent.log.

A peer is unreachable in one direction

If one side can reach the other but not the reverse, look at the silent side’s log rather than the one reporting the problem — the peer that looks broken is usually the one that is fine. Watch for:

dropping relayed traffic: no data path for this peer

That means traffic is arriving for a peer this agent has no path back to. Restarting the affected agent rebuilds it.

The link keeps flapping

Repeated upgraded from relay and stalled, reverted lines mean a direct path keeps being tried and failing. The agent handles this — it backs off exponentially and stays on the relay — so it is not an outage, but it points at a NAT that passes probes while dropping real traffic. Traffic continues over the relay meanwhile.

No direct path ever forms

Check that the agent’s stun_urls includes a turn: entry and not only stun:. Without a TURN candidate, a device behind a symmetric NAT has no fallback and stays on the relay permanently. See Agent configuration.

Names do not resolve

Test through the system resolver, not only against the agent’s resolver — they take different paths, and only the first is what applications use:

bash
getent hosts peer-name.blinex                  # the real path
dig @127.0.0.1 -p 53535 peer-name.blinex     # the resolver itself

If the second works and the first does not, the OS is not pointed at the agent’s resolver. A SERVFAIL means the upstream could not be reached; a domain answered NXDOMAIN unexpectedly may be on the malicious-domain blocklist.

Traffic to a subnet route is dropped

Confirm the advertising peer is Linux. A Windows peer can use subnet routes and exit nodes but cannot serve as one — it needs WinNAT, absent from a stock Windows install. See Subnet Routes & Exit Nodes.

TLS errors on enrollment

The control plane uses a self-signed certificate unless you supply one. Either set tls_skip_verify on the agent for a lab, or provide TLS_CERT_FILE and TLS_KEY_FILE on the server.

Keep the certificate stable

Agents pin the certificate fingerprint on first contact. Regenerating it — for instance by recreating the container with a fresh volume — breaks every enrolled agent at once. Persist the TLS state directory.