Port forwarding stalls (after macOS sleep?)

[natevw]

Type: Bug

I've been having trouble in recent months with port forwards to my VMs. It used to be reliable but now whenever I leave and/or close my laptop for a long time my port forwards stop working.

In normal usage, this would be e.g. a Django/node.js webapp on port 8000 but I am also able to somewhat reproduce it with just socat:

1. In a VM through VS Code terminal start socat TCP-LISTEN:8001,fork,reuseaddr,bind=localhost - running
2. Forward port 8001 through the "Ports" tab provided by this Remote extension
3. Confirm that from the host can socat - TCP:localhost:8001 and data typed on host shows up on guest and vice-versa.
4. Now, close the lid of the laptop and wait (doesn't happen right away, pretty much 100% overnight, and maybe 50/50% during a snack break…)

When coming back to my real work (e.g. a web server), the browser just stalls when I refresh the page — i.e. it doesn't show connection refused right away or anything, but rather the tab just sits there spinning for a looooong time (many minutes!) without any request actually making it to my dev server.

With this socat test, things were even a bit more mysterious. When the port forwarding was in this state:

• opening a new connection from host to VS Code / guest via socat - TCP:localhost:8001 succeeeded
• my typing from the host into the remote listener didn't show up…
• …until I typed some in the VM's still-running socat process! then some of the incoming data did show up, as if it had gotten stuck in a buffer somewhere?
• but then additional connections and further testing, nothing further made it back or forth…?

In this state, restarting neither the socat TCP-LISTEN:8001,fork,reuseaddr,bind=localhost - in the remote VM nor reconnecting more new socat - TCP:localhost:8001 from the host running VS Code got any further bytes through, just the one random buffer that made it in the one time after some typing went back out.

The workaround is to "delete" the port forward and recreate it in the Ports tab — then it resumes working.

Extension version: 0.115.0 VS Code version: Code 1.94.2 (384ff7382de624fb94dbaf6da11977bba1ecd427, 2024-10-09T16:08:44.566Z) OS version: Darwin arm64 21.6.0 Modes: Remote OS version: Linux arm64 5.10.0-33-arm64

System Info

|Item|Value| |---|---| |CPUs|Apple M1 Pro (8 x 2400)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: enabled
webgl: enabled
webgl2: enabled
webgpu: enabled
webnn: disabled_off| |Load (avg)|1, 2, 2| |Memory (System)|16.00GB (0.44GB free)| |Process Argv|| |Screen Reader|no| |VM|0%| |Item|Value| |---|---| |Remote|SSH: vm-inq-5e| |OS|Linux arm64 5.10.0-33-arm64| |CPUs|unknown (2 x 0)| |Memory (System)|3.83GB (3.14GB free)| |VM|0%|

[joshspicer]

…until I typed some in the VM's still-running socat process! then some of the incoming data did show up, as if it had gotten stuck in a buffer somewhere?

Does this mean typing in the VS Code integrated terminal where the socat process is attached?   Perhaps a more stable configuration would be a VS Code task or similar that can re-create ports after a long session away. That way, it's one press to "Tear down" and "set up" all those ports. Thoughts?

[natevw]

Does this mean typing in the VS Code integrated terminal where the socat process is attached?

Yes, it's been a little while but iirc what I did was type e.g. "abcabc[enter]" in the local machine to the remote, but nothing showed up in the remote. But when I typed "123123[enter]" in the remote machine (via VS Code integrated terminal) then suddenly the "abcabc" did show up. But then nothing further got passed in either direction. Just kind of weird and maybe a fluke but maybe a clue?

Perhaps a more stable configuration would be a VS Code task or similar that can re-create ports after a long session away. That way, it's one press to "Tear down" and "set up" all those ports. Thoughts?

Well, that might be a workaround in the meantime? But it seems that for a couple years there was no problem with this. I wish I'd filed sooner or at least had a better memory for when this started, but it seems that earlier this year suddenly the port forwarding went from being alway reliable to having this stalled-tunnel as a new behavior. So ideally it'd be nice if the forwards just kept working like they used to, instead of just automating a workaround iiuc?

[natevw]

Oh one other clue of note! It's possible this is coincidence and unrelated, but I seem to remember that VS Code used to detect/show which actual process it found remotely on the forwarded port. But perhaps around the time this stalled tunnel stopped working it also stopped showing the process:

The port forward still works (for a while) but it doesn't seem to be as aware of what it's connecting to as it used to. And it doesn't seem to notice other ports that might be available on the remote either. When I was messing with remote.localPortHost and changed it from "localhost" to "allInterfaces" it seemed to start showing the process again but that was an unrelated exploration and not sure if that's related to the stalling.