chion82/kcptun-raw

Kcptun with raw socket and fake TCP headers.

kcptun-raw's Issues

求在Windows流量通过Linux虚拟机连接kcptun-raw的思路

即Windows连接kcptun-raw服务器的办法，谢谢你们

我从腾讯云无法到我的Ramnode

Ramnode的VPS，从公司kcp到VPS正常使用，但是从腾讯云kcp过去一直无法使用
Server命令： /root/soft/kcptun-raw/server 127.0.0.1 10663 107.191.111.222 15663 --mode fast2
Client命令： /root/soft/kcptun-raw/client 107.191.111.222 15663 10.141.111.222 1090 --mode fast2
Server输出：
[root@222 kcptun-raw]# /root/soft/kcptun-raw/server 127.0.0.1 10663 107.191.111.222 15663 --mode fast2
[2017-06-26 17:23:30] fast2 mode enabled.
[2017-06-26 17:23:52] [trans_packet]Server replying SYN+ACK.
[2017-06-26 17:23:53] [trans_packet]Data checksum validation failed. Dropping.
[2017-06-26 17:23:54] [trans_packet]Server replying SYN+ACK.
[2017-06-26 17:24:15] [trans_packet]Server replying SYN+ACK.
[2017-06-26 17:24:16] [trans_packet]Data checksum validation failed. Dropping.
[2017-06-26 17:24:17] [trans_packet]Server replying SYN+ACK.

Client输出：
[root@VM_11_222_centos soft]# /root/soft/kcptun-raw/client 107.191.111.222 15663 10.141.111.222 1090 --mode fast2
[2017-06-26 17:24:15] fast2 mode enabled.
[2017-06-26 17:24:15] Re-init fake TCP connection.
[2017-06-26 17:24:15] [trans_packet]Client sending SYN.
[2017-06-26 17:24:15] [trans_packet]Client replying ACK.
[2017-06-26 17:24:17] Re-init fake TCP connection.
[2017-06-26 17:24:17] [trans_packet]Client sending SYN.
[2017-06-26 17:24:17] [trans_packet]Client replying ACK.

如果Client使用命令：/root/soft/kcptun-raw/client 107.191.111.222 15663 127.0.0.1 1090 --mode fast2 的话，Server端看不到任何信息

这会是什么原因？

连接初始化问题

启动程序有时候初始化不了，需要再启动一次才能完成初始化，这很不方便啊，能不能改成自动重试初始化？
具体就是有时候启动程序只显示 mode enable 而不显示 kcp ready.

这个改版不错，美中不足就是不能利用CPU多核。

内核态filter支持

目前判断raw socket收到的数据包的端口这段逻辑是在用户态实现的。也就是说，所有包都要从内核态传到用户态，影响性能。可以考虑加上bpf filter.这个我测试过，openwrt和桌面linux都是支持的。 代码如下：

struct sock_filter code_tcp[] = {
{ 0x5, 0, 0, 0x00000001 },//0    //jump to 2,dirty hack from tcpdump -d's output
{ 0x5, 0, 0, 0x00000000 },//1
{ 0x30, 0, 0, 0x00000009 },//2
{ 0x15, 0, 6, 0x00000006 },//3
{ 0x28, 0, 0, 0x00000006 },//4
{ 0x45, 4, 0, 0x00001fff },//5
{ 0xb1, 0, 0, 0x00000000 },//6
{ 0x48, 0, 0, 0x00000002 },//7
{ 0x15, 0, 1, 0x0000fffe },//8   //modify this fffe to the port you listen on
{ 0x6, 0, 0, 0x0000ffff },//9
{ 0x6, 0, 0, 0x00000000 },//10
};
int code_tcp_port_index=8;
void init_filter(int port)
{
	sock_fprog bpf;

	bpf.len = sizeof(code_tcp)/sizeof(code_tcp[0]);
	code_tcp[code_tcp_port_index].k=port;
	bpf.filter = code_tcp;
	int dummy;

	int ret=setsockopt(raw_recv_fd, SOL_SOCKET, SO_DETACH_FILTER, &dummy, sizeof(dummy)); //in case i forgot to remove
	if (ret != 0)
	{
		mylog(log_debug,"error remove fiter\n");
		//perror("filter");
		//exit(-1);
	}
	ret = setsockopt(raw_recv_fd, SOL_SOCKET, SO_ATTACH_FILTER, &bpf, sizeof(bpf));
	if (ret != 0)
	{
		mylog(log_fatal,"error set fiter\n");
		//perror("filter");
		myexit(-1);
	}
}

请问，iptables的设定是必须的吗？

如题

能不能在connection_info中加入客户端ip区分不同的客户端？

这样一来就可以一个server实例对应多个client了

cpu占用真的没办法减少吗？有点吃力啊感觉。

全速下载时cpu：
服务器的：

客户端的：

感觉有点吃力啊，cpu在1%以下有可能吗？

一直报Request KCP init

与ss不兼容？

本身似乎是可以用的，映射一个普通端口比如http可以正常使用

[2017-04-21 10:28:51] Re-init fake TCP connection.
[2017-04-21 10:28:51] Trying port 39501
[2017-04-21 10:28:51] [trans_packet]Client sending SYN.
[2017-04-21 10:28:51] [trans_packet]Client replying ACK.
[2017-04-21 10:28:52] Request kcp init
[2017-04-21 10:28:52] kcp ready.
[2017-04-21 10:28:53] kcp ready.
[2017-04-21 10:29:22] New connection conv 1404.
[2017-04-21 10:29:22] Notifying remote new connection. conv=1404
[2017-04-21 10:29:22] New connection conv 1405.
[2017-04-21 10:29:22] Notifying remote new connection. conv=1405
[2017-04-21 10:29:23] Remote notifies closing. conv=1404
[2017-04-21 10:29:23] Closing connection. conv=1404
[2017-04-21 10:29:23] Remote notifies closing. conv=1405
[2017-04-21 10:29:23] Closing connection. conv=1405
[2017-04-21 10:29:23] New connection conv 1406.
[2017-04-21 10:29:23] Notifying remote new connection. conv=1406
[2017-04-21 10:29:23] Remote notifies closing. conv=1406
[2017-04-21 10:29:23] Closing connection. conv=1406
[2017-04-21 10:29:24] New connection conv 1407.
[2017-04-21 10:29:24] Notifying remote new connection. conv=1407
[2017-04-21 10:29:24] Remote notifies closing. conv=1407
[2017-04-21 10:29:24] Closing connection. conv=1407
[2017-04-21 10:29:29] New connection conv 1410.
[2017-04-21 10:29:29] Notifying remote new connection. conv=1410
[2017-04-21 10:29:29] Remote notifies closing. conv=1410
[2017-04-21 10:29:29] Closing connection. conv=1410
[2017-04-21 10:29:31] New connection conv 1411.
[2017-04-21 10:29:31] Notifying remote new connection. conv=1411
[2017-04-21 10:29:31] New connection conv 1412.
[2017-04-21 10:29:31] Notifying remote new connection. conv=1412
[2017-04-21 10:29:32] recv ends. conv=1412
[2017-04-21 10:29:32] Closing connection. conv=1412
[2017-04-21 10:29:32] Notifying remote closing. conv=1412
[2017-04-21 10:29:32] recv ends. conv=1411

[2017-04-21 10:29:07] [trans_packet]Server replying SYN+ACK.
[2017-04-21 10:29:08] Remote notifies re-init KCP connection.
[2017-04-21 10:29:38] Remote notifies new connection. conv=1404
[2017-04-21 10:29:38] Remote notifies new connection. conv=1405
[2017-04-21 10:29:39] recv ends. conv=1404
[2017-04-21 10:29:39] Closing connection. conv=1404
[2017-04-21 10:29:39] Notifying remote closing. conv=1404
[2017-04-21 10:29:39] recv ends. conv=1405
[2017-04-21 10:29:39] Closing connection. conv=1405
[2017-04-21 10:29:39] Notifying remote closing. conv=1405
[2017-04-21 10:29:39] Remote notifies new connection. conv=1406
[2017-04-21 10:29:39] recv ends. conv=1406
[2017-04-21 10:29:39] Closing connection. conv=1406
[2017-04-21 10:29:39] Notifying remote closing. conv=1406
[2017-04-21 10:29:40] Remote notifies new connection. conv=1407
[2017-04-21 10:29:40] recv ends. conv=1407
[2017-04-21 10:29:40] Closing connection. conv=1407
[2017-04-21 10:29:40] Notifying remote closing. conv=1407
[2017-04-21 10:29:45] Remote notifies new connection. conv=1410
[2017-04-21 10:29:45] recv ends. conv=1410
[2017-04-21 10:29:45] Closing connection. conv=1410
[2017-04-21 10:29:45] Notifying remote closing. conv=1410
[2017-04-21 10:29:47] Remote notifies new connection. conv=1411
[2017-04-21 10:29:47] Remote notifies new connection. conv=1412
[2017-04-21 10:29:48] Remote notifies closing. conv=1412
[2017-04-21 10:29:48] Closing connection. conv=1412
[2017-04-21 10:29:48] Remote notifies closing. conv=1411
[2017-04-21 10:29:48] Closing connection. conv=1411
[2017-04-21 10:29:51] Remote notifies new connection. conv=1414
[2017-04-21 10:29:52] recv ends. conv=1414
[2017-04-21 10:29:52] Closing connection. conv=1414
[2017-04-21 10:29:52] Notifying remote closing. conv=1414

但是一旦连接ss，服务器那边就完全收不到了。。。。。

[2017-04-21 10:37:17] [trans_packet]Server replying SYN+ACK.
[2017-04-21 10:37:18] Remote notifies re-init KCP connection.

[2017-04-21 10:37:01] Re-init fake TCP connection.
[2017-04-21 10:37:01] Trying port 34988
[2017-04-21 10:37:01] [trans_packet]Client sending SYN.
[2017-04-21 10:37:01] [trans_packet]Client replying ACK.
[2017-04-21 10:37:02] Request kcp init
[2017-04-21 10:37:02] kcp ready.
[2017-04-21 10:37:02] kcp ready.
[2017-04-21 10:37:03] kcp ready.
[2017-04-21 10:37:15] New connection conv 1708.
[2017-04-21 10:37:15] Notifying remote new connection. conv=1708
[2017-04-21 10:37:15] New connection conv 1710.
[2017-04-21 10:37:15] Notifying remote new connection. conv=1710
[2017-04-21 10:37:16] New connection conv 1713.
[2017-04-21 10:37:16] Notifying remote new connection. conv=1713
[2017-04-21 10:37:16] New connection conv 1714.
[2017-04-21 10:37:16] Notifying remote new connection. conv=1714
[2017-04-21 10:37:16] New connection conv 1716.
[2017-04-21 10:37:16] Notifying remote new connection. conv=1716

Errors at compilation

I got the following error message on make:

trans_packet.c: In function 'check_packet_recv':
trans_packet.c:91:19: error: 'struct tcphdr' has no member named 'dest'
     if (ntohs(tcph->dest) != packetinfo->source_port) {
                   ^~
trans_packet.c:102:22: error: 'struct tcphdr' has no member named 'check'; did you mean 'th_ack'?
     pseudo_tcp_header->check = 0;
                      ^~
trans_packet.c:106:33: error: 'struct tcphdr' has no member named 'doff'; did you mean 'th_off'?
     int payloadlen = size - tcph->doff*4 - iphdrlen;
                                 ^~
trans_packet.c:123:29: error: 'struct tcphdr' has no member named 'check'; did you mean 'th_ack'?
     if (tcp_checksum != tcph->check) {
                             ^~
trans_packet.c:131:69: error: 'struct tcphdr' has no member named 'source'
     (*(packetinfo->on_packet_recv))(inet_ntoa(from_addr), ntohs(tcph->source), buffer + iphdrlen + tcph->doff*4, payloadlen, tcph->seq);
                                                                     ^~
trans_packet.c:131:104: error: 'struct tcphdr' has no member named 'doff'; did you mean 'th_off'?
     (*(packetinfo->on_packet_recv))(inet_ntoa(from_addr), ntohs(tcph->source), buffer + iphdrlen + tcph->doff*4, payloadlen, tcph->seq);
                                                                                                        ^~
trans_packet.c:131:130: error: 'struct tcphdr' has no member named 'seq'; did you mean 'th_seq'?
     (*(packetinfo->on_packet_recv))(inet_ntoa(from_addr), ntohs(tcph->source), buffer + iphdrlen + tcph->doff*4, payloadlen, tcph->seq);
                                                                                                                                  ^~
trans_packet.c: In function 'send_packet':
trans_packet.c:177:9: error: 'struct tcphdr' has no member named 'source'
     tcph->source = htons(packetinfo->source_port);
         ^~
trans_packet.c:178:9: error: 'struct tcphdr' has no member named 'dest'
     tcph->dest = sin.sin_port;
         ^~
trans_packet.c:179:9: error: 'struct tcphdr' has no member named 'seq'; did you mean 'th_seq'?
     tcph->seq = seq;
         ^~
trans_packet.c:180:9: error: 'struct tcphdr' has no member named 'ack_seq'; did you mean 'th_seq'?
     tcph->ack_seq = 0;
         ^~
trans_packet.c:181:9: error: 'struct tcphdr' has no member named 'doff'; did you mean 'th_off'?
     tcph->doff = 5;  //tcp header size
         ^~
trans_packet.c:182:9: error: 'struct tcphdr' has no member named 'fin'
     tcph->fin=0;
         ^~
trans_packet.c:183:9: error: 'struct tcphdr' has no member named 'syn'
     tcph->syn=1;
         ^~
trans_packet.c:184:9: error: 'struct tcphdr' has no member named 'rst'
     tcph->rst=0;
         ^~
trans_packet.c:185:9: error: 'struct tcphdr' has no member named 'psh'
     tcph->psh=0;
         ^~
trans_packet.c:186:9: error: 'struct tcphdr' has no member named 'ack'; did you mean 'th_ack'?
     tcph->ack=0;
         ^~
trans_packet.c:187:9: error: 'struct tcphdr' has no member named 'urg'
     tcph->urg=0;
         ^~
trans_packet.c:188:9: error: 'struct tcphdr' has no member named 'window'
     tcph->window = htons (5840); /* maximum allowed window size */
         ^~
trans_packet.c:189:9: error: 'struct tcphdr' has no member named 'check'; did you mean 'th_ack'?
     tcph->check = 0; //leave checksum 0 now, filled later by pseudo header
         ^~
trans_packet.c:190:9: error: 'struct tcphdr' has no member named 'urg_ptr'
     tcph->urg_ptr = 0;
         ^~
trans_packet.c:193:13: error: 'struct tcphdr' has no member named 'ack'; did you mean 'th_ack'?
         tcph->ack=1;
             ^~
trans_packet.c:209:9: error: 'struct tcphdr' has no member named 'check'; did you mean 'th_ack'?
     tcph->check = csum( (unsigned short*) pseudogram , psize);
         ^~
make[1]: *** [Makefile:7: build] Error 1
make: *** [Makefile:4: default] Error 2

这个项目是 Kcptun 的 C 语言实现吗？

请问是否兼容原版 Kcptun 协议？

SYN flag

Hi.
Can you add to kcptun-raw option - only SYN flag a tcp header ?
All data must is transmitted only with SYN flag. Without 3 way handshake

在Windows上使用的可能性

@Chion82
关于在windows上运行的可能性， 分享一下最近 看 net-speeder 和 finalSpeed 源码的心得：

net-speeder 使用了 pcap来接收，使用libnet来发送。 net-speeder支持openvz (Cooked packet/mode)，因此libnet应该也支持openvz

而finalSpeed 统一使用 pcap来接收和发送，但pcap的发送不支持openvz(Cooked packet/mode)。 因此在openvz上finalSpeed只支持UDP mode，不支持 TCP mode。
https://github.com/the-tcpdump-group/libpcap/blob/f8198434d6d0b1016ee597a7c64723b1b1c48333/pcap-linux.c#L2064
https://wiki.wireshark.org/SLL

而finalSpeed的 TCP mode 的实现， 就是 使用了 绕过内核协议栈 的技术。 在linux机器上使用iptables （drop）来绕过。而在Windows机器上，Windows xp 和 Windows 2003使用 ipseccmd.exe ， 而在其他Windows机器上使用 netsh命令。
详细命令可见：
https://github.com/91yun/finalspeed/blob/master/src/net/fs/server/FSServer.java#L171
https://github.com/91yun/finalspeed/blob/master/src/net/fs/server/FSServer.java#L234

在openwrt上无法工作?

服务端已通过在VMWARE上ubuntu的客户端验证可以正常工作。在openwrt上客户端提示“KCP recv timeout”，tcpdump 在WAN口抓包没有看到RST报文，望大佬看一下
服务端log;
fast2 mode enabled.
[trans_packet]Server replying SYN+ACK.
Remote notifies re-init KCP connection.
[trans_packet]Server replying SYN+ACK.
Remote notifies re-init KCP connection.
[trans_packet]Server replying SYN+ACK.
Remote notifies re-init KCP connection.
Remote notifies re-init KCP connection.
Remote notifies re-init KCP connection.
Remote notifies re-init KCP connection.
Remote notifies re-init KCP connection.
客户端log:

Re-init fake TCP connection.
Trying port 36767
[trans_packet]Client sending SYN.
[trans_packet]Client replying ACK.
Request kcp init
kcp ready.
New connection conv 6952.
Notifying remote new connection. conv=6952
KCP recv timeout. Re-init KCP connection.
Closing connection. conv=6952
Request kcp init
kcp ready.
New connection conv 7046.
Notifying remote new connection. conv=7046
KCP recv timeout. Re-init KCP connection.
Closing connection. conv=7046
Request kcp init
kcp ready.
KCP recv timeout. Re-init KCP connection.
Request kcp init
kcp ready.

Default MTU 1440 may not work in cellular networks

It may be not a bug, but it may cause troubles in celluar networks. It takes quite some time for me to get to the bottom of this issue. I have a kcptun-raw tunnel which works fine through a cable connection, but it won't work through the cellular network of my phone. The cellular network is the 5G network run by China Telcom. After many failures I was determined to find out the cause. Using gdb I found some segments were always stuck in kcp->snd_buf of the client, and the size of segment is quite large, for example 1428. With a speculation that the stuck segments have sizes larger than MTU of the cellular network I tried to change MTU to 1200, then the stuck issue was fixed. It took me quite some time to get this issue fixed. I assume it may also happen to other users. So it may be a good idea to add a note explaining the MTU and lower the default value.

似乎端口被封了

昨天编译了最新版，按教程配置，参数没有加--noseq，用了几个小时体验良好，然后突然断开了连接
client日志
186226 [2017-02-07 15:47:34] recv ends. conv=1317
186227 [2017-02-07 15:47:34] Closing connection. conv=1317
186228 [2017-02-07 15:47:34] Notifying remote closing. conv=1317
186229 [2017-02-07 15:47:34] recv ends. conv=1318
186230 [2017-02-07 15:47:34] Closing connection. conv=1318
186231 [2017-02-07 15:47:34] Notifying remote closing. conv=1318
186232 [2017-02-07 15:47:34] recv ends. conv=1319
186233 [2017-02-07 15:47:34] Closing connection. conv=1319
186234 [2017-02-07 15:47:34] Notifying remote closing. conv=1319
186235 [2017-02-07 15:47:34] recv ends. conv=1320
186236 [2017-02-07 15:47:34] Closing connection. conv=1320
186237 [2017-02-07 15:47:34] Notifying remote closing. conv=1320
186238 [2017-02-07 15:47:34] recv ends. conv=1321
186239 [2017-02-07 15:47:34] Closing connection. conv=1321
186240 [2017-02-07 15:47:34] Notifying remote closing. conv=1321
186241 [2017-02-07 15:49:03] fast2 mode enabled.
186242 [2017-02-07 15:49:03] Re-init fake TCP connection.
186243 [2017-02-07 15:49:03] Trying port 38363
186244 [2017-02-07 15:49:03] [trans_packet]Client sending SYN.
186245 [2017-02-07 15:49:03] [trans_packet]Client replying ACK.
186246 [2017-02-07 15:49:04] Request kcp init
186247 [2017-02-07 15:49:04] kcp ready.
186248 [2017-02-07 16:02:22] fast2 mode enabled.
186249 [2017-02-07 16:02:22] Re-init fake TCP connection.
186250 [2017-02-07 16:02:22] Trying port 31459
186251 [2017-02-07 16:02:22] [trans_packet]Client sending SYN.
186252 [2017-02-07 16:02:22] [trans_packet]Client replying ACK.
186253 [2017-02-07 16:02:23] Request kcp init
186254 [2017-02-07 16:02:23] kcp ready.
186255 [2017-02-07 16:07:38] fast2 mode enabled.
186256 [2017-02-07 16:07:38] Re-init fake TCP connection.
186257 [2017-02-07 16:07:38] Trying port 37698
186258 [2017-02-07 16:07:38] [trans_packet]Client sending SYN.
186259 [2017-02-07 16:07:38] [trans_packet]Client replying ACK.
186260 [2017-02-07 16:07:39] Request kcp init
186261 [2017-02-07 16:07:39] kcp ready.
186262 [2017-02-08 15:10:04] fast2 mode enabled.
186263 [2017-02-08 15:10:04] Disable TCP sequense counter.
186264 [2017-02-08 15:10:05] fast2 mode enabled.
186265 [2017-02-08 15:10:05] Disable TCP sequense counter.
186266 [2017-02-08 15:10:07] fast2 mode enabled.
186267 [2017-02-08 15:10:07] Disable TCP sequense counter.
186268 [2017-02-08 15:10:10] fast2 mode enabled.
186269 [2017-02-08 15:10:10] Disable TCP sequense counter.

server对应时间日志（没管时差）
[2017-02-07 02:47:34] Closing connection. conv=1316
[2017-02-07 02:47:34] Remote notifies closing. conv=1317
[2017-02-07 02:47:34] Closing connection. conv=1317
[2017-02-07 02:47:34] Remote notifies closing. conv=1318
[2017-02-07 02:47:34] Closing connection. conv=1318
[2017-02-07 02:47:34] Remote notifies closing. conv=1319
[2017-02-07 02:47:34] Closing connection. conv=1319
[2017-02-07 02:47:34] Remote notifies closing. conv=1320
[2017-02-07 02:47:34] Closing connection. conv=1320
[2017-02-07 02:47:34] Remote notifies closing. conv=1321
[2017-02-07 02:47:34] Closing connection. conv=1321
[2017-02-07 02:49:03] [trans_packet]Server replying SYN+ACK.
[2017-02-07 02:49:04] Remote notifies re-init KCP connection.
[2017-02-07 03:00:15] fast2 mode enabled.
[2017-02-07 03:02:22] [trans_packet]Server replying SYN+ACK.
[2017-02-07 03:02:23] Remote notifies re-init KCP connection.
[2017-02-07 03:07:37] fast2 mode enabled.
[2017-02-07 03:07:37] Disable TCP sequense counter.
[2017-02-07 03:07:38] [trans_packet]Server replying SYN+ACK.
[2017-02-07 03:07:39] Remote notifies re-init KCP connection.
[2017-02-07 03:20:20] fast2 mode enabled.
[2017-02-07 03:20:20] Disable TCP sequense counter.
[2017-02-07 03:32:32] fast2 mode enabled.

另外看了下在用的时间里server日志有大量连续（client日志对应有连续的notifying remote new connection）
[2017-02-06 22:40:17] Remote notifies new connection. conv=1438
[2017-02-06 22:40:18] Remote notifies new connection. conv=1439
[2017-02-06 22:40:18] Remote notifies new connection. conv=1440
[2017-02-06 22:40:18] Remote notifies new connection. conv=1441
[2017-02-06 22:40:18] Remote notifies new connection. conv=1442
[2017-02-06 22:40:18] Remote notifies new connection. conv=1443
[2017-02-06 22:40:18] Remote notifies new connection. conv=1444
[2017-02-06 22:40:18] Remote notifies new connection. conv=1445
[2017-02-06 22:40:19] Remote notifies new connection. conv=1446
[2017-02-06 22:40:19] Remote notifies new connection. conv=1447
[2017-02-06 22:40:19] Remote notifies new connection. conv=1448
[2017-02-06 22:40:34] Remote notifies new connection. conv=1449
[2017-02-06 22:40:48] Remote notifies new connection. conv=1452

47分似乎还正常传输，49分开始client和server就重复出现那几行了，尝试加上--noseq参数也连不上，kcptun-raw使用的端口换成kcptun用也连不上，似乎端口直接被封了？我看浏览器相当快就connection refused连dns解析都没有，现在换了个端口能用（之前和现在都不是443端口），加上--noseq在试会不会再发生