Timeout error during SSH via fctl

Troubleshoot timeout errors, WebRTC data-channel failures, and repeated TURN CreatePermission messages when connecting to a robot with SSH via fctl.

Issue details

I'm getting a timeout error when trying to SSH to my robot via fctl.

Troubleshooting steps

This may be caused by an outdated version of fctl or your Formant agent. To resolve this issue:

sudo apt install fctl

Connection drops with stream N not found after peer connection

If fctl port-forward or ssh <device>.formant establishes a peer connection and then immediately fails, your local network stack may be interfering with the WebRTC data channel.

You may see output similar to:

fctl: peer-to-peer connection is established
sctp ERROR: 2026/01/01 00:00:00 [0x...] stream 3 not found

The peer connection establishes, but the session immediately closes and SSH never completes. Teleoperation and other Formant features may still work normally.

Cause

A NAT on your local machine may be mishandling the WebRTC data-channel traffic used by fctl. The peer connection comes up, but the SCTP data channel desynchronizes and produces a stream N not found error.

The most common cause is running fctl inside WSL2 in its default NAT networking mode. WSL2 NAT can interfere with the UDP/DTLS/SCTP traffic used by the WebRTC data channel.

VPNs and some corporate proxies can cause similar symptoms.

This is a client-side network issue. Updating fctl, updating the Formant agent, or changing the robot network will not resolve it if the local NAT is the cause.

Fix

If you run fctl inside WSL2, switch WSL2 from NAT networking mode to mirrored networking mode:

  1. Edit or create this file on Windows:

    C:\Users\<you>\.wslconfig
  2. Add the following configuration:

    [wsl2]
    networkingMode=mirrored
  3. Restart WSL:

    wsl --shutdown
  4. Reopen your WSL terminal.

  5. Retry the SSH command:

    ssh <device>.formant

If you use a VPN or corporate proxy, temporarily disconnect it or try a different network. If SSH works from another network, work with your network administrator to allow the WebRTC and TURN traffic required by Formant.

To confirm the diagnosis, run the same command from a machine that is not behind WSL2 NAT, the VPN, or the proxy. If it works there, the issue is with the local network stack.

Related

Teleoperation uses the same WebRTC connection path. For related network troubleshooting, see Issues connecting to device via teleop.

Repeating turnc ERROR: CreatePermission ... 400 Bad Request messages

If your SSH tunnel works but the terminal repeatedly prints turnc ERROR: CreatePermission ... 400 Bad Request messages, your firewall or NAT configuration may be changing the UDP source port used for TURN traffic.

One reported cause is pfSense randomizing UDP source ports on outbound NAT. In this case, Twilio's TURN server may tie permission refreshes to the original source port. If the NAT mapping changes, the TURN server can reject the permission refresh and the turnc error may appear again every few minutes.

To resolve this on pfSense, work with your network administrator to add a Static Port NAT rule for outbound UDP traffic on port 3478 from the affected internal user subnet.

After applying the rule, start a new SSH session with fctl and confirm that the turnc ERROR: CreatePermission ... 400 Bad Request messages no longer appear.