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
App reconnects every 2 minutes after update from 0.7.36 to 0.7.37 #1486
Comments
|
Thanks for the answer
It was an existing profile
It's my guess based on timestamps from UI log While I was saving a log I found out it was more descriptive than the one shown in app UI
So turns out server pushes timeout setting and server is to blame But the issue still there although now intervals became ~3 minutes (see client_log ignore ping-restart.txt):
And additionally there two run-time exceptions:
So I'm wondering:
|
The runtime expections are red herrings. Ignore them for this ticket. The default is to still restart a connection, so ignoring ping-restart just gives you the default which is still USR1. The ping restart of 3 10 is very agressive. That means that if there is any 10s hickup, the client will disconnect. And yes for UDP there is a 120s default. You can going back to 0.7.36 but this looks more like some other problem like bad server connection or mismatched control parameter being negotiated so pings are not getting through. So a complete log to look for those problems would be good. |
Okay, I'll keep using the previous version then |
@andronov-alexey well, if you using the old version, this bug will probably not be fixed since I have no idea what is happening in your setup. |
I looked at server logs and found out that SoftEther server breaks the connection after 20 seconds and then the client drops it too after another 10 seconds. Server:
Client:
So I guess the server cant ping the client and drops the connection after timeout. Also "OpenVPN Connect" is working fine with the same config file |
Can you post a whole log? There is something fishy going on but I have no idea what it is. Does it reproduce if you use OpenVPN3 core under general settings? |
I provided two full logs at the earlier reply With OpenVPN3 enabled I can't connect at all with the error: |
I can also send you my ".ovpn" config file if that would help |
I believe I got the same issue. I tried building the APK, and Here are some general information: General information
Description of the issueTCP/UDP connections are restarted after roughly 10s/30s, respectively Logs (from self-built APK)
Configuration fileics-openvpn-config.txt (exported from the app; key & cert removed) Additional information
|
If that commit in OpenVPN is really the offending one, Softether does not implement the OpenVPN protocol correctly. Having repeated ACKs should not trigger a complete meltdown in the protocol |
Can you capture a tcpdump of the connection as pcap? |
Sure! ics-openvpn-tcp-filtered.pcap.gz Both are captured on the Wi-Fi router using WireShark (I'm more familiar with it than tcpdump) and filtered to keep traffic to/from the VPN server only ( |
Yeah, I found the problem. Basically Softether never implemented the protocol correctly: In its code (Proto_OpenVPN.c) there is a code fragement:
while OpenVPN always had up to 8 acks per P_ACK_V1 packet. So basically Softether ignores valid OpenVPN ACK packets and then drops the connection after 2 minutes. |
OpenVPN always allowed 8 ACKs in P_ACK_V1 packets but only used up to 4 in other control packets. Since Softether drops all packets with more than 4 ACKs it also drops legimate P_ACK_V1. See also this issue: schwabe/ics-openvpn#1486
OpenVPN always allowed 8 ACKs in P_ACK_V1 packets but only used up to 4 in other control packets. Since Softether drops all packets with more than 4 ACKs it also drops legimate P_ACK_V1. See also this issue: schwabe/ics-openvpn#1486
Tried SoftEtherVPN/SoftEtherVPN#1610, works for me. |
Thank you very much for the fix! It may take some time for a new release of SoftEther VPN and for network administrators at our department to upgrade, so I need a workaround for now. Besides using an older commit, is limiting the number of ACKs a valid workaround? diff --git a/src/openvpn/reliable.h b/src/openvpn/reliable.h
index 0f3caa34..5455d42e 100644
--- a/src/openvpn/reliable.h
+++ b/src/openvpn/reliable.h
@@ -41,7 +41,7 @@
* @{ */
-#define RELIABLE_ACK_SIZE 8 /**< The maximum number of packet IDs
+#define RELIABLE_ACK_SIZE 4 /**< The maximum number of packet IDs
* waiting to be acknowledged which can
* be stored in one \c reliable_ack
* structure. */ |
OpenVPN always allowed 8 ACKs in P_ACK_V1 packets but only used up to 4 in other control packets. Since Softether drops all packets with more than 4 ACKs it also drops legimate P_ACK_V1. See also this issue: schwabe/ics-openvpn#1486
No. That is absolutley not a good workaround. That would make OpenVPN misbehave like Softether and break with other OpenVPN servers. |
Thank you very much for clarafication! I will switch to 0.7.36 instead. |
@yan12125 try this:
|
This works for both TCP and UDP connections, thanks! |
Closed by commit 02eabb0 |
General information
Hello,
After latest app update to version 0.7.37 app started reconnecting to server every 2 minutes.
The issue goes away when I install previous version 0.7.36
Here's the client logs:
So it seems like new app version (0.7.37) sets some kind of reconnect timeout, for example:
Regards
The text was updated successfully, but these errors were encountered: