Beiträge von Sebbo

"Problem" gefunden. Der Befehl "netstat" kürzt diverse Ausgaben, weshalb bei den IPs entsprechend etwas fehlt. Mit dem zusätzlichen Parameter "-W" / "--wide" kann das vollständig angezeigt werden:

$ netstat -tulpen --wide | grep -E "30033|10011|9987"
tcp6       0      0 2001:1608:10:3::5:a:10011 :::*                    LISTEN      1003       179696      11714/ts3server
tcp6       0      0 2001:1608:10:3::5:a:30033 :::*                    LISTEN      1003       179683      11714/ts3server
udp6       0      0 2001:1608:10:3::5:a:9987 :::*                                1003       179692      11714/ts3server


root@ipdc-vs00019:~#
$ netstat -tulpenW | grep -E "30033|10011|9987"
tcp6       0      0 2001:1608:10:3::5:a:10011 :::*                    LISTEN      1003       179696      11714/ts3server
tcp6       0      0 2001:1608:10:3::5:a:30033 :::*                    LISTEN      1003       179683      11714/ts3server
udp6       0      0 2001:1608:10:3::5:a:9987 :::*                                1003       179692      11714/ts3server

Peinlich...

IPv6 Bug oder Feature?

Kann das jemand bestätigen?

$ cat /home/teamspeak-ipv6/ts3server.inidefault_voice_port=9987voice_ip=2001:1608:10:3::5:afiletransfer_port=30033filetransfer_ip=2001:1608:10:3::5:aquery_port=10011query_ip=2001:1608:10:3::5:a[...]

TeamSpeak 3 Server startet erfolgreich und sagt, dass er die IP und Ports auch so verwendet:

$ cat logs/ts3server_2016-06-20__20_35_54.835102_0.log2016-06-20 20:35:54.835163|INFO    |ServerLibPriv |   |TeamSpeak 3 Server 3.0.13 (2016-06-16 08:54:34)[...]2016-06-20 20:35:57.540351|INFO    |FileManager   |   |listening on 2001:1608:10:3::5:a:300332016-06-20 20:35:57.563448|INFO    |Query         |   |listening on 2001:1608:10:3::5:a:10011

$ cat logs/ts3server_2016-06-20__20_35_54.835102_1.log2016-06-20 20:35:57.563128|INFO    |VirtualServer |1  |listening on 2001:1608:10:3::5:a:9987

Schaut man sich nun allerdings die wirklichen Bindungs per Linux Befehl an, sieht man folgende IPs und Ports:

$ netstat -tulpen | grep -E "30033|10011|9987"
tcp6       0      0 2001:1608:10:3::5:10011 :::*                    LISTEN      1003       179696      11714/ts3server
tcp6       0      0 2001:1608:10:3::5:30033 :::*                    LISTEN      1003       179683      11714/ts3server
udp6       0      0 2001:1608:10:3::5::9987 :::*                                1003       179692      11714/ts3server

Der lauscht nun nicht wie angegeben auf die IP Adresse 2001:1608:10:3::5:a, sondern auf 2001:1608:10:3::5 und 2001:1608:10:3::5:, was aber ja nicht die selben sind...

Bei den aktuellen stabilen Versionen entsinne ich mich ja dem "Feature", dass er einfach nicht startet und meldet, dass er auf die IP xyz den Port abc nicht binden kann, da die IP entweder nicht vorhanden ist oder der Port auf dieser IP bereits in Verwendung ist. Ich verstehe daher überhaupt nicht, wie diese Bindings überhaupt zustande kommen können. Interessanterweise läuft und funktioniert dieser TeamSpeak 3 Server auf IPv6 Basis ohne Probleme.

Ok, nutzt du eine ts3server.ini?

Wenn ja, welche IP's sind hier eingetragen? Versuche es mal mit 0.0.0.0, wenn es mit anderen beim NAT Probleme gibt.

Hi,
ich gehe einfach mal Schritt-für-Schritt die Auflösung etc. durch.

$ ping Join-FPS.dePING Join-FPS.de (104.24.115.211) 56(84) bytes of data.64 bytes from 104.24.115.211: icmp_seq=1 ttl=60 time=0.763 ms...

$ ping Join-FPS.dePING Join-FPS.de (104.24.114.211) 56(84) bytes of data.64 bytes from 104.24.114.211: icmp_seq=1 ttl=60 time=0.686 ms...

Die Domain zeigt auf zwei unterschiedliche IP Adressen, wie du oben und nachfolgend siehst:

$ host Join-FPS.deJoin-FPS.de has address 104.24.11[u][b]5[/b][/u].211Join-FPS.de has address 104.24.11[u][b]4[/b][/u].211

Keine Ahnung, ob das von dir so gewollt ist/war oder ob es einfach nur ein doppelter/alter/falscher Eintrag ist.

Mit diesen IP Adressen konnte ich mich jedoch nicht auf den Server verbinden:

Zitat

<17:05:11> Versuche zum Server auf 104.24.114.211 zu verbinden
<17:05:17> Verbindung zum Server fehlgeschlagen

Zitat

<17:05:42> Versuche zum Server auf 104.24.115.211 zu verbinden
<17:05:47> Verbindung zum Server fehlgeschlagen

Wenn ich mich mittels der Domain "Join-FPS.de" verbinde, sieht man dann, dass eine komplett andere IP Adresse verwendet wird:

19.06.2016 14:54:51    ClientUI    Info    Connect to server: Join-FPS.de    19.06.2016 14:54:51    ClientUI    Info    Trying to resolve Join-FPS.de    19.06.2016 14:54:51    TSDNS    Info    DNS resolve successful, "join-fps.de"=104.24.115.211    ***19.06.2016 14:54:51    TSDNS    Info    SRV DNS resolve successful, "_ts3._udp.join-fps.de"=>"dc-124a1c19.join-fps.de:9987" = 92.222.90.224:9987***19.06.2016 14:54:51    ClientUI    Info    Lookup finished: 92.222.90.224 9987 join-fps.de 0 0    19.06.2016 14:54:51    ClientUI    Info    Resolve successful: 92.222.90.224:9987    19.06.2016 14:54:51    ClientUI    Info    Blacklist check ok    19.06.2016 14:54:51    ClientUI    Info    Initiating connection: 92.222.90.224:9987 Join-FPS.de    19.06.2016 14:54:52    ClientUI    Info    Connect status: Connecting 19.06.2016 14:54:52    ClientUI    Info    Connect status: Connected    19.06.2016 14:54:52    ClientUI    Info    Connect status: Establishing connection    19.06.2016 14:54:52    ClientUI    Info    Connect status: Connection established

Mit der IP kann ich mich dann auch direkt verbinden:

Zitat

<17:07:24> Versuche zum Server auf 92.222.90.224 zu verbinden
<17:07:25> Willkommen auf Flames per Second! --|-- Welcome to Flames per Second!

Die Domain zeigt auch nur auf eine IP Adresse:

$ host dc-124a1c19.join-fps.de
dc-124a1c19.join-fps.de has address 92.222.90.224

So, nun zu den Fragen:

• Sind die zwei IP Adressen für die Domain so gewollt? 104.24.115.211, 104.24.114.211
• Wie lauten deine IPtables Forwarding Regeln?
• Welche Software sagt, dass der Server offline ist?
• Was ist der Uptimerobot und wie liest der die Info heraus?

Tutorial an die aktuellen Binarys, sowie für den kommenden IPv6 Support angepasst.

Hallo,

seit einigen Tagen ist es möglich, ein PreRelease, also eine Beta vom neuen TeamSpeak 3 Server herunterzuladen. Dieser unterstützt nun auch endlich das lang erwartete IPv6 Protokoll.

Zitat von CHANGELOG

=== Server Release 3.0.13 1 august 2016
+ ipv6 support
+ improved database performance
+ improved snapshot create/deploy performance
+ Enable "tcp_nodelay" option for server query (less latency)
+ bindinglist command now has a new parameter "subsystem"
- file transfer now only accepts connections from ip addresses that have started an upload /
download. There is a reserve of 20 slots that are allowed to connect even though that particular
ip address did not start an upload/download. This is to support exotic client routing
configurations like tcp load balancers.
- fixed incorrect filetransfer port reported in instanceinfo
- binding voice to the any address (0.0.0.0 / 0::0), which is the default behaviour of the server,
now supports clients connecting to all addresses instead of just the default ip of the network
interface.
* file transfer now only allows an idle time of 2 seconds after connect
* new file transfer implementation
* updated sqlite to 3.11.1
* sqlite db now uses WAL as journal mode
! the new file transfer routines on unix systems now depend on async io (aio*) routines. For
freebsd this probably means you need to load the aio kernel module using 'kldload aio'
! for server query users: ftinitupload/download replies may now omit the ip parameter. If it is
omitted, it means the transfer should be started on the same ip that was currently used by the
server query ip.
! for ftinitupload/download there is now an optional "proto" parameter. See the server query manual
for more info.

Alles anzeigen

Insgesamt werden/haben sich die Performance von Datenbank Abfragen und Snapshots erstellen, sowie einspielen optimiert. Die Performance der Dateitransfers wurde mit Hilfe von async io ebenfalls optimiert. Die wohl größte Neuerung wird die Unterstützung von IPv6 sein.

Dadurch ändern sich in Zukunft einige Einstellmöglichkeiten. Ich nutze im nachfolgenden Beispiel Adressen von example.com - man kann sich also nicht drauf verbinden.

1) Eine TS3 Instanz kann auf mehrere IP Adressen lauschen
Eine durch Komma getrennte Liste mit IP Adressen gibt an, auf welchen IPs die Instanz alles lauschen soll. Hier kann man IPv4 und auch IPv6 Adressen angeben.

Zitat von ts3server.ini

voice_ip=217.160.231.140, 2606:2800:220:1:248:1893:25c8:1946
filetransfer_ip=217.160.231.140, 2606:2800:220:1:248:1893:25c8:1946
query_ip=217.160.231.140, 2606:2800:220:1:248:1893:25c8:1946

2) IPv6 bei der ServerQuery White- und Blacklist
Für die ServerQuery kann man nun auch IPv6 Adressen white- und blacklisten.

Zitat von query_ip_whitelist.txt / query_ip_blacklist.txt

127.0.0.1
::1
217.160.231.140
2606:2800:220:1:248:1893:25c8:1946

3) IPv6 bei TSDNS Einträgen
TSDNS Einträge können nun auf IPv4, sowohl IPv6 Adressen zeigen.

Zitat von tsdns/tsdns_settings.ini

ts3.example.com=217.160.231.140:9987
ipv6-ts3.example.com=[2606:2800:220:1:248:1893:25c8:1946]:9987

Wer einen IPv6 fähigen TS3 Server testen möchte, kann sich hier den 32-Bit Beta Client für Windows herunterladen und sich auf einen Test Server von mir verbinden: ipv6-only-ts3.4g-server.eu

Dieser Test Server ist ausschließlich über IPv6 erreichbar. Wer also keine IPv6 Adresse hat, kommt auf diesen Server auch nicht drauf.

Den Beta Client wird es nur in dieser Version geben. Die anderen Clients wird es erst zum Release der stabilen Version geben.

Die Meldung erhalte ich nicht...

Zitat von Agent_Orange

_ts3._udp.domain.tld 86400 SRV 0 5 Port server[1|2|3|4].domain.tld

Das ist immer der selbe Eintrag, der nur auf unterschiedliche Ziele zeigt.
Du müsstest den wenn dann so anlegen:

_ts3._udp.server1.domain.tld 86400 SRV 0 5 Port server1.domain.tld
_ts3._udp.server2.domain.tld 86400 SRV 0 5 Port server2.domain.tld
_ts3._udp.server3.domain.tld 86400 SRV 0 5 Port server3.domain.tld
...

Wenn die TS3 Server immer auf der selben IP landen, brauchst du auch nur einen A-Record und kannst alles auf die selbe Domain leiten. Lediglich der Port muss dann immer anders sein.

So solltest du dich mit folgenden IPs verbinden können:

• eisernerorden.de (SRV Record)
• server.eisernerorden.de:25000 (A Record)

Geht das nicht?

Hallo @Mogli95,
was hast du denn bereits probiert? Nutzt du überhaupt den DNS Server von Plesk oder vielleicht doch sogar einen externen von deinem Domain Anbieter?

Hallo,

Zitat von ItsJokaful

ich habe derzeit das Problem das mein TeamSpeak (der auf einem Vserver läuft) ab und zu abstürz.

stürzt der TS3 Server Prozess wirklich ab, sodass du ihn wieder starten musst oder verlieren einfach nur alle / sehr viele Clients zeitgleich die Verbindung?

Zitat von Punisher.biz

UTC ist keine Zeitzone.

Eigentlich schon. "UTC" bzw. "UTC 0" ist die Ausgangszeitzone, die auch als Weltzeit bekannt ist. Siehe auch https://de.wikipedia.org/wiki/Koordinierte_Weltzeit für genauere Details.

Zitat von Punisher.biz

In Deutschland haben wir momentan GMT +1

UTC, GMT,... Alles (fast) das gleiche. Wie im obigen Artikel steht, sind die Zeitzonen einfach nur unter anderen Namen bekannt:

• Coordinated Universal Time (UTC)
• Greenwich Mean Time (GMT)

Ob man hier für Deutschland jetzt jedoch UTC +1 oder GMT +1 sagt, ist das gleiche. Sieht man auf der Weltzeitkarte auch sehr gut: https://upload.wikimedia.org/w…dard_World_Time_Zones.png

Zu diesem Problem gibt es einen Copy-Paste FAQ Artikel von TeamSpeak selbst: http://forum.teamspeak.com/thr…em-clock-quot-log-message

Copy-Paste deswegen, weil sie tatsächlich nur 1:1 die Texte von einem größeren Thema zusammengefasst haben, indem sie diese Stellen zitiert haben.

Der genannte Fehler "detected incorrectly running system clock" bedeutet nur, dass ein Client eine Anfrage erstellt hat und die Antwort aber deutlich aus der Vergangenheit oder sogar Zukunft erhalten hat bzw. würde. Das findet TeamSpeak nicht so lustig und schließt daher diese fehlerhafte Verbindung, was dazu führt, dass der Client die Verbindung verliert. Ob man hier jetzt einmal UTC 0 und UTC +1 verwendet ist dabei egal. Die laufenden Uhrzeiten dürfen sich nur nicht zu stark voneinander differenzieren. Man sagt, dass die maximale Grenze hier bei 0,128 Sekunden liegt.

Ein Server hat immer zwei Uhren:

• Hardware Uhr
• Software Uhr

Normalerweise wird die Software Uhr aktuell gehalten und bei bestimmten Zeitdifferenzen wird die Hardware Uhr auf die von der Software Uhr synchronisiert, damit sie immer relativ gleich sind. Ist diese Zeitdifferenz jedoch zu groß, führt das bei einem TS3 Server zu - ich nenne es mal - "fatalen" Fehlern/Problemen, was im Log als einfache "Warnung" gehandhabt wird.

Die Lösung des Problems ist daher, dass man die Zeit mittels NTP Server (= Zeitserver) synchronisiert, damit sie immer möglichst gleich bleibt. Hier sollte man darauf achten, dass der Zeitserver entsprechend schnell antwortet und auch keine Timeouts hat.

Warum eine Uhr vor- oder nachgehen kann, muss ich denke ich nicht erklären. Das sollte längst bekannt sein. Immerhin hatten das die analogen Uhren auch gerne mal, sodass man sie immer wieder mal richtig drehen musste.

Unter Linux ist bisher nur bekannt, dass diverse NTP Synchronisationen derartige Abweichungen haben, dass es dann dennoch zu diesem Problem kommt. Daher muss man hier noch folgende Option in der Konfiguration setzen:

Zitat von /etc/ntpd.conf

tinker step 0

Ob das unter Windows auch der Fall ist, kann ich dir leider nicht sagen. Das müsstest du einfach mal probieren, sobald du die Uhrzeit einmalig manuell synchronisiert und einen bzw. mehrere Zeitserver eingestellt hast.

Nachtrag: Hier ist noch eine kleine Anleitung, wie man eine Zeitsynchronisation unter Windows Servern durchführt/einrichtet: Uhrzeit im Active Directory mit einem externen Zeitserver synchronisieren | mnTechBlog

