[Discussion] TeamSpeak 3 Client 3.1 [BETA]

[RedPuma]

Second Issue with the new Version:
When I connect to my Server via IPv6 the whole server hangs for every user on it until the IPv6 client has a timeout (which happens because the server isn't reacting anymore). I dont see other clients, I cant switch channels, voice doesn't seem to be transmitted. The server simply stalls. For every user on the server until no IPv6 client is there anymore. The server is running fine when everyone is connected via IPv4. I am using the MariaDB Plugin instead of sqlite.

/Edit: Same is happening on a fresh database i.e. a fresh server.
/Edit2: Connected my phone via LTE so I have a totally independent connection to my server. Server is also dead on my phone while IPv6 client is connected on my PC.

[Jonybat]

Question regarding the ongoing changes to SRV in the server and client...Is it going to be compliant with the spec in terms of priority? More specifically, regarding the client connecting to a lower priority server if the higher priority one is down.


About this beta release in specific:

The sound files exist in "C:\Users\user\AppData\Local\TeamSpeak 3 Client\sound\default"


Thanks for the continued development as always

[Sebi94]

It's annoying, if you don't have an IPv6 address and every server join takes just a few seconds longer, because the client tries to connect via IPv6 first and realises, that it's not possible due of an missing IPv6 address.

Can you please add an option in the settings of the client to dis-/enable IPv6 support, that the client attempts to connect directly via IPv4? Thanks!

[numma_cway]

@RedPuma: What OS/Architecture are you running? I can't reproduce on Debian x64 running an x86 server.

It's annoying, if you don't have an IPv6 address and every server join takes just a few seconds longer, because the client tries to connect via IPv6 first and realises, that it's not possible due of an missing IPv6 address.

Ehm... No?

[AGamer]

Where do I download the 3.1 beta?

[Barungar]

It's annoying, if you don't have an IPv6 address and every server join takes just a few seconds longer, because the client tries to connect via IPv6 first and realises, that it's not possible due of an missing IPv6 address.

If your client is configured OS-sided properly and you don't have any IPv6 adress the DNS resolver shouldn't try to get a AAAA record. But I suppose as with many, many IPv6 issues it's a messy configuration with IPv6 beiing in a kind of half configured and half not working state. So the client might have a IPv6 adress but can't reache any host outside the local network via IPv6.

@RedPuma: Can't reproduce this either. Sever CentOS 6.x 64bit, about 20% of the clients (win10 x64) connect via IPv6 and the other 80% via IPv4 all coexist happyly together on the same server.

[Dorde]

I want to run the beta but i cant because it crashes everytime.Please release a fix asap .

[joshua2504]

Finally! I thought the development of TSSync was quitted, but finally it's comming

but why myteamspeak.com?

[RedPuma]

@RedPuma: What OS/Architecture are you running? I can't reproduce on Debian x64 running an x86 server.

Ubuntu server 16.04 x64
Its somewhat of a strange issue, other ipv6 services work fine on my server. I will try to use a completely fresh installation of the server when I find the time.

[joshua2504]

Could you please tell us a bit more about the used encryption? You're about to sync millions of Identities to your servers.

- Where are the servers located? Germany?
- Why not implement sync feature to TeamSpeak Server so clients can choose where they want to store their stuff?

There are a lot needed improvements at the UI, e.g. here

[ScP]

Finally! I thought the development of TSSync was quitted, but finally it's comming

but why myteamspeak.com?

Could you please tell us a bit more about the used encryption? You're about to sync millions of Identities to your servers.

- Where are the servers located? Germany?
- Why not implement sync feature to TeamSpeak Server so clients can choose where they want to store their stuff?

There are a lot needed improvements at the UI, e.g. here

The idea is that we'll add more and more cloud based features to the My TeamSpeak service over time to improve our products. I guess you could say that TS Sync is basically the first feature of My TeamSpeak.



Our server-clusters are located around the globe (including Europe and North America) to ensure stability and low latency. We did choose not to rely on servers hosted by third parties as we cannot guarantee their availablility. Also, at least one of our biggest upcoming features requires a centralized intrastructure.



About encryption... as I'm not a developer I can't give you any in-depth info, but all the encryption and decryption is happening locally on your devices. At no time we have access to your bookmarks, identities or passwords. Your data is for your eyes only! Therefore it's super important that you backup your account recovery key as we can't help you decrypt any of your data when you loose your password.

[kubax]

As @VJean allready pointed out....

Is this some kind of a joke?

        generatePassword: function(password, email)
        {
            var hmacSHA512 = function (key) {
                var hasher = new sjcl.misc.hmac(key, sjcl.hash.sha512);
                this.encrypt = function ()
                {
                    return hasher.encrypt.apply(hasher, arguments);
                };
            };

            var salt = email.toLowerCase() + "ts3Login" + password;
            var iterations = 10000;
            var bits = 384;
            return sjcl.codec.base64.fromBits(sjcl.misc.pbkdf2(password, salt, iterations, bits, hmacSHA512));
        } 

Why is the complete hash algorithm for the password written in JS this could be easily done in php, where nobody could view the hash algorithm with everything needed to reverse to the original password from the hash?

Also, why didn't anyone answer to VJeans post yet? This is (at least for me) a deal breaker in using this.

[BigBear]

So guys: can I please have an official answer: Is there a reason for the added characters in the TSDNS client request or is it an error?

I still need an answer about that! Can you please ask the dev?

[RedPuma]

@RedPuma: Can't reproduce this either. Sever CentOS 6.x 64bit, about 20% of the clients (win10 x64) connect via IPv6 and the other 80% via IPv4 all coexist happyly together on the same server.

I think I found the issue. The server wasn't stalling, it crashed and was restarted by my systemd script repeatedly.
The following log entry says it all:

2016-08-19 09:30:40.858177|ERROR   |DatabaseQuery |   |db_exec() update clients set client_lastconnected=1471599040, client_totalconnec error: Data too long for column 'client_lastip' at row 1
2016-08-19 09:30:40.858508|CRITICAL|DatabaseQuery |   |Assertion "error == ERROR_ok" failed at ../../../../s/deps/teamspeak_server_lib/src/ts_server/database/db_database.cpp:132;

As I said I am using the MariaDB Plugin with a MySQL Server. The field client_lastip is only varchar 20 which is simply not enough vor IPv6 adresses. I wonder why this isn't an issue with the sqlite implementation because:
http://mgraefe.de/screens/2016_08_19..._34_000123.png

(I cannot post this directly because the varchar line seems to trigger your website protection, I was spending the last 20 minutes trying to get my post to go through)

[RedPuma]

Why is the complete hash algorithm for the password written in JS this could be easily done in php, where nobody could view the hash algorithm with everything needed to reverse to the original password from the hash?

Also, why didn't anyone answer to VJeans post yet? This is (at least for me) a deal breaker in using this.

Showing the hashing algorithm doesn't compromise security if it's done right.
"Everything needed to reverse to the original password from the hash": If you can simply reverse salted SHA512 hashes, even if you know the salt and everything, you might get a nobel price. Submit your paper now and break all encryption in the world!

It's actually better to NOT send the un-hashed password over the wire and have it hashed server-side, even if you are using https.