[3.0.12 and above] Allow all client versions to connect

kingston

Contributor
Feb 10, 2016
243
151
128
You can't have any stability issue with the first method as you only patch values and not instructions :)
(don't use the second method ever)
Yes you can. I love your find but i think i won't use it because chances are that older clients are not fully compatible protocol-wise and, in some cases, bad things may happen. I would be the least worried if it was just a client crash. Well perhaps nothing will happen but i'm not ready to take this risk. Wish i could just put my old ios 5.1.1 in... but do i really need to null so many checks in that particular case?
 

ehthe

Retired Staff
Contributor
Apr 26, 2015
1,029
896
216
When I say you can't have any stability issue I am talking exclusively about the patch. There may indeed be stability issue from the server itself not handling correctly the older clients.
but do i really need to null so many checks in that particular case?
The great thing is those are not checks :) they are integers (that are used by the checks, but we don't patch these as they change between versions) so they won't change or become corrupted as new releases come out (well they could if teamspeak decides to change the minclientversion to another version, but anyway they'll just be not found in the binary)
 

kingston

Contributor
Feb 10, 2016
243
151
128
Yes i understood from your first post that they are not checks per se as you are not nulling any commands in this solution. I should use a different phrase: "modify so many checks". Well, still really not sure what they did in 3.0.12.x and why they insist so hard on using 3.0.18.x+. It could make much sense to just force people to finally drop old, insecure versions (i have seen like 5% of my users still using those). Or could be serious compatibility issue. Or could be just "antipiracy" to fight those old, cracked android and ios versions and make some desperate people go and buy newest mobile clients. I guess we will never know for sure.

But then... if there would be any compatibility issues why put a setting like minimal client version at all? It makes no sense and that could mean it's all good to use old clients stability-wise. Unless that setting is old and introduced long ago and they changed their minds with 3.0.12.x so it's not fully compatible since, thus they locked the setting. Or changes are made once for a long time and from now on, even if 3.0.19 or 3.1.0 client comes out people will be still allowed to use 3.0.18.2.

Yet other words i understand it like this: use any version you want as long as it is 3.0.18.2 minimum. In the situation when there is no newer one yet (in stable channel at least) it seems like a hard lock. But once they will come, it will look good and make sense. They probably aren't interested in messing compatibility with every server release so this could be like one time mile stone for the years to come.
 
Last edited:

ehthe

Retired Staff
Contributor
Apr 26, 2015
1,029
896
216
Their official stance about it is : Those versions are insecure
Which is very true ^^
 

kingston

Contributor
Feb 10, 2016
243
151
128
Well then it might be all about the security of clients after all and there are no compatibility issues. Still we can't be sure if they are not hiding something.
 

VJean

Active Member
Jan 28, 2016
16
0
76
Now use the overwrite function to replace these by 0 ;)
replace to 0 - not worked.
for support min version, etc. 3.0.17 (2015-08-04 07:38:33) [1438673913]
need replace 28C52856 to F96BC055
and set virtualserver_min_client_version=1438673913 or below
tested on latest server ver 3.0.12.2 win & linux
 

ehthe

Retired Staff
Contributor
Apr 26, 2015
1,029
896
216
The windows binary won't work but the linux one works. I can assure you it works, tested it multiple times and have production servers with the patch.
 

VJean

Active Member
Jan 28, 2016
16
0
76
2c0500f5e9b793cdb71cc81235ffbdf8.png


e955e9ff2d459174795b5842b3aa8c33.png

83022f1d701ee3eddb0dac0771d6cc82.png

if replace to 0, client not connected: wrong version
 

Aalesund

Member
Feb 3, 2016
7
0
33
Hmmm. Very strange, I tried method 1 by replacing "28 C5 28 56", "D3 8D DF 53", "27 C5 28 56", "D2 8D DF 53" and on the server with original file it works fine. But on the cracked server with this crack (https://r4p3.net/threads/teamspeak-server-crack-3-0-12-3.1389/) It doesn't works.
I'm doing the same in both files (original and cracked) but it works only in original. The cracked version returns "This server requires a newer client version. Please visit Android Market for the latest version."
 

lukasjanra

Active Member
Jan 7, 2016
103
22
65
I tried it on both servers. Look via heidisql or navicat in ts3server.sqlitedb for minimal_client_version and same with android and ios. It can happen that non modified binary already placed values into db.
 

ehthe

Retired Staff
Contributor
Apr 26, 2015
1,029
896
216
Well I didn't test but it should be exactly the same procedure.
 

Wolfie

Active Member
Sep 12, 2015
69
5
80
I tried but I couldn't find some strings.... I tried to edit the Bins, but it didn't worked.....
 

lukasjanra

Active Member
Jan 7, 2016
103
22
65
Well if you want I can send you modified binary for your version but maybe you have it already writen in DB. Can you PM me your ts3server_sqlitedb?
 

Wolfie

Active Member
Sep 12, 2015
69
5
80
Yes, I can. But, can I download original TS3 server (not R4p3's one) and edit it without losing R3p4's licence?
 
Top