kcp over udp2raw does not work well

[linnuxx]

mode=client kcp=regular4 inbound_bandwidth=500M outbound_bandwidth=50M

kcptube should listen on 51820, so the wireguard client can connect to this port.

listen_port=51820

this is the port of server side's kcptube

destination_port=5900 destination_address=0.0.0.0 encryption_password=qwerty1234 encryption_algorithm=AES-GCM

mode=server kcp=regular4 inbound_bandwidth=1G outbound_bandwidth=1G

Listening on 59000

listen_port=5900

The port number of server side's wireguard

destination_port=51820

if wireguard and kcptube are running on the same server, use localhost, or 127.0.0.1, or ::1

destination_address=localhost encryption_password=qwerty1234 encryption_algorithm=AES-GCM

./udp2raw_amd64 -c -l0.0.0.0:5900 -ripvps:443 -k "passwd" --raw-mode easy-faketcp --seq-mode 0 --cipher-mode none ./udp2raw -s -l0.0.0.0:443 -r 0.0.0.0:5900 -a -k passwd --raw-mode faketcp --seq-mode 0 --cipher-mode none the command does not want to run.

[cnbatch]

Setting destination_address to 0.0.0.0 will prevent connections from working. While 0.0.0.0 is a valid address for listening, indicating that any address can connect to it, it cannot be used as a destination address for outbound connections.

https://superuser.com/questions/949428/whats-the-difference-between-127-0-0-1-and-0-0-0-0 https://en.wikipedia.org/wiki/0.0.0.0

[linnuxx]

Setting destination_address to 0.0.0.0 will prevent connections from working. While 0.0.0.0 is a valid address for listening, indicating that any address can connect to it, it cannot be used as a destination address for outbound connections.

https://superuser.com/questions/949428/whats-the-difference-between-127-0-0-1-and-0-0-0-0 https://en.wikipedia.org/wiki/0.0.0.0

I set up and made the route like this: wgclient > kcptube > udp2raw > ethernet > vps > udp2raw > kcptube > wgserver.

[cnbatch]

I know what you're trying to do, but I was telling you that for the scenario of this usage, DO NOT set destination_address=0.0.0.0, the correct setting is destination_address=127.0.0.1.

Those two links have already mentioned the background of 0.0.0.0

[linnuxx]

I know what you're trying to do, but I was telling you that for the scenario of this usage, DO NOT set destination_address=0.0.0.0, the correct setting is destination_address=127.0.0.1.

Those two links have already mentioned the background of 0.0.0.0

mode=client kcp=regular4 inbound_bandwidth=500M outbound_bandwidth=50M

kcptube should listen on 51820, so the wireguard client can connect to this port.

listen_port=51820

this is the port of server side's kcptube

destination_port=5900 destination_address=127.0.0.1 encryption_password=qwerty1234 encryption_algorithm=AES-GCM

mode=server kcp=regular4 inbound_bandwidth=1G outbound_bandwidth=1G

Listening on 59000

listen_port=5900

The port number of server side's wireguard

destination_port=51820

if wireguard and kcptube are running on the same server, use localhost, or 127.0.0.1, or ::1

destination_address=127.0.0.1 encryption_password=qwerty1234 encryption_algorithm=AES-GCM

"speedtest" command also does not work.

[cnbatch]

With this configuration, your WireGuard connection's IP address is 127.0.0.1, and your VPS's IP address is 46.174.53.140. In this case, once the WireGuard connection is established, it won't automatically add an entry to the routing table to configure 46.174.53.140 as a direct route. Therefore, you need to manually add a direct route for your VPS IP in the WireGuard configuration file.

Honestly, before delving into network tools, learning fundamental networking basic knowledage is necessary. Otherwise, you'll struggle to formulate proper questions when seeking assistance, and it will be difficult for others to accurately diagnose the root cause of any issues you encounter.

[linnuxx]

With this configuration, your WireGuard connection's IP address is 127.0.0.1, and your VPS's IP address is 46.174.53.140. In this case, once the WireGuard connection is established, it won't automatically add an entry to the routing table to configure 46.174.53.140 as a direct route. Therefore, you need to manually add a direct route for your VPS IP in the WireGuard configuration file.

