-
Notifications
You must be signed in to change notification settings - Fork 372
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
Not all data in http payload is sent from tunnel client until TCP FIN from webserver sent for files larger than approx 170Kbytes #360
Comments
Hello, From what i have glazed, it seems to be coming from the websocket library (or a miss use of it). The client see the data and correctly forward it to the tunnel but it is not flushed to the network for unknown reason yet. I will investigate more, after i come back from travel (next week). Thank you for the report and test case 🙏 |
Would you mind trying this pre-release and let me know if it fix the issue for you ? https://github.com/erebe/wstunnel/releases/tag/v10.1.2-rc1 |
Made a proper release https://github.com/erebe/wstunnel/releases/tag/v10.1.2 Let me know if it is ok. |
Thank you, I'll test this right now. |
Hi, we're still seeing exactly the same behaviour with release v10.1.2 in our real scenario and in the replication scenario I added to this bug. I've attached fresh pcaps and logs from release v10.1.2: We noticed the version isn't reported in the client side logs. Server:
Client:
|
That's sad, because I don't manage to reproduce it on my side anymore :X I keep you in touch P.s: Thanks again for the detailed report. |
I can't manage to reproduce it anymore on my side sadly, even when removing everything in the between. So I will rely on you. Would you mind starting the client like below, and providing again the logs, the pcap and also now the file export SSLKEYLOGFILE=/tmp/wstunnel.keyfile
export TOKIO_WORKERS=1
sudo -E perf trace -- wstunnel client --log-lvl=TRACE -R tcp://[::]:50000:localhost:49999 wss://192.168.1.10:4443 |
I think I found out the issue with TLS and the websocket librairy. Would you mind giving a try and let me know if you still notice the issue ? |
Hi @erebe, @christopherhibbert is out today and tomorrow so I will test this today and let you know hopefully this morning! |
Hi there @erebe , using @christopherhibbert 's reproduction steps I can not reproduce the issue using v10.1.3-rc1 whereas I can with v10.1.1 |
Glad to hear that 🙏 |
Yes, give me the whole day - I'll be testing all day!! |
OK, I have found a problem. Or a behaviour I think is a problem! I will attempt to replicate pathologically. I will make a portable reproduction BASH script as before. |
Please find attached a BASH script that can be used to recreate the problem. This may be a new issue, it occurs with 10.1.1 and 10.1.3-rc1 (other versions not tested) For cleanest log output, please launch the script on the server-side followed a few seconds later by the client-side. server-side:
|
Hello, I haven't look into the details your report. But if the only remaining issue is the connection try on IPv6. You can disable it with the option. With it wstunnel will try using IPv4 only
P.s: Will check more in depth your report later. |
You sir are a gem! That worked perfectly. Longest now takes... 0.5secs. Was 8.1sec. Thank you very, very much! |
Perfect then ;) I made a proper release https://github.com/erebe/wstunnel/releases/tag/v10.1.3 with the changes. P.s: If you happen to run a business out of wstunnel, feel free to sponsor a coffee 💌 |
Describe the bug
Thanks so much for wstunnel, it's great! I've been working with my colleage James Grant, and we've found an issue we'd appreciate your thoughts on.
Using wstunnel in wss reverse tunnel mode we see that not all data in an http payload is delivered until FIN sent for larger files.
When using ws, then we don't see this issue.
When using wss, we do see this issue.
If we run wstunnel server and client on the same machine using loopback interface we don't see this issue.
To Reproduce
Expected behavior
All data from the HTTP get is returned quickly and before httpd sends the FIN.
Your wstunnel setup
Paste your logs of wstunnel, started with
--log-lvl=DEBUG
, and with thecommand line used
Desktop (please complete the following information):
Client:
Server:
Additional context
Captures attached:
captures.tgz
The text was updated successfully, but these errors were encountered: