[Discussion] TeamSpeak 3 Client 3.1 [BETA]

[ScP]

About all the TSDNS reports... please keep in mind we're taling about a pre-release here. Anyway... here's the deal:

Client version 3.1 introduces a new implementation of TSDNS. The resolver will only look for a TSDNS server on top-level SRV records. This means that for a server name like super.fancy.teamspeak.com, the client will *ONLY* search for a TSDNS server with a SRV record named _tsdns._tcp.teamspeak.com. With this first 3.1 release we have started to dramatically inprove our support for SRV records - like honoring priority and weight of SRV records - and we will continue to do so. This is long overdue...

I think it's safe to assume that the TSDNS system will be obsolete at some point in the future as SRV records are far superior.

[VJean]

Attachment 14189
Where are the translations for the permissions?

bug: permissions_ru.qm not loaded

[pid 24641] access("/home/user/TeamSpeak3-Client-3.1beta/translations/qt_ru.qm.qm", R_OK) = -1 ENOENT (No such file or directory)
[pid 24641] access("/home/user/TeamSpeak3-Client-3.1beta/translations/qt_ru.qm", R_OK) = 0
[pid 24641] stat("/home/user/TeamSpeak3-Client-3.1beta/translations/qt_ru.qm", {st_mode=S_IFREG|0664, st_size=158012, ...}) = 0
[pid 24641] open("/home/user/TeamSpeak3-Client-3.1beta/translations/qt_ru.qm", O_RDONLY|O_CLOEXEC) = 11
[pid 24641] access("/home/user/TeamSpeak3-Client-3.1beta/translations/lagos_ru.qm.qm", R_OK) = -1 ENOENT (No such file or directory)
[pid 24641] access("/home/user/TeamSpeak3-Client-3.1beta/translations/lagos_ru.qm", R_OK) = 0
[pid 24641] stat("/home/user/TeamSpeak3-Client-3.1beta/translations/lagos_ru.qm", {st_mode=S_IFREG|0664, st_size=394624, ...}) = 0
[pid 24641] open("/home/user/TeamSpeak3-Client-3.1beta/translations/lagos_ru.qm", O_RDONLY|O_CLOEXEC) = 11
[pid 24641] access("/home/user/TeamSpeak3-Client-3.1beta/translations/ts_core_errors_ru.qm.qm", R_OK) = -1 ENOENT (No such file or directory)
[pid 24641] access("/home/user/TeamSpeak3-Client-3.1beta/translations/ts_core_errors_ru.qm", R_OK) = 0
[pid 24641] stat("/home/user/TeamSpeak3-Client-3.1beta/translations/ts_core_errors_ru.qm", {st_mode=S_IFREG|0664, st_size=21497, ...}) = 0
[pid 24641] open("/home/user/TeamSpeak3-Client-3.1beta/translations/ts_core_errors_ru.qm", O_RDONLY|O_CLOEXEC) = 11

[PeterS]

Regarding permissions_xx.qm not loaded: Looking into that right now. No clue yet. File exists and is good, but Qt refuses to load it. Unsure right now if it's related to the Qt version or our path changes, but seems to be the former.

Edit: Found & fixed

[VJean]

Regarding permissions_xx.qm not loaded: Looking into that right now. No clue yet. File exists and is good, but Qt refuses to load it. Unsure right now if it's related to the Qt version or our path changes, but seems to be the former.

not even load your translation


disable capcha!

Edit: Found & fixed

when the wait for the update client?

[PeterS]

Quick update on further changes addressing problems mentioned in this thread:

- Countries.zip fixed. %APPDATA%\gfx\countries.zip has highest priority, if not found use INSTALL\gfx\countries.zip as fallback.
- Server IP removed from UI, print hostname instead as before. No change to client log.
- permissions_xx.qm are being used again

In addition we fixed a few crashes reported via the crash upload tool (thanks for everyone using that) and overhauled a few of the new dialogs.

I don't know yet when beta-2 will be available. There are a few other issues being looked at at the moment regarding synchronization and I cannot foresee yet if they require a change in the client. As such, I'd rather wait. All of the above are not critical issues which warrant an immediate release.
Right now our focus is on stabilizing the new server infrastructure and get the online addon system live, but latter probably won't happen before end of next week. And Linux 32-bit, but that also won't happen this week anymore. A good part of our team is in Cologne at Gamescom at the moment.

[ScP]

I've added links to the Lua plugin files in the release announcement thread. G15 plugin coming soon.

http://forum.teamspeak.com/threads/126583

[furion37]

Hello,

reading the topic about the new beta version of TeamSpeak 3 i got some question about the changes of TSDNS

5) Overhauled TSDNS
The resolver will only look for a TSDNS server on top-level SRV records. This means that for a server name like super.fancy.teamspeak.com, the client will *ONLY* search for a TSDNS server with a SRV record named _tsdns._tcp.teamspeak.com. With this first 3.1 release we have started to dramatically inprove our support for SRV records - like honoring priority and weight of SRV records - and we will continue to do so.

Using the address sub.domain.extension have I change something in the TSDNS or DNS configuration?

If I want to allow the connection with only one address, for example ts3.domain.extension, how to configure that? Can I do without port?

This is my TSDNS configuration:

domain.extension=NORESPONSE
ts3.domain.extension=IP ADDRESS:PORT
*.domain.extension=NORESPONSE

This is my DNS configuration:

A - domain.extension => IP ADDRESS
A - ts3.domain.extension => IP ADDRESS
SRV - _ts3._udp.domain.extension => 0 5 PORT ts3.domain.extension
SRV - _tsdns._tcp.domain.extension => 0 5 PORT ts3.domain.extension

[VJean]

ts_core_errors_xx.ts from translation_templates*.zip

    <message>
        <source>ts_core_error_0</source>
        <translation type="unfinished"></translation>
    </message>
    <message>
        <source>ts_core_error_1</source>
        <translation type="unfinished"></translation>
    </message>

ts_core_errors_en.ts from client

    <name>teamspeak_core_error</name>
    <message>
        <source>ts_core_error_0</source>
        <translation>ok</translation>
    </message>
    <message>
        <source>ts_core_error_1</source>
        <translation>undefined error</translation>
    </message>

In package translation_templates.zip wrong ts_core_errors_xx.ts file.
Or add tag <translatorcomment> with strings for translate in ts_core_errors_xx.ts

[numma_cway]

Hello guys,

I use TSDNS for my services but I don't use the official TSDNS server, I use JTSDNS (It is a java implementation with a database behind).
I saw the changelog of this beta and I configured a SRV pointer on my top domain to test it. It works, I can see the requests coming to the server and the TSNDS server replies.

My problem is the following: the tsdns server doesn't reply correctly because he can't find the result in the database. So I searched why and here is my conclusion: you changed the request format: I used wireshark to check the request, here is what I see:
- With the non-beta client: "blabla.ts.mydomain.com" (First image: Part of the Hex dump of the packet)
- With the beta client: "blabla.ts.mydomain.com " (Second image: Part of the Hex dump of the packet) -> there are some spaces or something else after the tsdns domain.

Is it an error? Is it something done on purpose?
It annoys me a bit because I have to contact the JTSDNS developper (Stephan) or decompile it to modify the code, this is why I ask here first if this is normal. I discussed it with other hosters and they also face this problem.

I hope my explaination of the problem is clear. Sorry for the pictures but I don't want to give too much informations so I only let the necessary minimum.

Thanks in advance for your answer

Attachment 14188
Attachment 14187

I would guess that's to support fragmentation at some point in the future. There is no server-side support, though. Stuff must be sent in one packet. E.g. using Windows telnet to connect to a server, you get kicked after typing the first character.

Why is new version showing IP address of a server it's connecting to? Previously, if the client was connecting using domain, only the domain name was shown in general chat tab and since you hid server's IP from server information window it makes no sense to show it (if one would really want to know it then there's a client log).
I know it's just a detail but it kind of saved my machine from DDoS'es as many of annoying "we're closing this server, please connect to our new address: example.com" guys didn't know they're making an attack againts different machine that they intended (TSDNS FTW).

Regarding client log. It can be debated if we want the IP there or not. So far it helped our support and Q/A team to resolve TSDNS issues for our users and customers, so I think it may be problematic to remove them completely. However, it sort of makes hiding the IP from the UI a bit meaningless. I don't know yet what's a good compromise here. Are the DDOS kids really unable to find that info in the logs? Hard to imagine.

Why was this changed at all and...

- Server IP removed from UI, print hostname instead as before. No change to client log.

...why was this reverted then?

About all the TSDNS reports... please keep in mind we're taling about a pre-release here. Anyway... here's the deal:

Client version 3.1 introduces a new implementation of TSDNS. The resolver will only look for a TSDNS server on top-level SRV records. This means that for a server name like super.fancy.teamspeak.com, the client will *ONLY* search for a TSDNS server with a SRV record named _tsdns._tcp.teamspeak.com. With this first 3.1 release we have started to dramatically inprove our support for SRV records - like honoring priority and weight of SRV records - and we will continue to do so. This is long overdue...

I think it's safe to assume that the TSDNS system will be obsolete at some point in the future as SRV records are far superior.

Well, there are situations in which require SRV TSDNS: If you want example.com:9987 and example.com:9988 to point to a server that is not serving the example.com website, you MUST use SRV TSDNS. (There is absolutely no use for plain TSDNS at all, though. Plain TSDNS was removed with this release! This could be stated more clearly.) An option would be defining SRV TS3 with port = 0 as port = input.

Also, the new TSDNS does not work with TLDs that are completely (e.g. ni) or primarily third-level (e.g. nz):

[VJean]

Why was this changed at all and...
...why was this reverted then?

debug version

[ScP]

Also, the new TSDNS does not work with TLDs that are completely (e.g. ni) or primarily third-level (e.g. nz)

Good catch as always mate! Forwarded to the devs...

[BigBear]

About all the TSDNS reports... please keep in mind we're taling about a pre-release here.

Yeah sure and that's why we submit our questions/observations here! As a Teamspeak Hoster my job is to keep an eye on what is coming to ensure that I won't have to play the role of a firefighter trying to save a thousand of users trying to connect to my services.
I hope you also have this kind of professional care in your job...

Please contact me by email (you will find the address at the top of the readme file), if you got an official answer. If this is not an error, I can just do a trim on that String.

Thanks for your answer Stefan, I appreciate it!
By the way, thank you for JTSDNS, it helps me a lot.

I would guess that's to support fragmentation at some point in the future.

Yes, I think you are right but I want the confirmation.

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?

Are the DDOS kids really unable to find that info in the logs? Hard to imagine.

Oh yes, the most of them are really stupid. (They DDoS, that's definitively the proof that they are stupid! It requires more money than skill to DDoS). As I said before TSDNS really helps to "protect" the VOIP machines that's another proof of their intelligence.

Thanks for the modifications!

[Damian1123333]

In the last Update of TeamSpeak 3 I deleted my all Identities wchich I had. I don't know how I do this.. but I would to know How I backup This Identity? Someone help me with this problem?? That is very important for me

[ScP]

In the last Update of TeamSpeak 3 I deleted my all Identities wchich I had. I don't know how I do this.. but I would to know How I backup This Identity? Someone help me with this problem?? That is very important for me

If you've logged out of your account, this is normal behavior as the client will remove all the data that's been uploaded to the cloud. The idea behind this is allowing people to use their accounts and data on other devices and have it wiped when they leave. Logging-in again should bring them back.

However, thanks to some bug reports, our dev team has identified a very rare issue where local data was corrupted. If you're affected by this issue - I hate to be the one who has to tell you this - I guess your identity and bookmarks are lost.

[RedPuma]

The plugin callback

requestHotkeyInputDialog(const char* pluginID, const char* keyword, int isDown, void* qParentWindow)

doesn't work properly anymore for my addon (it was working before the update).
The Dialog itself behaves as usual (shows pressed buttons and disappears when you let go) but the settings aren't saved properly anymore. After I set a hotkey via that function it is actually added to the global teamspeak hotkey list, but the right column ("Action") appears empty. When I then press the hotkey nothing happens, my addon doesn't receive the hotkey command. When I set the hotkey via the global teamspeak hotkey menu it works. I am calling requestHotkeyInputDialog with the proper PluginID and a keyword previously registered in ts3plugin_initHotkeys.