Feature: support setSocketOptions on windows

[nange]

Hi, I have made a PR for supporting setSocketOptions on windows, since it is not supported now.

The idea is taken from wireguard-go

[nange]

It seems mistake that base on address parameter to exec bindSocketToInterface4 or bindSocketToInterface6 func.
I think we should base on RawConn which is IPv4 or IPv6, but How can I know that? Do you have any suggestion? @xjasonlyu

[xjasonlyu]

Hi, thanks for the PR!

We don’t need RowConn to know whether is IPv4 or not. The network param already indicates that.

For example, in Darwin:

tun2socks/component/dialer/sockopt_darwin.go

Lines 29 to 34 in 3cbc74b

	switch network {
	case "tcp4", "udp4":
	innerErr = unix.SetsockoptInt(int(fd), syscall.IPPROTO_IP, syscall.IP_BOUND_IF, opts.InterfaceIndex)
	case "tcp6", "udp6":
	innerErr = unix.SetsockoptInt(int(fd), syscall.IPPROTO_IPV6, syscall.IPV6_BOUND_IF, opts.InterfaceIndex)
	}

[nange]

Hi, @xjasonlyu
I have updated the code based on your suggestion. But I found it can't avoid routing loop with the code below:

pc, err := dialer.ListenPacketWithOptions("udp", "", &dialer.Options{
        InterfaceName:  mylocalName,
        InterfaceIndex: mylocalIndex,
})
if err != nil {
        // to do err
}

uAddr, _ := net.ResolveUDPAddr("udp", "114.114.114.114:53")
pc.WriteTo(mydata, uAddr)

Based on the code above, I found the network param in setSocketOptions will be udp6(actually my internet is "IPv4").

There are two ways to fix the routing loop issue that I found：

1. use "udp4" in ListenPacketWithOptions func, eg.

       pc, err := dialer.ListenPacketWithOptions("udp4", "", &dialer.Options{
               InterfaceName:  mylocalName,
               InterfaceIndex: mylocalIndex,
       })

2. only exec bindSocketToInterface4 in setSocketOptions func, eg.

   // ....
   if opts.InterfaceIndex != 0 {
       innerErr = bindSocketToInterface4(windows.Handle(fd), uint32(opts.InterfaceIndex))
   }
   // ....

I'm confused with the result. Any thought??

PS:
I want to proxy all the system traffic except the target ip in China, so I need use dialer.ListenPacketWithOptions interface.
And I also tested on MacOS, there is no routing loop issue although it has the similar code logic.
My local env is: OS: Windows11, IP Net: IPv4

[xjasonlyu]

I guess it might have something to do with Windows' long ipv6 representing ipv4 addresses.

[nange]

Hi, @xjasonlyu please review the code again.
I found a workaround to fix the routing loop issue on windows.
I tested both on IPv4 and IPv6 network on windows11, it works correctly. But It's up to you to merge this PR, It's all ok for me.

[xjasonlyu]

I like this PR since I wondered how to solve routing loop issue on Windows before.

[xjasonlyu]

Hi, please see the reviews.

[nange]

@xjasonlyu Hi, replied to you. Please take a look.

[xjasonlyu]

Thoughts here.

[xjasonlyu]

Also, this feature is only supported on Windows 11, right?

[nange]

Also, this feature is only supported on Windows 11, right?

From the doc(https://learn.microsoft.com/en-us/windows/win32/winsock/ipproto-ip-socket-options#windows-support-for-ip_proto-options), it doesn't support windows10 and lower. But I want to do a test on windows10 in Virtual Machine, I'll give you the result later.

[xjasonlyu]

Do you think we should put the const within the func or declare it globally?

[nange]

It seems more reasonable that move IP_UNICAST_IF to global.

[xjasonlyu]

And how about IP_UNICAST_IF6? They're different param, right?

[nange]

I think we can use IP_UNICAST_IF for all of them, since the value is the same. I've done some research, I found the IP_UNICAST_IF param is unique. Here is the windows.rs example: https://microsoft.github.io/windows-docs-rs/doc/windows/Win32/Networking/WinSock/constant.IP_UNICAST_IF.html I didn't find IP_UNICAST_IF6 or similar.

[xjasonlyu]

There is a param for IPv6: IPV6_UNICAST_IF, see https://learn.microsoft.com/en-us/windows/win32/winsock/ipproto-ipv6-socket-options, nut I wonder if they have the same value.

[nange]

Oh sorry, It is true that IPV6_UNICAST_IF is for IPV6. I also find it in windows.rs and the value is 31 as well. I've updated the code.

[xjasonlyu]

Also, this feature is only supported on Windows 11, right?

From the doc(https://learn.microsoft.com/en-us/windows/win32/winsock/ipproto-ip-socket-options#windows-support-for-ip_proto-options), it doesn't support windows10 and lower. But I want to do a test on windows10 in Virtual Machine, I'll give you the result later.

Ok, thanks. And let me know what happens actually, so we can discuss how to handle those circumstances.

[nange]

Also, this feature is only supported on Windows 11, right?

From the doc(https://learn.microsoft.com/en-us/windows/win32/winsock/ipproto-ip-socket-options#windows-support-for-ip_proto-options), it doesn't support windows10 and lower. But I want to do a test on windows10 in Virtual Machine, I'll give you the result later.

I did the test on windows10 in Virtual Machine. I found it works fine on windows10 as well.

[xjasonlyu]

That's weird but OK.

[xjasonlyu]

Hi, making last style changes, and I think it's good for merge.

[nange]

Hi, the style changes have been done.

[xjasonlyu]

Great, thank you for the PR and all the hard effort!

[xjasonlyu]

Hi, just to mention, someone has tested this feature under Windows 10 21H2 or below, but it doesn't seem to work.

[nange]

Hi, just to mention, someone has tested this feature under Windows 10 21H2 or below, but it doesn't seem to work.

That's weird. Could him open a issue? I want to know how to reproduce it.

[xjasonlyu]

I've had it tested, there's no problem. It turns out he misconfigured the interface name. 🤦‍♂️

[e1732a364fed]

很重要的功能 以及 对于 ipv4部分的 endian转换的发现！感谢