openvz+vmware用faketcp不通

[PHCSJC]

环境：
服务器端：openvz+centos6.8_x64+kcptun
客户端：win7+openwrt12.09_x86_vmware_image_with_udp2raw_pre_installed

1.--raw-mode用faketcp不通
2.--raw-mode用udp可以通，说明整个配置是没问题的
3.用ssh服务测试的
4.-a 参数去掉也不行
5.命令是完全参照示例里写的，没有添加其它参数
6.我不确定是否和openvz有关，只是猜测

[wangyu-]

虚拟机网卡是不是桥接模式？

[PHCSJC]

@wangyu- 确实是这个问题，之前是nat模式，换成桥接后好了，原来必须得桥接，谢谢！

[PHCSJC]

另一个请教：后期会增加windows客户端吗？还是windows上无法实现必须得linux呢？

[wangyu-]

在windows上实现一个困难是需要改得东西比较多，维护起来麻烦。

另一个困难是windows没iptables，用什么东西替代我暂时也没有想法。

短期不会有windows原生客户端。

[PHCSJC]

我这速度明显提高了很多，1080p完全没问题。
再有一个疑惑：我开启的bbr，对udp2raw-tunnel会有加速作用吗？

[wangyu-]

再有一个疑惑：我开启的bbr，对udp2raw-tunnel会有加速作用吗？

没作用。但是不冲突，可以开。

[PHCSJC]

再请教，我在docker下运行，报这个错误，是不支持吗？还是哪里不对？
[2017-09-04 15:18:35][INFO]argc=10 /root/udp2raw/udp2raw_amd64 -s -l 0.0.0.0:9080 -r 127.0.0.1:443 -k dcOa145I0NoK --raw-mode faketcp
[2017-09-04 15:18:35][INFO]important variables: log_level=4:INFO raw_mode=faketcp cipher_mode=aes128cbc auth_mode=md5 key=dcOa145I0NoK local_ip=0.0.0.0 local_port=9080 remote_ip=127.0.0.1 remote_port=443 source_ip=0.0.0.0 source_port=0 socket_buf_size=1048576
[2017-09-04 15:18:35][INFO]const_id:3c1787b6
[2017-09-04 15:18:35][FATAL]SO_SNDBUFFORCE fail

[wangyu-]

你下载这个版本试一下，然后贴一下日志。
https://github.com/wangyu-/udp2raw-tunnel/files/1267468/udp2raw_amd64.zip

[PHCSJC]

报错：
[2017-09-04 15:29:36][INFO]argc=10 /root/udp2raw/udp2raw_amd64 -s -l 0.0.0.0:9080 -r 127.0.0.1:443 -k dcOa145I0NoK --raw-mode faketcp
[2017-09-04 15:29:36][INFO]important variables: log_level=4:INFO raw_mode=faketcp cipher_mode=aes128cbc auth_mode=md5 key=dcOa145I0NoK local_ip=0.0.0.0 local_port=9080 remote_ip=127.0.0.1 remote_port=443 source_ip=0.0.0.0 source_port=0 socket_buf_size=1048576
[2017-09-04 15:29:36][INFO]const_id:26bdfd4a
[2017-09-04 15:29:36][FATAL]SO_SNDBUFFORCE fail socket_buf_size=1048576 errno=Operation not permitted

[wangyu-]

这个账户是root吗？貌似你的机器不允许SO_SNDBUFFORCE这个操作。

用--sock-buf 100试一下，看是否能运行。

[PHCSJC]

加了--sock-buf 100还是报错。docker启动没有root权限，我在docker里执行命令是root权限，这样行吗？
[2017-09-04 15:35:14][INFO]argc=12 /root/udp2raw/udp2raw_amd64 -s -l 0.0.0.0:9080 -r 127.0.0.1:443 -k dcOa145I0NoK --raw-mode faketcp --sock-buf 100
[2017-09-04 15:35:14][INFO]important variables: log_level=4:INFO raw_mode=faketcp cipher_mode=aes128cbc auth_mode=md5 key=dcOa145I0NoK local_ip=0.0.0.0 local_port=9080 remote_ip=127.0.0.1 remote_port=443 source_ip=0.0.0.0 source_port=0 socket_buf_size=102400
[2017-09-04 15:35:14][INFO]const_id:abb195ae
[2017-09-04 15:35:14][FATAL]SO_SNDBUFFORCE fail socket_buf_size=102400 errno=Operation not permitted

[wangyu-]

你这个docker里面的root有可能不是真正的root，貌似没权限用这个命令。

加上--log-position试一下，我看看问题出在哪行代码。一会我给你重新编译一版，去掉SO_SNDBUFFORCE这个操作。

