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

The build number must be at least 5180 for client binaries distributed by SoftEther Corporation to work #1392

Closed
domosekai opened this issue Jun 22, 2021 · 21 comments · Fixed by #1400

Comments

@domosekai
Copy link
Contributor

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)

@metalefty
Copy link
Contributor

I also met that issue. BTW, also 4.x client binary is open source.

@domosekai
Copy link
Contributor Author

The binary is different from the open source code. There is secret sauce in the binary.

@davidebeatrici
Copy link
Member

@metalefty
Copy link
Contributor

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.

@metalefty
Copy link
Contributor

Anyway, also SoftEther 4.x is open source. Build it on your own and test. Then you can reproduce the original issue.

@domosekai
Copy link
Contributor Author

How can you prove the binary is built from the same source? I said I knew it's different because I wrote a client.

@davidebeatrici
Copy link
Member

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.

@dnobori
Copy link
Member

dnobori commented Jun 24, 2021

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.

@domosekai
Copy link
Contributor Author

@dnobori Thank you for the clarification. わざわざ説明していただいて申し訳ございません。
Guys, so can we set a default build number in the dev source to avoid the issue?

@metalefty
Copy link
Contributor

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.
So the issue is not limited to Windows clients. It also reproduced other UNIX-like OSes.

@dnobori
Copy link
Member

dnobori commented Jun 24, 2021

Perhaps someone breaks the Developer Edition source code. He reset the build number to 0 (zero).

@metalefty
Copy link
Contributor

ビルドナンバーが0にされた経緯は見ていたのでそのあたりは承知しています。

Let's reset the build number to > 9674 when we make a new developer edition release.

freebsd-git pushed a commit to freebsd/freebsd-ports that referenced this issue Jun 24, 2021
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)
@metalefty
Copy link
Contributor

Regarding the FreeBSD port, I updated & rebuilt it with a tentative build number 9675.
https://cgit.freebsd.org/ports/commit/?id=eb4461c58f4b03ef2f85ee04a55be17e5d9d8693

@davidebeatrici
Copy link
Member

davidebeatrici commented Jun 24, 2021

We set the build number when building the project:

if [[ "${#SE_BUILD_NUMBER_TOKEN}" -eq 64 ]]; then
VERSION=$(python3 "version.py")
BUILD_NUMBER=$(curl "https://softether.network/get-build-number?commit=${BUILD_SOURCEVERSION}&version=${VERSION}&token=${SE_BUILD_NUMBER_TOKEN}")
else
BUILD_NUMBER=0
fi

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:

  1. Two versions co-exist at the same time:
    • Current: actively developed.
    • Previous: only receives backports.
  2. Windows uses an unsigned 16 bit variable for each version component, meaning that the value can go up to 65535.

In order to fix the protocol issue we can either:

  1. Initialize the counter at 5179 (-1), assigning number 5180 to the first build.
  2. Push a specific build number if PacketiX is detected.
  3. Use a single counter (starting at 9731, 9730 was the last for 5.01), regardless of the version. We will have to get rid of the build number in the manifest file in case we ever reach the limit.

@metalefty
Copy link
Contributor

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?

@davidebeatrici
Copy link
Member

Excellent. Also, feel free to create a pull request to set the default build number to 5180.

@davidebeatrici davidebeatrici changed the title Win 10 official client fails to connect if BUILD_NUMBER is not set properly The build number must be at least 5180 for client binaries distributed by SoftEther Corporation to work Jun 24, 2021
@davidebeatrici
Copy link
Member

@domosekai
Copy link
Contributor Author

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?

UniFormat(tmp2, tmp2_size, _UU(c->ClientBuild >= 9428 ? "NATT_MSG" : "NATT_MSG2"), local_name);

if ((policy->NoSavePassword) || (policy->AutoDisconnect != 0))
{
if (c->ClientBuild < 6560 && InStrEx(c->ClientStr, "client", false))
{
// If NoSavePassword policy is specified,
// only supported client can connect
HLog(hub, "LH_CLIENT_VERSION_OLD", c->Name, c->ClientBuild, 6560);

@metalefty
Copy link
Contributor

Use a single counter (starting at 9731, 9730 was the last for 5.01), regardless of the version. We will have to get rid of the build number in the manifest file in case we ever reach the limit.

I +1 to this way.

@domosekai
Copy link
Contributor Author

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.
If the answer is to separate from the stable branch, one way would be starting at a much bigger number.
However if we stick to 97xx, we had better ensure its comparability to the stable branch, which is at 9754 now.

@davidebeatrici
Copy link
Member

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.

@davidebeatrici davidebeatrici linked a pull request Jun 27, 2021 that will close this issue
mekanix pushed a commit to mekanix/freebsd-ports that referenced this issue Jun 27, 2021
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants