jpillora / jpillora/chisel

Remote forwards not clearing on server when client loses power

Open
#168 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

need-more-info
Dominant language
Go
Stars
16.6k
Forks
1.6k
PR merge metrics
No merged PRs in 30d

Description

I have some rasp pi's forwarding their ssh to a central server. If a rasp pi loses power or router is down during reboot, when rasp pi comes back up and tries to push its ssh to the port it used before, client gives this message:

2020/06/28 01:24:49 client: server: server: proxy#3:R:0.0.0.0:3999=>127.0.0.1:22: listen tcp4 0.0.0.0:3999: bind: address already in use

server command: chisel server --pid --reverse --port 443
client command: chisel client --keepalive 1m --pid 192.168.64.230:443 R:3999:127.0.0.1:22

Server OS is debian buster and rasp pi's are using current raspbian.

lsof on the server shows the chisel process with 3999 open for hours after the rasp pi lost power.

Sending a SIGHUP to the chisel server is killing the process completely.

I see the --keepalive option uses the websocket ping/pong but I think it would need to be a server option to help here.

Another option I was trying to figure out would be to use SO_KEEPALIVE on the server's socket but I am not overly familiar with go and haven't sorted that out yet.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the stale reverse-forward condition with the provided chisel server and client commands, then inspect the server-side websocket keepalive and cleanup behavior after the client loses power. Use lsof on the server to confirm when port 3999 is released; done means a reconnect can reuse the port without restarting the server.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.