[PHCSJC]

[2017-09-04 15:48:32][INFO][main.cpp,func:process_arg,line:2802]argc=11 /root/udp2raw/udp2raw_amd64 -s -l 0.0.0.0:9080 -r 127.0.0.1:443 -k dcOa145I0NoK --raw-mode faketcp --log-position
[2017-09-04 15:48:32][INFO][main.cpp,func:process_arg,line:3098]important variables: log_level=4:INFO raw_mode=faketcp cipher_mode=aes128cbc auth_mode=md5 key=dcOa145I0NoK local_ip=0.0.0.0 local_port=9080 remote_ip=127.0.0.1 remote_port=443 source_ip=0.0.0.0 source_port=0 socket_buf_size=1048576
[2017-09-04 15:48:32][INFO][main.cpp,func:main,line:3390]const_id:219e4ad
[2017-09-04 15:48:32][FATAL][network.cpp,func:init_raw_socket,line:204]SO_SNDBUFFORCE fail socket_buf_size=1048576 errno=Operation not permitted

[wangyu-]

我编译了个新版，默认去掉了SO_SNDBUFFORCE操作，你试一下。
udp2raw_binaries.tar.gz

[PHCSJC]

你很牛逼！可以了，同时加了这个参数--seq-mode 0才稳定。

[wangyu-]

--seq-mode 0这个应该不用吧，加了这个反而会有明显的特征，容易被封掉。
你觉得这个稳定可能是运气因素造成的。
建议用--seq-mode 1或--seq-mode 2.

[PHCSJC]

1是默认，确实不稳定，网页一打开就断，改成0就可以了，我再试试2

[wangyu-]

--seq-mode 0表示关掉tcp序号的模拟。
--seq-mode 1表示模拟不丢包情况下的tcp序号。
--seq-mode 2假装有一定丢包，序号有时增长有时不涨。

[PHCSJC]

我有一个nat的server，1是默认，试了很多次确实不稳定，网页一打开就断，改成0就可以了，我再试试2
我另一台非nat的服务器，没有加--seq-mode这个参数没有问题。

[wangyu-]

nat的server是说阿里云的1:1nat吗？

[PHCSJC]

不是， 一个不知名的。

[wangyu-]

麻烦你把这个vps供应商的名字发到我邮箱里 [email protected]

哪天有时间我注册一个试试，看看是什么原因。

[PHCSJC]

发你邮箱了

[wangyu-]

多谢

[PHCSJC]

刚试了参数2几分钟，能打开，但感觉好像速度要慢些，不知道是否是错觉。

[wangyu-]

如果方便的话，可以用www.speedtest.net之类的网站测速试一下。能测出延迟和吞吐。

[PHCSJC]

又试了下参数1，确实不行，又断了。

[wangyu-]

又试了下参数1，确实不行，又断了。

了解了。多谢反馈。

[PHCSJC]

现在的测试是：
1.一个nat server+一个docker，用0正常，用1不行，用2好像有些慢。
2.另一个普通的server，默认就正常。

[wangyu-]

./udp2raw_mips34kc: line 1: syntax error: unexpected "("

binary选择的不对。查一下cpu架构。如果没有合适的就自己编译，参考readme里面的编译教程。

[PHCSJC]

mt7621是mips架构的，用udp2raw_mips34kc应该没有错吧？再就是不会编译喔。

[wangyu-]

貌似你这个路由器的CPU运行在'little endian'模式，我编译的那个是'big endian'的。

编译教程： https://github.com/wangyu-/udp2raw-tunnel/blob/master/doc/build_guide.zh-cn.md

[PHCSJC]

好吧，这个对于我来说难道太大，我还是等高人适配吧。

[wangyu-]

@PHCSJC

我新发布了一版release.增加了'little endian'的mips binary.

https://github.com/wangyu-/udp2raw-tunnel/releases

文件名：udp2raw_mips24kc_be和udp2raw_mips24kc_be_asm_aes udp2raw_mips24kc_le和udp2raw_mips24kc_le_asm_aes

不保证可以用，我手上没有可测试的环境。

[PHCSJC]

@wangyu-
k2p上测试的udp2raw_mips24kc_le_asm_aes，没有问题，给你点个赞！

[wangyu-]

多谢反馈。

udp2raw_mips24kc_be和udp2raw_mips24kc_be_asm_aes.

是udp2raw_mips24kc_le和udp2raw_mips24kc_le_asm_aes。

前面的写错了。

[PHCSJC]

斐讯k2p（mt7621）：默认参数，看1080p视频，CPU 9%-15%，这个负载完全可以正常使用。

