-
Notifications
You must be signed in to change notification settings - Fork 21
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
Connection drops fairly quickly with "Broken pipe" #11
Comments
Here's a sample syslog where this occurred:
|
I was getting something rather like this - I could fetch data down the link OK, but sending stuff up (of any size) caused python to go into an infinite loop (100% CPU), which did not transfer pppd session data, and so pppd timed out and the session terminated.
Note two LCP EchoReq sent and no RX. During this time the python process was at 100% CPU spinning the In nxbender/sslconn.py, the
I noticed that in the ~/.netextender configuration file used by the official binary client, there is a (global) line
This seems to fix the problem - the web page submission which was 100% repeat-ably getting the client into the infinite loop now does not do so, and I seem to have a stable connection. I don't believe that 1280 is the optimum size here, just that it's small enough to fit down whatever the actual link MTU is. I suspect that is smaller than 1500 (and hence the original setup was having to fragment everything) because my internet connection is Virgin Media cable (DOCSIS) and the MTU is said to be fixed at 1500 bytes ...
This suggests that a 1514 byte payload will produce fragmented packets, a 1280 byte payload will not. If 1500 is the path max (and it seems to be), then we want to limit to 1500 minus the overhead, which should be:
So looks like we need an MTU option with a conservative default value, which users can tune upwards if they care about performance, and their link is capable of larger packets. |
Yes! It works! Brilliant! Thank you! More exclamation marks!!!! |
There are some comments on #15, this is not really MTU or MSS, just a line length thing in the remote server. But capping it downwards does make the connection stable. |
This appears to be related to the latter comments on #9. When I start a VPN connection with nxBender and then try to move some traffic over it, I get:
This appears to be related to the amount of traffic carried, not the time the connection has been up. It definitely carries traffic for a bit, and can stay up for some minutes if no traffic goes across it, but if I try to copy a large file across it lasts perhaps ten seconds.
Happy to test any changes or provide further information if requested.
The text was updated successfully, but these errors were encountered: