能否提供arm的预编译版本 #1

baggiogogo · 2017-08-07T05:17:41Z

实在不会编译，可否提供，感谢!

wangyu- · 2017-08-07T05:40:43Z

路由器型号是什么？arm也不止一种。
这次我先帮你编译了，然后我出个编译的文档，以后你自己编译吧。
编译很简单，只是需要下载个很大的包。我暂时不想维护更多的预编译版本。

baggiogogo · 2017-08-07T05:46:22Z

树莓派2，kcptun用armv7，谢谢，能提供编译文档甚好，我们自己依葫芦画瓢。

baggiogogo · 2017-08-07T05:48:07Z

另外请教，是否套上这个以后kcptun可以不用加密？

wangyu- · 2017-08-07T05:56:58Z

树莓派的话，你直接在树莓派上sudo apt-get install build-essential 安装好编译环境，然后把代码下载到树莓派，执行make本机编译就可以了，不需要交叉编译。

我手上现在没有树莓派，所以没法这样编译。你先试试，如果不行，晚上我试试能否在电脑上交叉编译个版本给你。

另外请教，是否套上这个以后kcptun可以不用加密？

是这样的。

baggiogogo · 2017-08-07T05:58:40Z

好的，刚才我试过直接make失败，这回下完build-essential再试试，谢谢。

baggiogogo · 2017-08-07T06:04:33Z

你好，不知编译是否通过，log如下：
common.cpp common.h doc encrypt.cpp encrypt.h images lib LICENSE.md log.cpp log.h main.cpp makefile network.cpp network.h README.md
root@ubuntu:/fff/udp2raw-tunnel# make
sudo killall udp2raw||true
sudo: unable to resolve host ubuntu: No such file or directory
udp2raw: no process found
sleep 0.2
g++ main.cpp -o udp2raw -static -ggdb -I. lib/aes.c lib/md5.c encrypt.cpp log.cpp network.cpp common.cpp -lrt -std=c++11 -Wall -Wextra -Wno-unused-variable -Wno-unused-parameter -O3
main.cpp: In function ‘int client_event_loop()’:
main.cpp:1973:30: warning: ignoring return value of ‘ssize_t read(int, void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
read(timer_fd, &value, 8);
^
main.cpp: In function ‘int server_event_loop()’:
main.cpp:2158:30: warning: ignoring return value of ‘ssize_t read(int, void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
read(timer_fd, &dummy, 8);
^
main.cpp:2185:24: warning: ignoring return value of ‘ssize_t read(int, void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
read(fd, &dummy, 8);
^
完成后出现这个文件：udp2raw

baggiogogo · 2017-08-07T06:06:03Z

应该是通过了：
root@ubuntu:/fff/udp2raw-tunnel# ./udp2raw -h
udp2raw-tunnel
version: Aug 7 2017 14:02:09
repository: https://github.com/wangyu-/udp2raw-tunnel

usage:
run as client : ./this_program -c -l local_listen_ip:local_port -r server_ip:server_port [options]
run as server : ./this_program -s -l server_listen_ip:server_port -r remote_ip:remote_port [options]

common options,these options must be same on both side:
--raw-mode avaliable values:faketcp(default),udp,icmp
-k,--key password to gen symetric key,default:"secret key"
--auth-mode avaliable values:aes128cbc(default),xor,none
--cipher-mode avaliable values:md5(default),crc32,simple,none
-a,--auto-rule auto add (and delete) iptables rule
-g,--gen-rule generate iptables rule then exit
--disable-anti-replay disable anti-replay,not suggested
client options:
--source-ip force source-ip for raw socket
--source-port force source-port for raw socket,tcp/udp only
this option disables port changing while re-connecting
other options:
--log-level 0:never 1:fatal 2:error 3:warn
4:info (default) 5:debug 6:trace
--log-position enable file name,function name,line number in log
--disable-color disable log color
--disable-bpf disable the kernel space filter,most time its not necessary
unless you suspect there is a bug
--sock-buf buf size for socket,>=10 and <=10240,unit:kbyte,default:1024
--seqmode seq increase mode for faketcp:
0:dont increase
1:increase every packet
2:increase randomly, about every 3 packets (default)
-h,--help print this help message
一会我把服务端配置好测试，非常感谢。

baggiogogo · 2017-08-07T09:21:42Z

HI,遇到问题
请问ss-redir---->kcptun---->udp2raw-tunnel这样可行吗？

wangyu- · 2017-08-07T10:05:15Z

只要ss-redir---->kcptun可行，ss-redir---->kcptun---->udp2raw-tunnel就可行。udp2raw-tunnel对上层来说是透明的。
至于ss-redir---->kcptun可不可行呢，我没有用过，原理上我觉得可行。

baggiogogo · 2017-08-07T10:23:15Z

可行的，我一直这么用，今天配置udp2raw-tunnel打不通，不清楚哪出问题，一会我把配置发上来。

wangyu- · 2017-08-07T10:39:13Z

不用ss-redir，只用udp2raw-tunnel是否可以连通？是否显示了client ready 和server ready?

如果只用udp2raw-tunnel没问题，我怀疑是ss-redir"劫持"了udp2raw-tunnel的流量，造成了环路，你是否有在iptables对udp2raw-tunnel的端口添加例外？你把iptables贴出来，我看一下。

你也可以先尝试使用udp2raw的icmp模式，看是否可以打通，因为ss-redir不会中转icmp，配置起来可能简单些。

baggiogogo · 2017-08-07T10:42:02Z

只用udp2raw-tunnel可以连通，我也怀疑是iptables的问题，稍等。

baggiogogo · 2017-08-07T10:43:43Z

iptables -t nat -N SHADOWSOCKS

iptables -t nat -A SHADOWSOCKS -d xx.xx.xx.xx -j RETURN
iptables -t nat -A SHADOWSOCKS -d 0.0.0.0/8 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 10.0.0.0/8 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 127.0.0.0/8 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 169.254.0.0/16 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 172.16.0.0/12 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 192.168.0.0/16 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 224.0.0.0/4 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 240.0.0.0/4 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 108.61.10.10 -p tcp --dport 53 -j REDIRECT --to-port 1080
iptables -t nat -A SHADOWSOCKS -d 8.8.8.8 -p tcp --dport 53 -j REDIRECT --to-port 1080
iptables -t nat -A SHADOWSOCKS -m set --match-set chnroute dst -j RETURN
iptables -t nat -A SHADOWSOCKS -p tcp -j REDIRECT --to-port 1080

iptables -t nat -A OUTPUT -p tcp -j SHADOWSOCKS
iptables -t nat -A PREROUTING -p tcp -j SHADOWSOCKS

wangyu- · 2017-08-07T10:49:05Z

添加一条iptables命令：

iptables -t nat -A SHADOWSOCKS -d udp2raw_server_ip/32   --dport  udp2raw_server_port  -j RETURN

也许可以。我手上没有ss-redir的环境，不能测试。

不过我建议你先试一下 --raw-mode icmp是否可以打通。先排除其他方面的原因，再调试tcp模式

baggiogogo · 2017-08-07T10:52:48Z

ss-redir:
{
"server":"127.0.0.1",
"server_port":17372,
"local_address": "0.0.0.0",
"local_port":1080,
"password":"passwd**",
"method": "chacha20-ietf-poly1305",
"timeout":300
}

kcptun:
{
"localaddr": ":17372",
"remoteaddr": "192.168.88.26:10800",
"key": "passwd**",
"crypt": "aes-128",
"mode": "manual",
"conn": 4,
"autoexpire": 160,
"mtu": 1400,
"sndwnd": 128,
"rcvwnd": 256,
"datashard": 5,
"parityshard": 5,
"dscp": 46,
"nocomp": true,
"acknodelay": false,
"nodelay": 0,
"interval": 20,
"resend": 0,
"nc": 1,
"sockbuf": 4194304,
"keepalive": 10
}

udp2raw:
/kcptun/udp2raw -c -r 108.x.x.x:27372 -l 0.0.0.0:10800 --raw-mode faketcp -a -k "passwd**"

好的，一会我试试icmp，上面是配置文件。

baggiogogo · 2017-08-07T11:07:50Z

报告,icmp打通了，配置没有问题，估计就是iptables搞得鬼，我去试试。

wangyu- · 2017-08-07T11:17:54Z

好的。运营商对icmp也会做qos，长久来说最好用--raw-mode faketcp。

baggiogogo · 2017-08-07T11:20:47Z

坏消息，加了那条iptables依然不通，不过我想起件事情，好像那时实验kcptun-raw正常也没打通过，后来用seq通了，不过时间太久远，我记不太清，今天尝试seq也没打通。

但是kcpraw是可以用的。

wangyu- · 2017-08-07T11:34:24Z

你运行iptables-save看一下，那条命令是否加在了最前面？直接运行iptables -A是添加在最后面的。
你可以要么把iptables -A换成-I (大写的i)，执行命令。要么把那条规则添加到你的iptables脚本的最前面，然后清空iptables，运行脚本重新添加。

baggiogogo · 2017-08-07T11:36:04Z

最前面的，实际服务器地址也是做了RETURN的。

Chain SHADOWSOCKS (2 references)
pkts bytes target prot opt in out source destination
3 180 RETURN tcp -- * * 0.0.0.0/0 108.x.x.x tcp dpt:27372
2 120 RETURN all -- * * 0.0.0.0/0 108.x.x.x
0 0 RETURN all -- * * 0.0.0.0/0 0.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 10.0.0.0/8
999 59940 RETURN all -- * * 0.0.0.0/0 127.0.0.0/8
0 0 RETURN all -- * * 0.0.0.0/0 169.254.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 172.16.0.0/12
1 52 RETURN all -- * * 0.0.0.0/0 192.168.0.0/16
0 0 RETURN all -- * * 0.0.0.0/0 224.0.0.0/4
0 0 RETURN all -- * * 0.0.0.0/0 240.0.0.0/4
0 0 REDIRECT tcp -- * * 0.0.0.0/0 108.61.10.10 tcp dpt:53 redir ports 1080
335 20100 REDIRECT tcp -- * * 0.0.0.0/0 8.8.8.8 tcp dpt:53 redir ports 1080
71 4529 RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 match-set chnroute dst
669 41960 REDIRECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 redir ports 1080

wangyu- · 2017-08-07T12:02:57Z

我记下这个问题了。以后我考虑加个功能，让udp2raw在2层发包，绕过iptables，杜绝配iptables的麻烦。

现在udp2raw是在3层发包，2层收包。2层是可以绕过iptables的。在3层发包主要是为了简便。

我在写另一个程序，所以这个功能可能要等一等了。

baggiogogo · 2017-08-07T12:06:17Z

没事的，慢慢来。已经非常感谢了，又多了个选择。感谢感谢！

wangyu- · 2017-08-07T14:59:10Z

我把绕过iptables发包的功能实现了，增加了一个选项 --lower-level，带这个选项以后就是2层发包。

例子：

./udp2raw -l 127.0.0.1:3333 -r 45.66.77.88:9966   -c  --raw-mode faketcp -k123 --lower-level eth0#00:23:45:67:89:b9

eth0换成你的默认网络接口，用ifconfig可以查到。 00:23:45:67:89:b9 换成你的网关的mac地址（注意，不是本机的mac地址），用arp命令可以查到。

你的情况应该只要在client端2层发包就可以，server端不需要。代码我已经提交到master里了。

附上我的ifconfig和arp命令的输出，给你参考。

wangyu@debian:~/Desktop/udp2raw-tunnel$ sudo ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:0c:29:cc:1d:0d  
          inet addr:192.168.205.8  Bcast:192.168.205.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fecc:1d0d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:30549 errors:0 dropped:0 overruns:0 frame:0
          TX packets:48082 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:5119888 (4.8 MiB)  TX bytes:23907242 (22.7 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:30248 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30248 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:21438113 (20.4 MiB)  TX bytes:21438113 (20.4 MiB)

wangyu@debian:~/Desktop/udp2raw-tunnel$ sudo arp
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.205.1            ether   00:23:45:67:89:b9   C                     eth0

==updated==
更简单的方法，用ip route和 arp -a命令，获得例子里的eth0#00:23:45:67:89:b9参数。

wangyu@debian:~/Desktop/UDPspeeder$ ip route
default via 192.168.205.1 dev eth0  proto static 
192.168.205.0/24 dev eth0  proto kernel  scope link  src 192.168.205.8
wangyu@debian:~/Desktop/UDPspeeder$ sudo arp -a 192.168.205.1
? (192.168.205.1) at 00:23:45:67:89:b9 [ether] on eth0

运行ip route命令(或route)，显示default的那个就是默认网关的ip和接口名。
运行arp -a <网关的ip>，获得网关的mac。

wangyu- · 2017-08-07T15:02:00Z

暂时比较麻烦，需要指定接口名和mac。好在这两个参数是固定不变的，设置好了以后就不用改了。

以后这两个参数会自动获取。

baggiogogo · 2017-08-07T15:50:58Z

看明白了，我重新下源码编译测试。再次感谢。

baggiogogo · 2017-08-07T16:18:47Z

报告，还是打不通，另外我想起来了，使用kcpraw时应该是--noseq模式通过。

辛苦了，我一会换另一台服务器尝试，会继续在这反馈，好好休息。

wangyu- · 2017-08-07T16:24:52Z

这个没关系的。既然你只用udp2raw不用 ssredir能连接，那就不是seq的问题。

还是按照老样子，先试一下 --lower-level模式不用ssredir能不能连通吧。也许你的eth0#00:23:45:67:89:b9这个参数没设置正确，先排除这个问题。

wangyu- · 2017-08-07T16:26:04Z

你把udp2raw的命令发给我，然后把下面这3个命令的输出发给我。我检查一下。在运行udp2raw -c的机器上执行。

ifconfig
arp
traceroute baidu.com

wangyu- · 2017-08-07T16:35:37Z

执行一下，arp -a 192.168.88.1

还有你的udp2raw client端的命令参数是什么？

baggiogogo · 2017-08-07T16:37:57Z

arp: in 5 entries no match found.

/kcptun/udp2raw -c -r 108.x.x.x:27372 -l 192.168.88.26:10800 --seq-mode 0 -k "passwd**" --lower-level eth0#d4:ca:6d:f3:61:f7 -a

192.168.88.26 0.0.0.0都试过

是--raw-mode faketcp 复制粘贴错了

wangyu- · 2017-08-07T16:42:12Z

wangyu@debian:~/Desktop/tunnels/dup_delay$ sudo arp -a
? (192.168.205.1) at 00:23:45:67:89:b9 [ether] on eth0

我这边输出是这样的。
你的arp不加参数的输出也跟我的不一样。。
我看一下man page，如果你要休息，就明天再试吧。

wangyu- · 2017-08-07T16:47:47Z

eth0#d4:ca:6d:f3:61:f7 这个应该没有填错。你的client server两端都显示了ready?没有异常输出？

baggiogogo · 2017-08-07T16:49:17Z

没有，可以看见正常连接，甚至还有192.168.X.X输出，但就是卡在那，会不会是我用TCP查询DNS惹的祸。

[2017-08-08 00:50:10][INFO]changed state from to client_handshake2 to client_ready
[2017-08-08 00:50:14][INFO]new packet from 127.0.0.1:53600,conv_id=6c21237
[2017-08-08 00:50:15][INFO]new packet from 127.0.0.1:50708,conv_id=88e63cba

比如这样，就卡在这

wangyu- · 2017-08-07T16:50:45Z

没有是说没有异常。但是有ready吧？

baggiogogo · 2017-08-07T16:51:42Z

没有异常,没报错，两段都没报错。

wangyu- · 2017-08-07T16:58:37Z

“卡”在这，是正常的。如果连接出异常，心跳会丢失，然后会显示 client state back to idle,server state back to idle。如果你用--log-level 5,会显示心跳的log。

这就尴尬了。。我觉得今晚暂时搞不定了。
明天可以尝试：

尝试不用udp2raw，确认可以打通，再调试带udp2raw的。然后再尝试不用ss-redir，用普通的ss，看是否可以打通。逐步确认问题出在哪一环节。
或者直接用tcpdump抓包，看在哪一步的包丢了。

多谢反馈问题。我睡了。明天再搞吧。

baggiogogo · 2017-08-07T17:01:23Z

好的，明白。
不用udp2raw是肯定通的，一会我就试试SS-local，反馈在这，你明天可以看，好好休息，晚安。

wangyu- · 2017-08-07T17:01:58Z

好的，晚安。

baggiogogo · 2017-08-07T17:57:45Z

ss-local失败，罢了，明天再说。

wangyu- · 2017-08-07T23:02:16Z

我搭了个ss-local的环境试了一下。可以稳定打通。

client端：
./udp2raw_amd64 -c -l127.0.0.1:4000 -r45.66.77.88:8855  --raw-mode faketcp -a -k"passwd"
./client_linux_amd64 -r "127.0.0.1:4000" -l ":6666" -mode fast2 -mtu 1300
sslocal -b0.0.0.0 -s 127.0.0.1 -p6666 -l9001 -k 'ss123' -m aes-256-cfb

server端：
./udp2raw_amd64 -s -l0.0.0.0:8855 -r 127.0.0.1:4000 -k "passwd" --raw-mode faketcp -a
 ./server_linux_amd64 -t "127.0.0.1:666" -l ":4000" -mode fast2 -mtu 1300
ssserver -p 666 -k ss123 -m aes-256-cfb

你的问题可能是kcptun的mtu设大了（我这边试过1400打不通）。你尝试一下把MTU改成 1000（先尽量改小，调通以后再慢慢改大），client和server端都要改。

上面的命令是我执行成功后一条一条copy过来的。如果还是打不通，你可以尝试一下copy我的命令。

baggiogogo · 2017-08-08T03:19:34Z

好的，我这就是试，还是你专业，预感就是MTU的问题了。

baggiogogo · 2017-08-08T03:50:44Z

你是正确的，通了，果然是MTU的问题，ss-redir直接就通了，都不用是ss-local了。

用kcptun默认的1350也是没问题的，优化惹的祸，不是你测试的话，我大概永远也想不到这个问题，呵呵。

感谢啦！

wangyu- · 2017-08-08T03:54:35Z

好，问题解决了就好。我会加上醒目的LOG，报出前端MTU过大的问题。

wangyu- · 2017-08-08T04:01:00Z

建议MTU设置成1200。MTU越小额外开销越大，但是越稳定。 1200和1400相比，造成的额外开销可以忽略。finalspeed为了稳定性，默认的MTU只有1000，一样不影响他的速度。

baggiogogo · 2017-08-08T04:02:45Z

好的，明白了，已经改1200了。

baggiogogo closed this as completed Aug 7, 2017

wangyu- mentioned this issue Aug 12, 2017

才看到，马上试试~ wangyu-/UDPspeeder#2

Closed

wangyu- added solved and removed solved labels Aug 13, 2017

wangyu- mentioned this issue Aug 18, 2017

在路由上加速kcp的疑问 #18

Closed

yhj39300 mentioned this issue May 13, 2018

Linux 4.14.14内核的问题 #166

Closed

lalalalualua mentioned this issue Feb 6, 2020

请问出现“500 内部服务器错误”如何修复？ #305

Closed

clanet mentioned this issue Jul 22, 2020

提示:[WARN]send returned -1 #336

Open

能否提供arm的预编译版本 #1

能否提供arm的预编译版本 #1

Comments

baggiogogo commented Aug 7, 2017

wangyu- commented Aug 7, 2017

baggiogogo commented Aug 7, 2017

baggiogogo commented Aug 7, 2017

wangyu- commented Aug 7, 2017 • edited

baggiogogo commented Aug 7, 2017

baggiogogo commented Aug 7, 2017

baggiogogo commented Aug 7, 2017

baggiogogo commented Aug 7, 2017

wangyu- commented Aug 7, 2017

baggiogogo commented Aug 7, 2017

wangyu- commented Aug 7, 2017

baggiogogo commented Aug 7, 2017

baggiogogo commented Aug 7, 2017 • edited

wangyu- commented Aug 7, 2017 • edited

baggiogogo commented Aug 7, 2017

baggiogogo commented Aug 7, 2017

wangyu- commented Aug 7, 2017 • edited

baggiogogo commented Aug 7, 2017 • edited

wangyu- commented Aug 7, 2017

baggiogogo commented Aug 7, 2017 • edited

wangyu- commented Aug 7, 2017

baggiogogo commented Aug 7, 2017

wangyu- commented Aug 7, 2017 • edited

wangyu- commented Aug 7, 2017

baggiogogo commented Aug 7, 2017

baggiogogo commented Aug 7, 2017 • edited

wangyu- commented Aug 7, 2017

wangyu- commented Aug 7, 2017 • edited

wangyu- commented Aug 7, 2017 • edited

baggiogogo commented Aug 7, 2017 • edited

wangyu- commented Aug 7, 2017

wangyu- commented Aug 7, 2017

baggiogogo commented Aug 7, 2017 • edited

wangyu- commented Aug 7, 2017

baggiogogo commented Aug 7, 2017

wangyu- commented Aug 7, 2017 • edited

baggiogogo commented Aug 7, 2017

wangyu- commented Aug 7, 2017

baggiogogo commented Aug 7, 2017

wangyu- commented Aug 7, 2017

baggiogogo commented Aug 8, 2017

baggiogogo commented Aug 8, 2017 • edited

wangyu- commented Aug 8, 2017

wangyu- commented Aug 8, 2017

baggiogogo commented Aug 8, 2017

wangyu- commented Aug 7, 2017 •

edited

baggiogogo commented Aug 7, 2017 •

edited

wangyu- commented Aug 7, 2017 •

edited

wangyu- commented Aug 7, 2017 •

edited

baggiogogo commented Aug 7, 2017 •

edited

baggiogogo commented Aug 7, 2017 •

edited

wangyu- commented Aug 7, 2017 •

edited

baggiogogo commented Aug 7, 2017 •

edited

wangyu- commented Aug 7, 2017 •

edited

wangyu- commented Aug 7, 2017 •

edited

baggiogogo commented Aug 7, 2017 •

edited

baggiogogo commented Aug 7, 2017 •

edited

wangyu- commented Aug 7, 2017 •

edited

baggiogogo commented Aug 8, 2017 •

edited