frp
frp copied to clipboard
P2P MODE READ UDP I/O TIMEOUT FREQUENTLY HAPPENS and YAMUX CONNECTION ERROR
Bug Description
Hi, I am using frp for NAT Penetration, and I have already succeed in a short moment that I can browser a webpage or setup a SSH connection through this xtcp, the frp can shows "nat hole connection make success". (Means the NAT devices in my network is able to be penertrated.) However, this normal time did not last long, while I was downloading a quite big file throuh IIS, at first, it begun download at around speed 550kB/s *(though the normal uploading speed in my IIS server is ~3MB/s and download speed is ~30MB/s in my IIS client.) * But a short time later a WARNING appeared in the console, the connection broke and could not be re-established whatever I tried: get sid from visitor error: read udp 10.63.xxx.xxx:49569: i/o timeout. and the similar one appeared in the visitor's console: get sid from client error: read udp 192.168.0.8:62182->114.xxx.xxx.131:12145: i/o timeout Moreover, I cannot make a parallel download with IDMan, with the following ERROR message: accept for yamux connection error: keepalive timeout
Could you plz help me with this problem, thanks a loooot!
frpc Version
0.37.0
frps Version
0.37.0
System Architecture
windows/amd64
Configurations
[p2p_mewebdav_tcp] type = xtcp sk = sksksk local_ip = 127.0.0.1 local_port = 80
[p2p_mewebdav_visitor] type = xtcp role = visitor server_name = p2p_mewebdav_tcp sk = sksksk bind_addr = 0.0.0.0 bind_port = 8909
Logs
accept for yamux connection error: keepalive timeout get sid from client error: read udp 192.168.0.8:62182->114.xxx.xxx.131:12145: i/o timeout get sid from visitor error: read udp 10.63.xxx.xxx:49569: i/o timeout.
Steps to reproduce
make a xtcp connection in WAN
Affected area
- [ ] Docs
- [ ] Installation
- [X] Performance and Scalability
- [ ] Security
- [ ] User Experience
- [ ] Test and Release
- [ ] Developer Infrastructure
- [ ] Client Plugin
- [ ] Server Plugin
- [ ] Extensions
- [ ] Others
Maybe caused by yamux. This issue needs more time to debug.
I have similar problem. Everthing is same except that only the vistor shows the sid error, and client shows keepalive timeout instead.
xtcp has been refactored and now defaults to using the quic protocol. This issue is now closed.