Failed to run the data channel: Failed to read cmd: early eof

[Lakr233]

Currently, when Rathole’s control channel is working normally, if the data channel is interrupted, it does not attempt to establish a new connection. This results in functionality being unavailable. I am currently using the Noise protocol.

• I would like to ask if this is an issue with my configuration or if there is no design to handle this scenario.

tunnel-1  | 2024-12-25T09:44:35.729140Z  INFO config_watcher{path="/app/config.toml"}: rathole::config_watcher: Start watching the config
tunnel-1  | 2024-12-25T09:44:36.129641Z  INFO handle{service=lab}:run: rathole::client: Control channel established
tunnel-1  | 2024-12-25T09:45:26.671300Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:45:26.736981Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:45:26.743869Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:45:26.744209Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:45:26.744289Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:45:26.744889Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:45:29.229061Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:45:29.277050Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:46:59.984763Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:47:07.970506Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:47:09.626772Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:47:11.145260Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:47:58.002186Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:47:58.016176Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:47:58.020133Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:47:58.026335Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:47:58.026518Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
tunnel-1  | 2024-12-25T09:48:00.654624Z  WARN handle{service=lab}:run: rathole::client: Failed to run the data channel: Failed to read cmd: early eof
... nothing else.

[Balssh]

Have the same proble, on rathole 0.5.0

[DEJWICH]

Same problem, latest version of rathole.

[MouseJD]

I had the same problem and found that the internal IP’s of docker containers are allocated dynamically. So the client needs the ip of the vm. This fixed it for me.

[Chuckame]

Had the same issue. Fixed it by restarting the client container

[DEJWICH]

As I am hosting on my old ThinkPad X230, I found the exact network adapter it uses and managed to find a stack exchange thread, which proposed turning these two options off in my proxmox host's "/etc/network/interfaces".

tcp-segmentation-offload: on => off
generic-segmentation-offload: on => off

I managed to debug the issue by getting the logs from my Mikrotik router and also from Proxmox where I saw random connection dropouts, where it reauthenticated its LAN access every few minutes.

Apparently, the adapter has problems with offloading in linux. Has been running awesome ever since!

[hykilpikonna]

It seems that this happened to me when two clients are connected to the same server at the same time.