TeamSpeak 3 Problemlösung: Benutzer werden gekickt, Server noch online

  • Hallo netcup Community,
    bis heute hatte ich folgenden Fehler: Beim Start/Neustart des TeamSpeak 3 Servers eines anderen netcup Kunden wurden alle Benutzer auf meinem TeamSpeak Server "gekickt", der Server schien für sie nicht mehr erreichbar zu sein. Nach einem Blick in die Logs stellte sich heraus, dass dieser allerdings noch erreichbar ist.
    Durch den netcup Support erhielt ich den Hinweis, dass es sich hierbei um einen bekannten Bug handelt, der sich durch das binden des Servers an die/eine IP-Adresse des vServers beheben lässt.


    Nun war der Weg für mich etwas holprig, also möchte ich ihn hier für alle Schritt für Schritt darlegen, falls jemand das selbe Problem hat.

    • TeamSpeak speichert Einstellungen für den Server in der INI-Datei ts3server.ini. Diese ist standardmäßig allerdings nicht vorhanden. Man kann sie erstellen, indem man dem dem Server folgendes Argument übergibt:

      Code
      1. ./ts3server_minimal_runscript.sh createinifile=1


      Danach ist eine ts3server.ini im Serververzeichnis vorhanden, die im nächsten Schritt bearbeitet wird.

    • Man öffne ts3server.ini mit seinem bevorzugten Texteditor und ändere die Standarddatei wie folgt. "<IP des vServers>" dabei immer mit der tatsächlichen vServer IP ersetzen.

    • Jetzt muss man dem TeamSpeak Server diese .ini-Datei beim Start noch übergeben, da er sie von alleine nicht einliest. Dazu übergibt man der ausführbaren Serverdatei folgendes Argument: "inifile=ts3server.ini" #add any command line parameters you want to pass here".
      Da es sich sowieso empfiehlt, das mitgelieferte Startscript zu verwenden, habe ich dieses leicht angepasst:

      Code
      1. ; Zeile 5
      2. COMMANDLINE_PARAMETERS="${2}" #add any command line parameters you want to pass here
      3. ; Ändern zu:
      4. COMMANDLINE_PARAMETERS="inifile=ts3server.ini ${2}" #add any command line parameters you want to pass here

    Ich hoffe, mein Beitrag kann noch so manchem anderen helfen, sein TeamSpeak Problem in den Griff zu bekommen. Bei weiteren Fragen stehe ich gerne zur Verfügung.


    -- ozzy

  • Hey, danke dir für diesen Beitrag.
    Keine Ahnung ob dies vielleicht auch mein Problem klärt, ich hatte vorhin das Phänomen dass ich bei
    meinem gerade erst frisch aufgesetzten TS3 Server plötzlich schon zwei Leute drauf hatte, als ich auf diesen gejoint bin.
    Diese schienen auch sichtlich irritiert über diesen Umstand. Ich bin gespannt was dass zu bedeuten hatte.

  • Das ist auch noch ein merkwürdiges Phänomen, was aufgetreten ist. Auf einmal war der andere netcup Kunde, von dem ich oben sprach, bei uns auf dem TeamSpeak Server, obwohl er zu seinem verbunden hatte. Erst so sind wir überhaupt auf die genauen Abhängigkeiten der Probleme/merkwürdigen Phänomene gekommen, aber das scheint zu der Problematik zu gehören und wird auch durch den Fix oben behoben.

  • Da bin ich wirklich beruhigt, dass ich mit diesem Problem nicht allein zu sein scheine.
    Im ersten Augenblick kochte natürlich die Panik hoch, dass man ggf. "gehackt" wurde.
    Man malt sich dann ja die tollsten Dinge aus, da diese IP nur im engeren Kreis derzeit bekannt ist
    und wie gesagt der Server erst seit 20-30 Sekunden online war.
    Mir ist durchaus klar dass ein Server von mehreren Usern genutzt wird, aber hier trat bei mir Verwirrung auf,
    denn meine Private IP wird doch wohl nicht zweimal verwendet werden?


    Ich danke dir jedenfalls wirklich dafür dass du deine Erkenntnisse in dem Bezug mit uns geteilt hast,
    denn bis jetzt habe ich zumindest nicht mehr das Problem dass ich nicht mehr auf den Server "joinen" kann obwohl er gestartet ist.


    Kind regards
    CallHimX

  • Vielen Dank für den deutlichen Hinweis.


    Das Problem ist seitens Teamspeak bekannt. Hier im Forum und bei Google gibt es einige Berichte dazu. Grund dafür ist der Lizenzserver von Teamspeak. Durch die gleiche MAC-Adresse der vServer werden die User teilweise auf die falsche IP geleitet. Der hier beschriebene Lösungsansatz wird allgemein empfohlen.

  • Wir haben das Problem auch mit 2 anderen NetCup Kunden, sie starten ihren Server und unseres verliert die Verbindung.
    Das nutzen der ts3server.ini hilft dabei auch nicht.


    Allerdings bezweifle ich das es am Lizenzserver liegt, dieser müsste ja dann schließlich die gesamte Instanz herunterfahren und nicht nur den einzelnen virtuellen Teamspeak Server?!

  • Es wird nichts heruntergefahren ;)


    Das Lizenzsystem seitens Teamspeak ist schlicht unintelligent umgesetzt (persönliche Meinung des Autors). Wenn der TS so startet das er an keine IP gebunden ist und somit auf 0.0.0.0 horcht, also alle IPs die es ggf. im vServer gibt, wird die TS Serverinstanz am Lizenzserver per MAC Adresse registriert auch wenn keine Lizenz zum Einsatz kommt, bzw. vor allem dann erst recht. Die MAC Adresse ist natürlich gleich für alle vServer die das gleiche ETH Interface nutzen.


    Meldet sich ein Client an einem TS Server an, wird geprüft ob dieser in der Datenbank seitens TS eine Lizenz hat, wenn dies nicht der Fall ist, liefert die TS Datenbank die letzte gestartete Instanz (IP) die auf die gleiche MAC registriert wurde zurück. Dadurch landen die Leute dann auf völlig falschen TS Servern.


    Hinweis: Dies wurde sinngemäß wieder gegeben, wie genau das Lizenzsystem arbeitet ist leider nicht bekannt. Aber dies scheint der technische Vorgang zu sein wenn man sich die Fehler und Problematik genauer anschaut.


    Es ist somit ein Fehler seitens Teamspeak. Der Hersteller scheint bisher auch keine Ambitionen haben dies zu ändern. Leider nimmt man bei Teamspeak offenbar schlichtweg in keinster Weise auf shared Kernel vServer Betreiber oder Kunden Rücksicht. Dass das Problem sehr sehr viele Leute und Anbieter haben, sieht man bei entsprechenden Google Suchen danach.


    Man kann dies beheben in dem man seinen Teamspeak Server so konfiguriert das dieser ausschließlich auf eine konfigurierte IP-Adresse des vServers horcht. Dies muss der Betreiber des Teamspeakservers vornehmen.


    Wir als Support haben keinerlei Einfluß auf diesen Vorgang.