[PHCSJC]

小米路由器mini（mt7620）：udp2raw_mips24kc_le_asm_aes，默认参数，看1080p视频，CPU 40%-60%。单个用户没问题。

[wangyu-]

小米路由器mini（mt7620）：udp2raw_mips24kc_le_asm_aes，默认参数，看1080p视频，CPU 40%-60%。单个用户没问题。

多谢反馈。

另外，看1080p视频这样测试出来的结果可能不是最准确的。因为YouTube不会尝试一直打满你的带宽，有时候Youtube在缓冲，有时候Youtube是空闲的，测出来结果可能会偏低。

测性能可以在server 用 iperf3 -s ，在client用 iperf3 -c <server_ip> -P30 -t100和iperf3 -c <server_ip> -P30 -R -t100，这样iperf3会尝试打满你的带宽。

[PHCSJC]

@wangyu-
iperf3不会用喔，抱歉，我只是用来看看视频、搜索。速度我观察了下，是目前几个方案中最快的。

[wangyu-]

我只是用来看看视频、搜索。速度我观察了下

下载大文件观察也可以，我觉得比开Youtube观察准确。

iperf3不会用喔，抱歉。

没事，我只是顺便说下YouTube测CPU这个方法可能不是很可靠。

[PHCSJC]

下载了个大文件试了下，50M带宽打满，小米路由器mini上cpu占用率40%-50%

[PHCSJC]

昨天晚上server进程崩溃了，看发布了新版本20170911.0，是解决的这个问题吗？

[wangyu-]

昨天晚上server进程崩溃了

崩溃是指程序自己退出了吗？具体现象是什么。

看发布了新版本20170911.0，是解决的这个问题吗？

昨天修的那个bug会导致性能问题，极端情况下会导致server连不上，但是不会退出。过几分钟后等有问题的连接被回收掉之后server会自己活过来。

昨天晚上server进程崩溃了

我这边最近一个月都没观察到崩溃，server是vultr日本512mb内存。

建议运行一下ulimit -c unlimited，这样程序崩溃后会在当前目录产生一个core文件。把这个文件传给我，可以用它找到崩溃的原因。

[PHCSJC]

kcptun，ssr都还在，就udp2raw进程没了，有可能是我的鸡内存太小只有128M的原因。
今天刚更新的0911版本，目前未出现崩溃。
运行了ulimit -c unlimited，再观察看看。

[wangyu-]

在这个问题查明之前，可以用这个脚本：

#! /bin/sh
while true
do
xxxxxxxxxxxxxxxxxxxxxx//运行udp2raw
sleep 10
done

这样在udp2raw退出后会自动重新运行。

[PHCSJC]

好的，谢谢

[linhua55]

@wangyu-

另一个困难是windows没iptables，用什么东西替代我暂时也没有想法。

可借鉴 finalSpeed的方法：
Chion82/kcptun-raw#2 (comment)

[wangyu-]

@linhua55

好方法，收藏了。

[PHCSJC]

期待早日出win版本

[PHCSJC]

好像在更新0911版本后，打开网页的速度慢了。

[wangyu-]

好像在更新0911版本后，打开网页的速度慢了。

我用iperf3测了一下，结果跟之前是一样的。可能是网络本身的问题，再观察观察吧。

[PHCSJC]

好的，再观察看看。

[PHCSJC]

又测了一下，发现如果在看视频的同时去看别的走udp2raw的网站，延时会大，估计有0.5-2秒吧，而用kcptun+ss就不会有这么明显。

[PHCSJC]

实际上建立的不是udp连接，是raw socket的连接，因为使用了信道复用(multiplex)的方法，下层连接只有一条，而且目前只能是一条。

刚看到这个，和这个是否有些关系呢？

[wangyu-]

又测了一下，发现如果在看视频的同时去看别的走udp2raw的网站，延时会大，估计有0.5-2秒吧，而用kcptun+ss就不会有这么明显。

有延迟变大本身是正常的。至于为什么更明显，这个测试过于笼统，具体原因我也无法确定。可能你额外套上udp2raw后CPU占用变高了；也可能是你用了udp2raw后视频的下载速度变快了，挤占了打开网页的带宽；也许像好像在更新0911版本后，打开网页的速度慢了一样，是网络环境本身波动造成的。

实际上建立的不是udp连接，是raw socket的连接，因为使用了信道复用(multiplex)的方法，下层连接只有一条，而且目前只能是一条。
刚看到这个，和这个是否有些关系呢？

应该不是，如果你的kcptun没特意改过相关参数的话，底层的连接也是只有一条。