You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have tested the port forwarding feature and it works as it should on Windows and Linux and in between, but I was confused at first because when I connected to a forward session, it told me to use the local port, but I could not connect to the destination through that port. Turns out it listens only on IPv6 ::1 or localhost on Windows. Only then it works. Because I am used to typing 127.0.0.1 for local loopback and not localhost, even though that is apparently the better option, I guess. The only clue is that it uses IPv6 ::ffff:0.0.0.0 style IPv6-IPv4 mixing, and that's what led me to the conclusion. I thought maybe it would be helpful for people to also see the local address that is being listened on?
So this does not appear to be a bug report as I first thought, but rather a feature request maybe? 😄
The text was updated successfully, but these errors were encountered:
The fundamental reason would be rust-lang/rust#130668: the TcpListener::bind API has no way of setting IPV6_V6ONLY socket option, so a platform-specific default is used. So the behavior is unfortunately inconsistent: on Windows (and on Linux with net.ipv6.bindv6only sysctl set to 1) the socket will not listen for IPv4 connections. Otherwise it will listen to both IPv6 and IPv4 as intended.
All relevant calls to TcpListener::bind need to be replaced by manual socket2::Socket binding after calling socket.set_only_v6(false).
I have tested the port forwarding feature and it works as it should on Windows and Linux and in between, but I was confused at first because when I connected to a forward session, it told me to use the local port, but I could not connect to the destination through that port. Turns out it listens only on IPv6
::1
orlocalhost
on Windows. Only then it works. Because I am used to typing127.0.0.1
for local loopback and notlocalhost
, even though that is apparently the better option, I guess. The only clue is that it uses IPv6::ffff:0.0.0.0
style IPv6-IPv4 mixing, and that's what led me to the conclusion. I thought maybe it would be helpful for people to also see the local address that is being listened on?So this does not appear to be a bug report as I first thought, but rather a feature request maybe? 😄
The text was updated successfully, but these errors were encountered: