-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
The build number must be at least 5180 for client binaries distributed by SoftEther Corporation to work #1392
Comments
I also met that issue. BTW, also 4.x client binary is open source. |
The binary is different from the open source code. There is secret sauce in the binary. |
4.x source code: https://github.com/SoftEtherVPN/SoftEtherVPN_Stable |
You're confused with PacketiX VPN, SoftEther Corporation's commercial product. It is commercial proprietary software based on SoftEtherVPN 4.x. PacketiX includes secret source code but SoftEtherVPN is 100% open source. |
Anyway, also SoftEther 4.x is open source. Build it on your own and test. Then you can reproduce the original issue. |
How can you prove the binary is built from the same source? I said I knew it's different because I wrote a client. |
PacketiX VPN is a commercial product that is available in Japan. It's based on SoftEther VPN 4.x, but it's not the exact same. |
Hello. I build the SoftEther VPN 4.0 Stable Edition binaries. SoftEther VPN 4.0 Stable Edition binaries, which are compiled and signed by SoftEther Corporation, have a compatible protocol which is used only for older PacketiX VPN software older than PacketiX VPN Server Build 5180 (released July 2006, commercial version in Japanese market), since some people in Japan still uses it. The protocol of old PacketiX VPN software (older than Build 5180) was different to the current SoftEther VPN Server. To support as many old PacketiX VPN Server versions as possible (including Build 5180 or older) and customers use the latest SoftEther VPN 4.0 installer, we implement the compatible protocol in the SoftEther Corporation's official signed SoftEther VPN Client 4.0 Stable Edition binaries. The compatible protocol will be used only when the destination server is older than Build 5180. The client detects it whether the destination PacketiX VPN Server's Build Number is older than 5180. If the destination PacktiX VPN Server indicates Build Number 0 (zero) to the client, it is regarded as Build 0 (zero). Build 0 is older than Build 5180, then the compatible protocol will be used. SoftEther VPN Server / PacketiX VPN Server must indicates its correct build number to the VPN client in the negotiation phase. All Stable Edition of SoftEther VPN Server (maintained by myself) includes its build number. If you are using Developer Edition of SoftEther VPN Server source code, please check if the BUILD_NUMBER macro is appropriately set. (Sorry I don't know the details of the latest Developer Edition source code.) The compatible protocol for PacketiX VPN Server older than Build 5180 is not included on the open source code to avoid any copyright and patent issue. |
@dnobori Thank you for the clarification. わざわざ説明していただいて申し訳ございません。 |
I think the build number must be a monotonically increasing value and never decreased or reset to zero. BTW, I confirmed v4.36-9754 from the open-source SoftEtherVPN_Stable repo built on my own cannot connect to v5.02.0. |
Perhaps someone breaks the Developer Edition source code. He reset the build number to 0 (zero). |
ビルドナンバーが0にされた経緯は見ていたのでそのあたりは承知しています。 Let's reset the build number to > 9674 when we make a new developer edition release. |
Despite the build number is a monotonically increasing value and never decreased or reset to zero, upstream accidentaly reset it to zero. As a result, The older version of SoftEtherVPN client cannot to connect to 5.x developer version server. To restore compatibility, this commit sets the appropreate build number. See also the upstream GitHub issue. While here, define LIB_DEPENDS pointed out by poudriere QA-test. Obtained from: SoftEtherVPN/SoftEtherVPN#1392 (comment)
Regarding the FreeBSD port, I updated & rebuilt it with a tentative build number 9675. |
We set the build number when building the project: SoftEtherVPN/.ci/azure-pipelines/linux_build.sh Lines 3 to 8 in 43a8070
The number returned by the server is a unique counter for each version (5.02, previously 5.01), as we do for Mumble. https://softether.network/build-number.json We do that because:
In order to fix the protocol issue we can either:
|
I've added a warning when the build number is set to less than 5180 at #1395. This is at least informative to users. What do you think? |
Excellent. Also, feel free to create a pull request to set the default build number to 5180. |
There are a number of places that have hard coded build numbers. I don't know how many are there. Have we considered the consequences? SoftEtherVPN/src/Cedar/Protocol.c Line 3220 in 56bb573
SoftEtherVPN/src/Cedar/Protocol.c Lines 2388 to 2394 in 56bb573
|
I +1 to this way. |
I can't say which way is better because I am just a random guy who started to read the source code several months ago. This is a decade-old project which should has its convention. Back in 2013 the build was 9022 and now it's 9754. I don't know why we can't follow that convention any more and have to start from new. |
I believe the build number should be independent between the two versions. The fact that the protocol version is determined from that instead of the version itself is unfortunate. Before making a final decision I would gather all hardcoded build number checks in the code. |
Despite the build number is a monotonically increasing value and never decreased or reset to zero, upstream accidentaly reset it to zero. As a result, The older version of SoftEtherVPN client cannot to connect to 5.x developer version server. To restore compatibility, this commit sets the appropreate build number. See also the upstream GitHub issue. While here, define LIB_DEPENDS pointed out by poudriere QA-test. Obtained from: SoftEtherVPN/SoftEtherVPN#1392 (comment)
This has been an issue for a long time, since this commit that changed the way build number is handled. (272ec5a)
There are multiple reports from vpnusers forum as well.
https://www.vpnusers.com/viewtopic.php?f=7&t=66845
https://www.vpnusers.com/viewtopic.php?f=7&t=66826
The official binary client (4.x) must have some secret sauce in it that requires the server build to be within some range. (I knew it when writing the iOS client) Otherwise it just forcibly cuts the connection, throwing some error code 13.
Since the build number is no longer set by default, one has to explicitly set it before building like this.
CMAKE_FLAGS="-DBUILD_NUMBER=9674" ./configure
But this is not obvious at all and the real reason is really hard for an ordinary user to find.
Can we set a default build number somewhere in the configure file instead? (At least in each release)
The text was updated successfully, but these errors were encountered: