[Bug] 最新版本存在闪退

[f4nff]

Verify steps

• [X] Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.
• [X] I have searched on the issue tracker for a related issue.

Version

https://github.com/xjasonlyu/tun2socks/commit/4be2734b19ec3b6082d9b66b2017ddb2656f9d8a

What OS are you seeing the problem on?

No response

Description

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x315854]

goroutine 363 [running]:
github.com/xjasonlyu/tun2socks/v2/tunnel.parseAddr({0x0, 0x0})
        /root/tun2socks/tunnel/addr.go:16 +0xd4
github.com/xjasonlyu/tun2socks/v2/tunnel.handleTCPConn({0x4cfaf8, 0x4000299800})
        /root/tun2socks/tunnel/tcp.go:29 +0x84
created by github.com/xjasonlyu/tun2socks/v2/tunnel.process
        /root/tun2socks/tunnel/tunnel.go:31 +0xbc

CLI or Config

/root/socks/tun -device tun1 -proxy socks5://127.0.0.1:1080

[f4nff]

https://github.com/xjasonlyu/tun2socks/tree/6547625688f9803883fc0c7de6a1c47aa34e2098

这个版本不会闪退。

[xjasonlyu]

最新的commit应该解决了这个问题

[f4nff]

没问题了，而且也不存在close_wait状态了，应该被修正了。

[f4nff]

./stress -n -1 -c 1000 -m POST https://www.google.com/

C:\Users\ll>nslookup www.google.com
服务器:  UnKnown
Address:  10.10.1.1

非权威应答:
名称:    www.google.com
Addresses:  2607:f8b0:4007:810::2004
          142.250.68.36

我使用并发测试，然后关闭程序之后，连接状态还一直保存存在，并没释放。

[f4nff]

    行 671: tcp      6 244 ESTABLISHED src=10.10.1.117 dst=142.250.68.36 sport=10900 dport=443 packets=3 bytes=398 src=142.250.68.36 dst=10.10.1.117 sport=443 dport=10900 packets=19 bytes=22144 [ASSURED] mark=0 use=1
    行 672: tcp      6 183 ESTABLISHED src=10.10.1.117 dst=142.250.68.36 sport=12268 dport=443 packets=6 bytes=719 src=142.250.68.36 dst=10.10.1.117 sport=443 dport=12268 packets=17 bytes=19220 [ASSURED] mark=0 use=1
    行 674: tcp      6 262 ESTABLISHED src=10.10.1.117 dst=142.250.68.36 sport=12117 dport=443 packets=6 bytes=719 src=142.250.68.36 dst=10.10.1.117 sport=443 dport=12117 packets=18 bytes=20682 [ASSURED] mark=0 use=1

我明明已经把程序关闭了，tcp状态在本地已经没了，

[xjasonlyu]

你打开stats，然后去/connections下面看一下哪些连接还开着？

[f4nff]

通过conntrack命令行工具查看conntrack的内容

yum install -y conntrack  
conntrack -L  

正常的流程应该tun发现连接断开之后，主动断开socks5的连接吧，

[xjasonlyu]

对啊，或者proxy连接断开也会断开tun侧连接的。

[f4nff]

tun2socks 运行在路由器上面， 然后下面的客户端机子运行并发测试， 并发数1000， 然后客户机并发测试1000的进程， 这时候tun2socks发现客户端进程主动退出进程，是不是也需要主动断开连接socks5的服务器？

[xjasonlyu]

tun2socks 运行在路由器上面， 然后下面的客户端机子运行并发测试， 并发数1000， 然后客户机并发测试1000的进程， 这时候tun2socks发现客户端进程主动退出进程，是不是也需要主动断开连接socks5的服务器？

是的，这个逻辑写在里面的，我之前也测试过，理论上是会断开整个pipe没错。如果超过一定时间还是存在连接的，说明有bug。

[f4nff]

对的，之前的版本发现有不少close_wait状态，刚才就并发测试了下，发现客户端机已经断开了，但是tun的连接还是存在，也没主动跟socks5服务器断开。

[f4nff]

正常情况下， 进程通过tun并发请求， 然后并发程序关闭之后，tun发现tcp状态关闭之后，就要主动关闭与socks5服务器的连接， 应该是这样才对。

[f4nff]

tun2socks
netstat -nap | grep 4581

socks5
netstat -nap | grep 2475

https://www.cnblogs.com/gyliu/p/12052245.html

你可以自己测试看看。 这个也导致了内存不能及时释放。

[xjasonlyu]

https://github.com/xjasonlyu/tun2socks/blob/5679d15442382478f295bd5c02025f562efa6bb6/tunnel/tcp.go#L51-L69

一直就是这个逻辑，任意一侧连接断开都会断开另一侧的连接。 BTW，你可以重新开一个issue反馈这个问题。

[f4nff]

已经躺下了，你可以得空完善下，我再測，明天再开个帖子，

[f4nff]

tcpWaitTimeout

这个值哪来的？