Tunnel fails to close after Linux system resumes from sleep

[VITEK-THE-BEST]

On a Linux-based system, after resuming from sleep, it is impossible to close the tunnel without killing the process.

Here’s the normal behavior when closing the tunnel:

sudo go run github.com/Jigsaw-Code/outline-sdk/x/examples/outline-cli@latest -transport "ss://token"
OutlineVPN CLI (experimental)
[INFO] 2024/12/06 16:00:09 updated global IPv6 support: false
[INFO] 2024/12/06 16:00:09 remote server supports UDP, we will delegate all UDP packets to it
[INFO] 2024/12/06 16:00:09 routing traffic configured...
^C[INFO] 2024/12/06 16:47:43 received interrupt, terminating...
[INFO] 2024/12/06 16:47:43 routing table cleaned up
[INFO] 2024/12/06 16:47:43 DNS config restored
[INFO] 2024/12/06 16:47:43 OutlineDevice -> tun stopped: 274279765 <nil>
[INFO] 2024/12/06 16:47:43 tun -> OutlineDevice stopped: 27566484 read tun: file already closed

However, after resuming from sleep, attempting to close the tunnel results in infinite waiting:

OutlineVPN CLI (experimental)
[INFO] 2024/12/06 00:23:58 updated global IPv6 support: false
[INFO] 2024/12/06 00:23:58 remote server supports UDP, we will delegate all UDP packets to it
[INFO] 2024/12/06 00:23:58 routing traffic configured...
^C[INFO] 2024/12/06 10:21:42 received interrupt, terminating...
[INFO] 2024/12/06 10:21:42 routing table cleaned up
[INFO] 2024/12/06 10:21:42 DNS config restored
[INFO] 2024/12/06 10:21:42 OutlineDevice -> tun stopped: 264549559 <nil>
signal: killed

The only way to close the tunnel in this case is to kill the outline-cli process manually.

The issue occurs in app_linux.go, specifically here:

go func() {
    defer trafficCopyWg.Done()
    written, err := io.Copy(ss, tun)
    logging.Info.Printf("tun -> OutlineDevice stopped: %v %v\n", written, err)
}()

This section does not receive an EOF, preventing the connection from closing.

I believe the issue lies in how io.Copy blocks indefinitely while waiting for data from the TUN device. This behavior becomes problematic after the system wakes up from sleep, as the TUN device does not signal EOF or return from the Read call.

[jyyi1]

Thanks for reporting the issue. Though the root cause here seems to be that we are not able to Close the tun device:

https://github.com/Jigsaw-Code/outline-sdk/blob/v0.0.17/x/examples/outline-cli/app_linux.go#L36

Because in the normal case, once the tun device has been Closed, the traffic copy go-routine will terminate:

[INFO] 2024/12/06 16:47:43 tun -> OutlineDevice stopped: 27566484 read tun: file already closed

io.Copy should respect that and return immediately when one of the IO objects has been closed.

[alamar]

I've prepared a pull request. I have too noticed that once my laptop goes to sleep, outline-cli will fail to recover and it will fail to be shut down with ctrl-C.

It turns out UDPHandler's closeSession() will try to acquire mutex, but it is called by newSession() in ReceiveTo without releasing the same mutex - all in udp.go.

Once I've fixed that and added a separate lock around addition of new sender, it will now able to recover most of the time and it is possible to shut it down normally. Please review!