Die dort genannten Befehle sollten valide sein, da sie auch in der offiziellen Dokumentation von Microsoft so verwendet werden: https://technet.microsoft.com/…ry/cc731191(v=ws.10).aspx

Zitat von master_d

Vielleicht lerne ich diese Probleme einmal kennen, sobald ich meinen DNS-Server selbst betreibe, und somit auch dessen IP mal wechseln kann.

Ohje, viel Spaß beim Setup nach DENIC Rules!

Es gibt sehr viele DNS Server und jeder hat andere TTL Einstellungen. Meine drei hab ich z.B. auf das Minimum von 15 Minuten gesetzt, weil ich die DNS Einträge schnellst möglich haben möchte und nicht erst morgen.

Da ich meine DNS Server als primären und sekundäre verwende, hab ich die Einträge auch sehr schnell, aber Dritte müssen dennoch 15mins oder auch länger warten, weil eben andere DNS Server nur alle 60mins, 12h oder sogar 24h die Einträge aktualisieren.

Wenn ich keinen DNS Server bräuchte, würde ich auch keinen betreiben wollen.

Super, vielen Dank für die Lösung!

@Lavundi in dem Forum hier sprechen alle - bis auf glaub ein oder zwei - deutsch. Auch @Punisher.biz spricht deutsch. Er hat vermutlich nur einen englischen Text kopiert.

Musst dir also nicht die Mühe machen, alles in englisch zu verfassen.

Und das Passwort natürlich auch...

Ggfs. musst du auch noch den UDP Port (9987) anpassen. Das ist der Port, mit dem du dich per TS3 Client auf den TS verbindest.

Der Port 10011 (TCP) ist auch ein Port und ist immer Standard. Der wird für das ServerQuery System verwendet. Siehe auch TeamSpeak 3 ServerQuery Benutzung.

Cool, wie praktisch.

Na dann viel Spaß beim Musik hören!

Mhmm, ok. Schade - hätte ja klappen können.

Wie gesagt: Offiziell kann man das nicht umgehen. Das wurde in TeamSpeak wohl so reinprogrammiert:

Zitat von dante696

This is a wanted behavior and can not be changed anymore.
We try to avoid, that users microphone still sends everything, when the computer is locked. We had some complaints, that a microphone still was sending everything, what happend in a room.

Ich habe deine Frage mal in unsere facebook Gruppe gepostet, da es doch ein eher seltenes Thema ist. Sobald jemand antwortet, leite ich die Antwort hier weiter, wenn es der entsprechende User nicht bereits selbst tut.
Zum Beitrag: https://www.facebook.com/group…rmalink/1107242206014267/

Hallo Jonas,

dieses Verhalten - so wie du es beschreibst - deutet auf einen Fehler seitens des TeamSpeak 3 Servers hin.

Wenn der TS3 Server selbst keine entsprechenden Datei-Berechtigungen auf die Dateien, also den Avatar z.B. hat, kann ihn weder wer löschen, noch anzeigen/downloaden. In der Log-Datei von der Instanz müsste eine entsprechende Meldung stehen, die darauf hindeutet.

Wende dich daher bitte direkt an deinen Hoster des TS3 Servers.

Hallo,
hilft hier die Einstellung "Dauersenden" nicht?

Offiziell heißt es seitens TeamSpeak, dass das nicht umgehbar ist und so gewollt ist, da sich zu viele User darüber aufregten, weil man immer noch alles vom Raum hörte, wenn die Person weg ist/war. Siehe auch http://forum.teamspeak.com/thr…-Lock?p=311481#post311481.

Hallo,
mittels der ts3admin.class kannst du z.B. per PHP-Skript die Info abfragen. Die benötigte Funktion lautet serverInfo():

[virtualserver_total_packetloss_speech] => 0.0000
 [virtualserver_total_packetloss_keepalive] => 0.0000
 [virtualserver_total_packetloss_control] => 0.0000
 [virtualserver_total_packetloss_total] => 0.0000

Hier ist eine Einführung in die ts3admin.class: Webprogrammierung für Teamspeak mit der ts3admin.class