Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[E] [client.go:171] get connection info from server error 长度错误542393671 #315

Closed
ntgeralt opened this issue Dec 18, 2019 · 14 comments
Labels
bug Something isn't working

Comments

@ntgeralt
Copy link

ntgeralt commented Dec 18, 2019

客户端和服务端是0.251,
服务端在MT7621 PADAVAN 公网路由上
客户端在MT7621 openwrt路由

客户端执行
./npc -server=xx.com:2101 -vkey=mhgat9tm78 -type=tcp

一切连接都还算正常,只是时不时来一句
[E] [client.go:171] get connection info from server error 长度错误542393671

winscp连接npc的地址,scp和sFTP都似乎有时会被断开,当然重连又能用。

另外求指导:openwrt自启动的正确操作。我看网上各种各样都有

@ntgeralt ntgeralt added the bug Something isn't working label Dec 18, 2019
@ffdfgdfg
Copy link
Contributor

ffdfgdfg commented Dec 18, 2019

你的服务端和客户端网络连接质量怎么样啊,是不是在报这个前有close mux这类的信息,另外,麻烦能同时贴一下客户端和服务端的错误日志吗

@ntgeralt
Copy link
Author

ntgeralt commented Dec 20, 2019

是的,nps日志有报close mux
0.251和0.252都存在,电信公网连电信内网
2019/12/20 21:50:12.688 [E] [mux.go:260] mux: read session unpack from connection err EOF
2019/12/20 21:50:12.688 [W] [mux.go:339] close mux
2019/12/20 21:50:12.688 [W] [mux.go:339] close mux

npc就偶尔一句[E] [client.go:171] get connection info from server error 长度错误542393671

@ffdfgdfg
Copy link
Contributor

不会吧,npc没报close mux?这个像是长连接被npc一端关闭了

@ntgeralt
Copy link
Author

ntgeralt commented Dec 21, 2019

还有个问题,穿透路由web。有时载入不完全,类似破图。F5刷新一下解决。其实没什么,也能用。我就反馈下,也不会排查;
Desktop Screenshot 2019 12 22 - 00 46 59 37
Desktop Screenshot 2019 12 22 - 00 47 28 15

同时启用frpc客户端。frpc倒很正常,没这问题

@ffdfgdfg
Copy link
Contributor

这两问题是相关的,连接未发完数据就关闭了,所以显示的内容不完整,主要原因还是客户端与服务端之间保持的一个长连接被关闭了,尚不清楚是什么原因导致的

@AlibabaDAMO
Copy link

@ffdfgdfg 我也遇到过,网络很好的情况下,甚至本地测试,也会破图。怀疑丢包

@ffdfgdfg
Copy link
Contributor

@ffdfgdfg 我也遇到过,网络很好的情况下,甚至本地测试,也会破图。怀疑丢包

本地测试是高并发呢还是长时间呢,我们测了1k并发的情况,在linux下出现了延迟明显上升的现象,trace了很长一段时间,程序一直处于网络block,收不到数据,后来调整了下内核参数现象就缓解很多了,而darwin下面还跑都跑不了。我们尝试在高并发的时候用wireshark抓包看看,但是数据量太大wireshark直接崩溃了。
另一方面,长时间跑的时候,nps建立的tcp长连接也会收不到数据,然后断开连接,进行重连,连上之后偶尔报这个长度错误,几个请求后也没问题了,这个又不好复现,我再跑几天观察观察日志。

@ntgeralt
Copy link
Author

ntgeralt commented Dec 25, 2019

测试环境没什么并发。但环境不会非常好,客户端在公司内网一层又一层里。
运行环境:两路由在纯净固件ssh执行客户端和服务端。

@ffdfgdfg
Copy link
Contributor

ffdfgdfg commented Jan 6, 2020

这个错误疑似在客户端反复断开多路复用连接同时访问nps上该客户端的端口会出现,几个请求后又好了,像是先后两个长连接数据错乱了

@ntgeralt
Copy link
Author

ntgeralt commented Jan 6, 2020

之前存在比较明显问题:npc运行在公司内网padavan路由上。我在家里用WinSCP连过去npc的穿透端口,拷文件时经常被断开。拷200MB文件WinSCP提示断开重连五六次。其实我也不知道是不是网络问题,还是nps问题,nps我运行在公网新路由3上

@ffdfgdfg
Copy link
Contributor

ffdfgdfg commented Jan 6, 2020

现在用的是什么版本呢,网桥采用什么连接,如果是TCP报EOF应该是收到了fin,而如果说中间的防火墙之类的应该只会drop包或者发rst,应该不至于发fin,尝试升级到0.25.4是否有好转

@ntgeralt
Copy link
Author

ntgeralt commented Jan 6, 2020

@ffdfgdfg 0.251.有空我再试试最新版

@cdown
Copy link

cdown commented Jan 14, 2020

542393671是GET decoded为little-endian的四字节integer。可能你发送了错误的protocol (HTTP instead of whatever the code expects)。

请你浏览此处获取更多信息: https://chrisdown.name/2020/01/13/1195725856-and-friends-the-origins-of-mysterious-numbers.html :)

@ntgeralt
Copy link
Author

npc用0.26,我用upx压缩后放到新路由3做客户端,WinSCP连接穿透端口拷贝大文件也不定期会断开。不知道其他朋友是否这样,如果其他人正常,那可能是我搭建环境问题

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants