Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Will it support windows? #2

Open
TongxiJi opened this issue Sep 1, 2016 · 18 comments
Open

Will it support windows? #2

TongxiJi opened this issue Sep 1, 2016 · 18 comments

Comments

@TongxiJi
Copy link

TongxiJi commented Sep 1, 2016

I want to use it to work with shadowsocks.That'll be wanderful.

@yinghuocho
Copy link
Owner

I did't test on Windows. I guess the package itself works, and the command in bin directory lacks a Windows implementation to open a tun device and returns a os.File struct. I will look at this. You can also try to play with it. Thanks.

@TongxiJi
Copy link
Author

TongxiJi commented Sep 2, 2016

Thanks a lot.
I'm look forward to the windows version!

@yinghuocho
Copy link
Owner

@TongxiJi gotun2socks now partially works on Windows. I tested on Windows XP, the basic function works, but very slow. It seems not working on Windows 10. That said, it is not ready to use before I find time to figure out these issues. But you can take a look and welcome to comment or suggest features.

@dogfight360
Copy link

in Windows 10 does not work
Is it possible to increase ICMP transport support in the future?

@yinghuocho
Copy link
Owner

@wu360463231 Yes, I just tried Windows 10, the tun device can be opened, but no packet comes. I need to figure out the problem.

I can think of one way to support ICMP while keeping the tunnel protocol as socks. Let gotun2socks dispatches ICMP messages to a local ICMP-client daemon/module. The ICMP-handle-client daemon/module then encapsulates ICMP messages into a socks session connecting to a remote ICMP-handle-server running on the VPN server. The ICMP-handle-server forwards ICMP messages and relays responses through the socks session. This is similar as how tun2socks supports UDP.

@dogfight360
Copy link

@yinghuocho Yes, the firewall does not have any connection information
When the application exits, the firewall will act only when port 2222 is connected

@yinghuocho
Copy link
Owner

@TongxiJi @wu360463231 Now gotun2socks should work on Windows. You can have a try. Please let me know if you have any problem.

@dogfight360
Copy link

@yinghuocho
UDP work properly, the game test
TCP seems to have problems with some connection processing, the error log:

panic: runtime error: slice bounds out of range

goroutine 1 [running]:
panic(0x5c0f80, 0xc042004060)
C:/Go/src/runtime/panic.go:500 +0x1af
github.com/yinghuocho/gotun2socks/tun.(*winTapDev).Read(0xc04210a000, 0xc042088c00, 0x5dc, 0x5dc, 0xc042565cd0, 0xc0420a80f0, 0x0)
g:/GOPATH/src/github.com/yinghuocho/gotun2socks/tun/tun_windows.go:308 +0x388
github.com/yinghuocho/gotun2socks.(*Tun2Socks).Run(0xc04207ab00)
g:/GOPATH/src/github.com/yinghuocho/gotun2socks/gotun2socks.go:120 +0x15e
main.main()
g:/GOPATH/src/github.com/yinghuocho/gotun2socks/bin/gotun2socks/main.go:55 +0x964

@dogfight360
Copy link

@yinghuocho

I deleted it (tun_windows.go line 307-310)

Works fine
exception should occur in this

  if nr > 14 {
  	if isStopMarker(data[14:nr], dev.addrIP, dev.gwIP) {
  		return 0, errors.New("received stop marker")
  	}

@dogfight360
Copy link

Delete (tun_windows.go line: 307-310) no exceptions
But can not keeplive long time
The TCP connection will still be disconnected at some point in time

@yinghuocho
Copy link
Owner

@wu360463231 Thanks for the feedback. The bug causing the panic should be fixed now. Can you give some details about the TCP disconnection problem, are you chaining gotun2socks with shadowsocks ? I tested with browser to open some pages and videos, didn't notice unexpected TCP disconnection issues.

@dogfight360
Copy link

Yes, I use shadowsocks
shadowsocks and gotun2socks logs do not see any information
today try to test on a more stable network
the TCP connection maybe disconnected because GFW, or China Mobile

@yinghuocho yinghuocho mentioned this issue Dec 7, 2016
@yinghuocho
Copy link
Owner

@wu360463231 how do you config shadowsocks connect with gotun2socks to forward UDP traffic? I tried to use shadowsocks-libev, the UDP relay did't work.

Thanks.

@dogfight360
Copy link

@yinghuocho I use the shadowsocksR C # windows client

@missdeer
Copy link

@yinghuocho AFAIK, shadowsocks-libev's UDP relay feature is not compatible with shadowsocksR server (aka. python version), but C# windows client's implementation does.

@yinghuocho
Copy link
Owner

@missdeer Yes, I also noticed that shadowsocks-libev's UDP relay does not comply with the RFC. It closes UDP Associate's corresponding TCP connection prematurely. After I commented a few lines of code, it worked well.

@yiqing95
Copy link

E:\yiqing-go\src\github.com\yinghuocho\gotun2socks\bin\gotun2socks>gotun2socks.exe --local-socks-addr=192.168.0.100:9666 --tun-device=tap0901:SSTAP:10.0.0.1:10.0.0.0:255.255.255.0
2017/10/22 11:20:01 device component id: {4054C3DD-32C4-49B9-A5B2-0103872D5550}
2017/10/22 11:20:01 device name: SSTAP
2017/10/22 11:20:02 set SSTAP with net/mask: 10.0.0.2/255.255.255.0 through DHCP
2017/10/22 11:20:02 set SSTAP with dns: 8.8.8.8,8.8.4.4 through DHCP
2017/10/22 11:20:02 ipv6 packet
2017/10/22 11:20:03 ipv6 packet
2017/10/22 11:20:03 ipv6 packet
2017/10/22 11:20:03 ipv6 packet
2017/10/22 11:20:03 ipv6 packet
2017/10/22 11:20:03 ipv6 packet
2017/10/22 11:20:04 ipv6 packet
2017/10/22 11:20:04 ipv6 packet
2017/10/22 11:20:04 Unsupported packet: protocol 2
2017/10/22 11:20:04 ipv6 packet
2017/10/22 11:20:04 Unsupported packet: protocol 2
2017/10/22 11:20:04 ipv6 packet
2017/10/22 11:20:04 Unsupported packet: protocol 2
2017/10/22 11:20:04 Unsupported packet: protocol 2
2017/10/22 11:20:04 ipv6 packet
2017/10/22 11:20:04 ipv6 packet
2017/10/22 11:20:04 tracking 1 UDP connections
2017/10/22 11:20:05 error to send UDP packet to relay: write udp 192.168.0.100:59392->127.0.0.1:16764: wsasendto: The requested address is not valid in its context.
2017/10/22 11:20:05 tracking 0 UDP connections

...
2017/10/22 11:21:03 Unsupported packet: protocol 2
2017/10/22 11:21:03 ipv6 packet
2017/10/22 11:21:03 Unsupported packet: protocol 2
2017/10/22 11:21:03 ipv6 packet
2017/10/22 11:21:03 tracking 1 UDP connections
2017/10/22 11:21:03 Unsupported packet: protocol 2
2017/10/22 11:21:03 ipv6 packet
2017/10/22 11:21:03 error to send UDP packet to relay: write udp 192.168.0.100:57940->127.0.0.1:13889: wsasendto: The requested address is not valid in its context.
2017/10/22 11:21:03 tracking 0 UDP connections
2017/10/22 11:21:05 ipv6 packet
2017/10/22 11:21:28 tracking 1 UDP connections
2017/10/22 11:21:28 error to send UDP packet to relay: write udp 192.168.0.100:57945->127.0.0.1:62162: wsasendto: The requested address is not valid in its context.
2017/10/22 11:21:28 tracking 0 UDP connections

win10 platform

these errors mean are there something wrong with my socks5-server (not using the shadowsocks )?
or I give the wrong config options ?

plz help and give some advice on windows platform . ✌️ 🐰

@txthinking
Copy link

txthinking commented Oct 28, 2017

@yinghuocho

Yes, I also noticed that shadowsocks-libev's UDP relay does not comply with the RFC. It closes UDP Associate's corresponding TCP connection prematurely. After I commented a few lines of code, it worked well.

A UDP association terminates when the TCP connection that the UDP ASSOCIATE request arrived on terminates.

Client(1) <----socks5 protocol(2)----->Socks5 Server<----> Remote [<----> Remote...]
  1. Tun is also a client.
  2. I think we should strictly abide by the standards here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants