query from XX 127.0.0.1 -> Falsche Nummer bei XX

[markusmarkusz]

|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 53 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account
|INFO    |Query         |   |query from 52 127.0.0.1 issued: login with account

Wie Sie sehen, sehen Sie, dass Ts3 irgendwie die Zahl 52 mag.
Die Frage ist die: Ist das so gewollt, dass in 95% aller Fälle "query from 52.." im Log steht?

[Schlumpi]

Früher war das mal eine bei jeder neuen Session um 1 hochzählende Nummer, die Session-Nummer einer Admin-Session. Heute ist es eine Konstante im 40er und 50er Bereich. Ich würde einen Bug vermuten, der bisher wohl einfach zu unwichtig war, um ihn trotz entsprechender Berichte zu beheben. Ist schon öfter erwähnt worden.

[numma_cway]

Mein "großer Server" mag 73 und Zahlen um die 72. Teilweise mochte der Server auch 38 ganz gerne. Relativ unabhängig von der Hardware.
Mein kleiner Testserver mag 56, läuft allerdings mit der ehemals selben Datenbank, nur ohne Lizenz.

Das Feature existiert seit 3.0.0-beta30 und zerhauen haben sie es mit 3.0.13.

[dante696]

Ich glaube das war eine Änderung um zu verhindern, das Sockets für den Query blockiert werden können.

Aber ganz sicher bin ich mir da im Moment nicht mehr.
Darum wird nochmal mit unserem Entwickler gesprochen und evaluiert.

[Schlumpi]

Eine Session-Nummer wäre schon nicht verkehrt, dann kann man jeden Query-Befehl eindeutig einer Session und dem User zuordnen, der die Session gestartet hat. Bei mehreren Sessions von derselben IP Adresse würde man immer noch sehen, welcher User und welche Session welchen Befehl abgesetzt hat. Der lokale IP-Port ist zur eindeutigen Identifikation nicht ausreichend, denn der wird vom tcp/ip Stack ja recycled.

[dante696]

Im alten Server (vor 3.0.13.x) war Nummer nur ein Zähler ohne richtigen Nutzen für uns.
Im neuen Server zeigt die Zahl den aktuellen "socket descriptor" und dient uns zum Debuggen.
Dass die Zahl so zufällig aussieht ist kein Bug und hängt auch etwas vom Betriebssystem ab.

-----Off-topic
@Schlumpi, das klingt nützlich, aber hat man denn so viele Nutzer mit Query Zugriff in einer Server Instanz um nicht zu wissen wer was getan hat?
Ich persönlich würde Session auch eher so definieren, dass Pro gestarteter Verbindung eine Session existiert. Unabhängig ob ich schon verbunden bin zum Server.

[Schlumpi]

Bezüglich Session-ID: Es geht darum, mit einem einfachen Mittel Klarheit im Logfile herzustellen. Für gewöhnlich gibt es immer nur eine Admin-Session unter einer Userid oder eine voice-Session mit einem Client. Aber es ist möglich, dass mehrere parallel existieren, und falls genau dann ein Problem auftritt, sollte man auch dann in der Lage sein, die Befehle genau zuzuordnen.

Es würde z.B. auch Logfile-Auswerteprogrammen sehr helfen.

Ich habe da die Logs des IBM Tivoli Storage Manager im Hinterkopf - das ist ein Enterprise Backup Programm mit einem zentralen Server, auf das viele Client-Knoten ihre Backups schicken. Sobald mehrere Clients parallel Backup machen, hast du ein heilloses Durcheinander von Logeingträgen im Activity Log. Aber weil TSM für jede Session eine fortlaufende ID vergibt, kann man absolut exakt nachvollziehen wann welcher Client was gemacht hat, und auch mit welcher Session. Schwierig zu erklären, wieso das jetzt nützlich ist, aber es ist dort bei TSM unendlich nützlich, und für Teamspeak, gerade auch für größere Server mit hundert und mehr Clients online, dürfte es ebenfalls recht nützlich sein. Auf größeren Systemen hast du auf einem TSM Server nach einigen Wochen Laufzeit Session-IDs im Bereich 100000 und mehr.
Man würde z.B. sehen, ob eine Session ständig läuft, oder immer wieder neu aufgebaut wird. Das würde möglicherweise Bot-Benutzern beim managen ihres Servers helfen.
Bei Hacker-Zugriffen könnte man genau sehen, welche Logins welcher Session in welcher Abfolge kamen und welche Befehle in welcher Abfolge in welcher Session kamen. Ist das alles von derselben IP Adresse, kann man ohne die Sessions rekonstruieren zu können nicht genau rekonstruieren, wie der Hacker genau vorgegangen ist.

Eine Umsetzung würde so aussehen, dass es einen globalen Session-Zähler im Server gibt, und bei jedem Verbindungsaufbau, also bei jedem Connect, und bereits vor der Authentifizierung, würde man den Zähler eins hochzählen und die neue Zahl in die interne Connection-Info der neuen Verbindung speichern. Die gibt man dann für jeden Logfileeintrag ins Logfile mit aus, der von dieser Verbindung produziert wird.

Die IP Adresse in Verbindung mit der Userid reicht jedenfalls nicht aus, um eine Session zu definieren: es ist ja möglich, dass mehrere Clients hinter derselben IP Adresse eine Verbindung unter demselben Namen aufmachen. Die kann man nur über eine Session-ID auseinanderhalten.

[markusmarkusz]

Im alten Server (vor 3.0.13.x) war Nummer nur ein Zähler ohne richtigen Nutzen für uns.
Im neuen Server zeigt die Zahl den aktuellen "socket descriptor" und dient uns zum Debuggen.
Dass die Zahl so zufällig aussieht ist kein Bug und hängt auch etwas vom Betriebssystem ab.

Dann kann man die Zahl doch ganz entfernen, wenn sie nur für euch zum Debuggen dient und eh zuvor keinen Nutzen hatte.

@Schlumpi, das klingt nützlich, aber hat man denn so viele Nutzer mit Query Zugriff in einer Server Instanz um nicht zu wissen wer was getan hat?

Ich habe 6 Ts3 Query Bots (mit JTS3ServerMod).
Zudem haben wir noch ein PHP Script, welches den Online-Status einzelner User prüft. Es stellt am Tag dadurch z. T. weit über 100 Verbindungen her.
Dann wären da noch ab und zu Query Clients zum Testen.
Und ich prüfe regelmäßig Einstellungen und Statistiken mit YaTQA.

Kurz gesagt: Viele Nutzer und viele Verbindungen.
Wir haben uns mehrere serveradmin Zugänge erstellt, um zwischen den Clients wenigstens bisschen unterscheiden zu können. Und da dies etwas sicherer ist.

Ich persönlich würde Session auch eher so definieren, dass Pro gestarteter Verbindung eine Session existiert. Unabhängig ob ich schon verbunden bin zum Server.

Die Idee den Verbindungen eine Session-ID zuzuweisen würde ich begrüßen.
Eine Zahl die einfach nur sagt wie viele Verbindungen vorhanden sind, wäre jedoch auch schön. Wenn man so viele Query-Verbindungen hat (z. B. wegen Ts3 Viewer o. Ä.) kann man den Instanz-Log nicht mehr so gut prüfen, da dies sehr lang werden kann. (Außer der Server-Log geht plötzlich nicht mehr, so wie es einmal passiert ist. Dann hat man halt recht kurze Logs. Bringt jedoch nichts.)
Wenn man die Anzahl an Query-Verbindungen hat, kann man zeitgleich bei jeder Verbindung in sein Script/Bot einfügen, dass irgendwo ein Counter angelegt wird. Dann kann man diesen mit dem im Log abgleichen und somit prüfen, ob sich jemand unbekanntes via Query eingeloggt hat.

[dante696]

Dann kann man die Zahl doch ganz entfernen, wenn sie nur für euch zum Debuggen dient und eh zuvor keinen Nutzen hatte.

Wenn wir die Zahl entfernen würden, dann hätten wir ja nichts mehr zum identifizieren, falls Hoster Probleme haben und uns deren logs schicken.

[markusmarkusz]

Wenn wir die Zahl entfernen würden, dann hätten wir ja nichts mehr zum identifizieren, falls Hoster Probleme haben und uns deren logs schicken.

Wenn ich fragen darf, was bringt euch die Zahl?
In meinem Log sind z. T. bis zu 20000 Einträge mit ein und derselben Zahl, wie kann man da irgendetwas identifizieren?
Würde mich freuen, wenn Sie mir das erklären, ggf. via PN.

[numma_cway]

Zu einem festen aber beliebigen Zeitpunkt X bedeuten unterschiedliche Nummern unterschiedliche Verbindungen.

[dante696]

In der Vergangenheit konnten mit dieser neuen Nummer Bugs im Query gelöst werden, die bei großen Hostern auftraten.
Daran war z.B. zu erkennen warum Verbindungen zum Query nicht mehr aufgebaut werden kontnen.

Die ganzen Details kenne ich nicht, da diese meist mit den hostern geklärt werden.