Honestly, before delving into network tools, learning fundamental networking basic knowledage is necessary. Otherwise, you'll struggle to formulate proper questions when seeking assistance, and it will be difficult for others to accurately diagnose the root cause of any issues you encounter.

Udp2raw client connects to udp2raw server, kcptube client connects to kcptube server through udp2raw tunnel.

[cnbatch]

You don't need to repeat what you want to do over and over again. What you need to do now is:

1. Check the routing table to see if there is a route entry to your VPS IP.
   • If there is no corresponding route entry, please add it in the wireguard configuration file.
2. After wireguard is running, use the ping command to test whether the connection is successful. Ping from the server to the client, and from the client to the server. When using ping, make sure to ping the internal IP of the wireguard VPN.
3. If ping is successful, check the MTU value of wireguard and adjust it to a suitable MTU size.
   • When using ping command, you can force the size of the packets to be sent and also force them not to be fragmented, so gradually adjusting the packet size can determine the minimum value of the MTU.
4. If the ping is not successful, or if you do not understand the above steps, then you can use kcptube to directly connect the two endpoints again, and adjust the bandwidth values in the configuration file to the effective value measured by iperf.
5. If the speed is still only 11Mbps, consider using the fec option of kcptube.
6. A better choice is to use udphop and enable the fec option. Remember to adjust the MTU value of wireguard.
7. If you don't understand and/or can't do the steps from 4 to 6, then I can't help you either.

The steps from 1 to 4 are very basic operations. In particular, ping and iperf are very basic testing tools. If you want to troubleshoot the problem, please learn how to use basic tools and basic network knowledge first.

I cannot teach you basic knowledge again and again in issue comments, nor help you come up with detailed troubleshooting steps again and again, especially those that are not related to my tool. Those basic troubleshooting steps should have been completed by you on your own, and the results should have been reported at the beginning. It has been almost a week now, and you have not done those basic tests. Don't just rely on using speedtest for troubleshooting, it can't identify which node in the middle link is causing the problem.

In addition, it is not recommended to wrap a tcp raw tunnel around kcptube, because kcptube will change its sending port periodically. If the tcp raw tunnel simulates a three-way handshake, wrapping a tcp raw tunnel may cause the latency unstable when the port number changes.

Once again, I emphasize the importance of learning basic networking knowledge and how to use basic tools. Otherwise, you won't understand what others are saying, and communication will be impossible.

Open-source software authors are not your free customer service representatives. Avoid treating them as such when seeking assistance. Also, take a moment to read about The Art of Asking Great Questions.

[linnuxx]

You're just a fool, you don't understand that the provider cuts udp, if you don't believe it, then buy a Russian vps yourself and check, you're just a fool if you blame me, it's not surprising that your kcp-based program is slow because your code is made so that it runs slowly even on a powerful processor.

[cnbatch]

1. According to your iperf test result (which you deleted) on #23, UDP is not limited by the VPS provider.
2. According to the disscussion on v2ex website, Chinese users confirmed Russian VPS did not limit the speed of UDP. https://www.v2ex.com/t/1034681

I've mentioned early on that KCPtube wasn't specifically designed for high-traffic scenario; it's intended to reduce latency. It has already been mentioned in the documentation: https://github.com/cnbatch/kcptube/blob/main/README_EN.md

the main goal of KCP Tube is to reduce latency, rather than focusing on transmitting large amounts of data

Yet, you insist on using KCPTube for transmitting high-traffic of data. I've also mentioned that using UDPHop and enabling the FEC option would be more suitable. I'm also doing this myself: the WireGuard tunnel passes through a UDPHop channel for transmission.

Fool? Just see what you wrote in the configuration file at the begining of this issue: destination_address=0.0.0.0 After explanation at my first reply in this issue, you still didn't understand. Anyone with basic network knowledge, upon seeing the reminder, will recognize the mistake and adjust the configuration accordingly, rather than simply repeating ‘what I want to do’.

Open source software authors are not obligated to provide long-term free basic knowledge tutorials, nor are they obligated to accept abuse.

Due to your comments violating the GitHub Community Guidelines, this issue has been locked.

[cnbatch]

Try https://github.com/lanthora/candy and https://github.com/lanthora/cake If you insist that your VPS provider has UDP limitation.