Port Conflict Detection and SSH Forwarding Improvements

[tatsukamijo]

🔄 Changes

This PR enhances the rdp-ssh script to handle port conflicts more gracefully:

1. Dynamic Docker Port Discovery: Checks both X11 display numbers AND actual Docker port usage to find available ports (cf: [bug] conflict with allocated port map #4)
2. Graceful SSH Port Forwarding: Added ExitOnForwardFailure=no to prevent SSH connection hangs when port forwarding conflicts occur

⚠️ Breaking Changes

None

🎯 Motivation

Problem 1: Docker Port Allocation Conflicts

Details

When starting a new virtual desktop session, rdp-ssh only checked X11 display numbers in /tmp/.X11-unix/ but didn't verify if the corresponding Docker port was actually available. This caused "port already allocated" errors when:

• Containers were manually launched with custom display/port combinations
• Containers crashed leaving orphaned X11 socket files
• Mixed management tools created containers in the same port range

Example Error (from #4):

docker: Error response from daemon: failed to set up container networking:
driver failed programming external connectivity on endpoint okubo:
Bind for 0.0.0.0:6103 failed: port is already allocated

Problem 2: SSH Port Forwarding Conflicts

Details

Multiple connections to the same remote host caused SSH port forwarding conflicts, especially with ~/.ssh/config LocalForward settings (e.g., LocalForward 5900 localhost:5900 for VNC).

Symptom:

bind [127.0.0.1]:5900: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 5900
Could not request local forwarding.
[Hangs for ~5 minutes waiting for timeout]

This resulted in several-minute connection times when opening multiple terminal sessions.

🔍 Reproduction Steps

Test 1: Port Conflict Detection (Verified on robot_dev7)

Details

# Initial state check
ssh robot_dev7 "docker ps --format 'table {{.Names}}\t{{.Ports}}'"
# NAMES              PORTS
# desktop-kamijo     0.0.0.0:6092->6080/tcp

ssh robot_dev7 "ls /tmp/.X11-unix/"
# X0 X1 X2

# Create a test container occupying port 6091 (creating a port gap)
ssh robot_dev7 "docker run -d --name test-port-conflict -p 6091:8080 nginx:alpine"

# Try to start a new session
# Expected display number: 3 (next after X2)
# Expected port: 6093 (skipping occupied 6091)
rdp-ssh -a robot_dev7 -n test-session-port start

# Output:
# 2 3
# Will create new display :3. To use on the remote, execute the following:
# export DISPLAY=:3
# Started "test-session-port"!

# Verify port assignment
ssh robot_dev7 "docker ps --format 'table {{.Names}}\t{{.Ports}}' | grep test-session-port"
# test-session-port    0.0.0.0:6093->6080/tcp  ✅ Correctly skipped to 6093

# Cleanup
ssh robot_dev7 "docker stop test-session-port test-port-conflict && docker rm test-port-conflict"

Result: Successfully detected port conflict and skipped to next available port (6093) in ~2.5 seconds.

Test 2: SSH Forwarding Graceful Failure (Verified on robot_dev7)

Details

# Terminal 1: Start a connection with port forwarding
ssh -o ExitOnForwardFailure=no -L 15900:localhost:6090 robot_dev7 "sleep 30" &

# Terminal 2: Try to connect with the same port forward (NEW behavior)
ssh -o ExitOnForwardFailure=no -L 15900:localhost:6090 robot_dev7 "echo 'Connected'; exit 0"

# Output:
# bind [127.0.0.1]:15900: Address already in use
# channel_setup_fwd_listener_tcpip: cannot listen to port: 15900
# Could not request local forwarding.
# Connected  ✅ Connection established immediately despite error

# Compare with OLD behavior (without ExitOnForwardFailure=no):
# ssh -L 15900:localhost:6090 robot_dev7 "echo 'test'"
# [Hangs indefinitely waiting for port forwarding timeout]

Result: With ExitOnForwardFailure=no, connection succeeds immediately (~3 seconds) despite port forwarding error messages.

✅ Results

Performance Improvement:

• Port conflict detection: Successfully skips occupied ports in ~2.5 seconds
• SSH forwarding with conflicts: Connection time reduced from indefinite hang to ~3 seconds

📝 Additional Notes

• Both start and connect commands now use ExitOnForwardFailure=no for consistent behavior
• Beneficial for users who work with multiple terminal sessions simultaneously

[ptrkhr]

LGTM!

[ptrkhr]

@tatsukamijo If the implementation is finished I will just merge it.

[tatsukamijo]

@ptrkhr Thanks for your review, it is ready to merge.