[GH-ISSUE #1139] Teamviewer can use UDP hole but frp can't #889

New issue

Closed

opened 2026-05-05 12:34:01 -06:00 by gitea-mirror · 3 comments

gitea-mirror commented

2026-05-05 12:34:01 -06:00

Owner

Originally created by @myrfy001 on GitHub (Mar 16, 2019).
Original GitHub issue: https://github.com/fatedier/frp/issues/1139

Issue is only used for submiting bug report and documents typo. If there are same issues or answers can be found in documents, we will close it directly.
(为了节约时间，提高处理问题的效率，不按照格式填写的 issue 将会直接关闭。)

Use the commands below to provide key information from your environment:
You do NOT have to include this information if this is a FEATURE REQUEST

What version of frp are you using (./frpc -v or ./frps -v)?
0.25.1 and 0.25.0

What operating system and processor architecture are you using (go env)?
Client: MacOS and Windows
Server: Centos

Configures you used:

# [common] is integral section
[common]
# A literal address or host name for IPv6 must be enclosed
# in square brackets, as in "[::1]:80", "[ipv6-host]:http" or "[ipv6-host%zone]:80"
server_addr = x.x.x.x
server_port = 7000
bind_udp_port = 7001


[p2p_tcp]
type = xtcp
sk = abcdefg123
local_ip = 127.0.0.1
local_port = 8000
use_encryption = false
use_compression = false


[p2p_tcp_visitor]
role = visitor
type = xtcp
server_name = p2p_tcp
sk = abcdefg123
bind_addr = 127.0.0.1
bind_port = 9001
use_encryption = false
use_compression = false

Steps to reproduce the issue:
1.
2.
3.

Describe the results you received:
frp can't setup a xtcp connection.
But using wireshark to inspect packets of Teamviewer, I'm sure that the TeamViewer can use the udp to communicate between two computer.

Using wireshark, I can see that TeamViewer send and receive packets normally using udp protocol.
When using frp, both client and visitor side can log make hole successfully, and visitor can send the http GET to the client, and the client can receive the GET request, but the visitor side won't receive the response.

Using Wireshark on both side, I can see that :

the visitor side keep sending the GET request through the UDP many times
the client side can receive the GET via UDP many times
the client side only send response via UDP once
the visitor side can't receive the only response sent by the client side via UDP

In fact, I'm using a computer in Beijing with China Telecomm ISP, another computer is in Hebei province with China Unicomm ISP, and a server with public IP on cloud, I use TeamViewer to control that computer to setup frp at both side.

Describe the results you expected:
frp should setup a xtcp connection

Additional information you deem important (e.g. issue happens only occasionally):

Can you point out what caused this issue (optional)

Originally created by @myrfy001 on GitHub (Mar 16, 2019). Original GitHub issue: https://github.com/fatedier/frp/issues/1139 Issue is only used for submiting bug report and documents typo. If there are same issues or answers can be found in documents, we will close it directly. (为了节约时间，提高处理问题的效率，不按照格式填写的 issue 将会直接关闭。) Use the commands below to provide key information from your environment: You do NOT have to include this information if this is a FEATURE REQUEST **What version of frp are you using (./frpc -v or ./frps -v)?** 0.25.1 and 0.25.0 **What operating system and processor architecture are you using (`go env`)?** Client: MacOS and Windows Server: Centos **Configures you used:** ``` # [common] is integral section [common] # A literal address or host name for IPv6 must be enclosed # in square brackets, as in "[::1]:80", "[ipv6-host]:http" or "[ipv6-host%zone]:80" server_addr = x.x.x.x server_port = 7000 bind_udp_port = 7001 [p2p_tcp] type = xtcp sk = abcdefg123 local_ip = 127.0.0.1 local_port = 8000 use_encryption = false use_compression = false [p2p_tcp_visitor] role = visitor type = xtcp server_name = p2p_tcp sk = abcdefg123 bind_addr = 127.0.0.1 bind_port = 9001 use_encryption = false use_compression = false ``` **Steps to reproduce the issue:** 1. 2. 3. **Describe the results you received:** frp can't setup a xtcp connection. But using wireshark to inspect packets of Teamviewer, I'm sure that the TeamViewer can use the udp to communicate between two computer. Using wireshark, I can see that TeamViewer send and receive packets normally using udp protocol. When using frp, both client and visitor side can log make hole successfully, and visitor can send the http GET to the client, and the client can receive the GET request, but the visitor side won't receive the response. Using Wireshark on both side, I can see that : * the visitor side keep sending the GET request through the UDP many times * the client side can receive the GET via UDP many times * the client side only send response via UDP once * the visitor side can't receive the only response sent by the client side via UDP In fact, I'm using a computer in Beijing with China Telecomm ISP, another computer is in Hebei province with China Unicomm ISP, and a server with public IP on cloud, I use TeamViewer to control that computer to setup frp at both side. **Describe the results you expected:** frp should setup a xtcp connection **Additional information you deem important (e.g. issue happens only occasionally):** **Can you point out what caused this issue (optional)**

gitea-mirror closed this issue

2026-05-05 12:34:02 -06:00

gitea-mirror commented

2026-05-05 12:34:05 -06:00

Author

Owner

@myrfy001 commented on GitHub (Mar 19, 2019):

It seems that the client side is Cone nat and the visitor side is a Symmetric one

@myrfy001 commented on GitHub (Mar 19, 2019): It seems that the client side is Cone nat and the visitor side is a Symmetric one

gitea-mirror commented

2026-05-05 12:34:05 -06:00

Author

Owner

@myrfy001 commented on GitHub (Mar 20, 2019):

Is there any plan that frp will support try near by port in udp punching?
if not, I'm interesting in this problem and maybe to have a try.

I found that the Symmetric in my case is a sequential port allocation one, the new port is old port plus one.

@myrfy001 commented on GitHub (Mar 20, 2019): Is there any plan that frp will support try near by port in udp punching? if not, I'm interesting in this problem and maybe to have a try. I found that the Symmetric in my case is a sequential port allocation one, the new port is old port plus one.

gitea-mirror commented

2026-05-05 12:34:06 -06:00

Author

Owner

@fatedier commented on GitHub (Mar 20, 2019):

@myrfy001 You are welcome to contribute to xtcp.

The key point is that some NAT device will drop follow packages if you send to port with no ack, so maybe we should set an appropriate TTL on udp package.

@fatedier commented on GitHub (Mar 20, 2019): @myrfy001 You are welcome to contribute to xtcp. The key point is that some NAT device will drop follow packages if you send to port with no ack, so maybe we should set an appropriate TTL on udp package.