[GH-ISSUE #1949] XTCP: read nat hole client ok package error: EOF #1549

Closed
opened 2026-05-05 12:58:56 -06:00 by gitea-mirror · 5 comments
Owner

Originally created by @simonchen on GitHub (Aug 20, 2020).
Original GitHub issue: https://github.com/fatedier/frp/issues/1949

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.

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)?
frp_0.33.0_linux_amd64

What operating system and processor architecture are you using (go env)?
Server: frp_0.33.0_linux_amd64
Client: MT7621 mipsle

Configures you used:
Server:

[common]
bind_port = 7000
kcp_bind_port = 7000
bind_udp_port = 7100
authentication_method = token
token = 1234
dashboard_port = 7500
dashboard_user = admin
dashboard_pwd = newart
max_pool_count = 50
log_file = /root/frp_0.33.0_linux_amd64/frps.log

ClientA:

[common]
server_addr = {public i/p address}
server_port = 7000
authentication_method = token
token = 1234

[p2p_ssh]
type = xtcp
sk = 1234
local_ip = 192.168.123.1
local_port = 22

ClientB:

[common]
server_addr = {public i/p address}
server_port = 7000
authentication_method = token
token = schmap1221

[p2p_ssh_visitor]
type = xtcp
role = visitor
server_name = p2p_ssh
sk = 1234
bind_addr = 192.168.123.1
bind_port = 1022

Steps to reproduce the issue:

  1. ClientA / ClientB均用的是老毛子固件Padavan,防火墙中的Netfilter中的NAT Type均指定Full Cone NAT
  2. Server配置运行在公网的VPS服务器上,ClientA 和 ClientB都运行在MT7621处理器的内网路由器上
  3. 在ClientB的路由器上运行ssh命令:
    ssh admin@192.168.123.1 -p 1022

Describe the results you received:
ClientB路由器上显示连接失败:
ssh: Connection to admin@192.168.123.1:1022 exited: Remote closed the connection
Server的日志显示:
[xtcp.go:66] [0dc28761da4c8ecd] [p2p_ssh] read nat hole client ok package error: EOF
[xtcp.go:66] [0dc28761da4c8ecd] [p2p_ssh] read nat hole client ok package error: EOF

Describe the results you expected:

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

Can you point out what caused this issue (optional)

Originally created by @simonchen on GitHub (Aug 20, 2020). Original GitHub issue: https://github.com/fatedier/frp/issues/1949 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. 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)?** frp_0.33.0_linux_amd64 **What operating system and processor architecture are you using (`go env`)?** Server: frp_0.33.0_linux_amd64 Client: MT7621 mipsle **Configures you used:** Server: --------- [common] bind_port = 7000 kcp_bind_port = 7000 bind_udp_port = 7100 authentication_method = token token = 1234 dashboard_port = 7500 dashboard_user = admin dashboard_pwd = newart max_pool_count = 50 log_file = /root/frp_0.33.0_linux_amd64/frps.log ClientA: ---------- [common] server_addr = {public i/p address} server_port = 7000 authentication_method = token token = 1234 [p2p_ssh] type = xtcp sk = 1234 local_ip = 192.168.123.1 local_port = 22 **ClientB:** ---------- [common] server_addr = {public i/p address} server_port = 7000 authentication_method = token token = schmap1221 [p2p_ssh_visitor] type = xtcp role = visitor server_name = p2p_ssh sk = 1234 bind_addr = 192.168.123.1 bind_port = 1022 **Steps to reproduce the issue:** 1. ClientA / ClientB均用的是老毛子固件Padavan,防火墙中的Netfilter中的NAT Type均指定Full Cone NAT 2. Server配置运行在公网的VPS服务器上,ClientA 和 ClientB都运行在MT7621处理器的内网路由器上 3. 在ClientB的路由器上运行ssh命令: `ssh admin@192.168.123.1 -p 1022` **Describe the results you received:** ClientB路由器上显示连接失败: **ssh: Connection to admin@192.168.123.1:1022 exited: Remote closed the connection** Server的日志显示: [xtcp.go:66] [0dc28761da4c8ecd] [p2p_ssh] read nat hole client ok package error: EOF [xtcp.go:66] [0dc28761da4c8ecd] [p2p_ssh] read nat hole client ok package error: EOF **Describe the results you expected:** **Additional information you deem important (e.g. issue happens only occasionally):** **Can you point out what caused this issue (optional)**
gitea-mirror 2026-05-05 12:58:56 -06:00
Author
Owner

@Becods commented on GitHub (Aug 20, 2020):

排版有点难看
https://github.com/fatedier/frp/issues/1129

<!-- gh-comment-id:677640721 --> @Becods commented on GitHub (Aug 20, 2020): 排版有点难看 https://github.com/fatedier/frp/issues/1129
Author
Owner

@simonchen commented on GitHub (Aug 23, 2020):

Nobody knows how to resolve this issue?

<!-- gh-comment-id:678730428 --> @simonchen commented on GitHub (Aug 23, 2020): Nobody knows how to resolve this issue?
Author
Owner

@simonchen commented on GitHub (Aug 25, 2020):

排版有点难看
#1129

this doesn't help

<!-- gh-comment-id:679685492 --> @simonchen commented on GitHub (Aug 25, 2020): > 排版有点难看 > #1129 this doesn't help
Author
Owner

@simonchen commented on GitHub (Aug 26, 2020):

排版有点难看
#1129

我认为这个日志明显的定位在xtcp.go第66行:

https://github.com/fatedier/frp/blob/dev/server/proxy/xtcp.go

` go func() {
raw, errRet := msg.ReadMsg(workConn)
if errRet != nil {
xl.Warn("read nat hole client ok package error: %v", errRet)
workConn.Close()
return
}
if _, ok := raw.(*msg.NatHoleClientDetectOK); !ok {
xl.Warn("read nat hole client ok package format error")
workConn.Close()
return
}

				select {
				case sr.NotifyCh <- struct{}{}:
				default:
				}
			}()

`

<!-- gh-comment-id:680667485 --> @simonchen commented on GitHub (Aug 26, 2020): > 排版有点难看 > #1129 我认为这个日志明显的定位在xtcp.go第66行: https://github.com/fatedier/frp/blob/dev/server/proxy/xtcp.go ` go func() { raw, errRet := msg.ReadMsg(workConn) if errRet != nil { xl.Warn("read nat hole client ok package error: %v", errRet) workConn.Close() return } if _, ok := raw.(*msg.NatHoleClientDetectOK); !ok { xl.Warn("read nat hole client ok package format error") workConn.Close() return } select { case sr.NotifyCh <- struct{}{}: default: } }() `
Author
Owner

@github-actions[bot] commented on GitHub (Oct 11, 2020):

Issues go stale after 45d of inactivity. Stale issues rot after an additional 10d of inactivity and eventually close.

<!-- gh-comment-id:706633970 --> @github-actions[bot] commented on GitHub (Oct 11, 2020): Issues go stale after 45d of inactivity. Stale issues rot after an additional 10d of inactivity and eventually close.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/frp#1549
No description provided.