Meldungen, die im Mumble-Server auftreten können

Eine Liste aller möglichen Meldungen eines Mumble-Servers (Murmur). (für den Client: Meldungen, die in Mumble auftreten können)

Alle diese Meldungen sind nicht übersetzbar und es gibt sie nur in englischer Sprache.

Es gibt hier auch eine Liste der Bedeutung der IDs, die man in der Serverlog eines Mumble-Servers findet.

Zur besseren Lesbarkeit der Serverlog des Mumble-Servers gibt es ein Multitail-Farbschema.

Für Benutzer von Logcheck gibt es ein Regelwerk unter Reguläre Ausdrücke für Logcheck für Murmur (Mumble-Server).

Es gibt verschiedene Arten von Logeinträgen, die über den Buchstaben in der ersten Klammer am Anfang einer Zeile gekennzeichnet sind, z. B. <X>.

Hier gibt es folgende Möglichkeiten:

• X → Standardnachricht
• F → Fatal
• C → Critical
• W → Warning
• D → Debug
  Diese Einträge werden nur angezeigt, wenn der Mumble-Server mit der Option -v gestartet wurde; weitere Startoptionen siehe hier.

failed to set initial capabilities

Siehe unter Mumble-Server Capabilities.

<W>2013-06-05 12:39:21.198 1 => Failed to set IPV6_RECVPKTINFO for 0.0.0.0:64738

Diese Meldung kann man laut Enwickler ignorieren; hier wird versucht, ein IPv4-Dingens als IPv6-Dingens zu behandeln oder so…

Current booted servers require minimum xxx file descriptors when all slots are full, but only xxx file descriptors are allowed for this process. Your server will crash and burn; read the FAQ for details.

Siehe unter Mumble-Server Capabilities.

<W>2012-05-06 01:20:07.070 1 => <76:(-1)> Strong certificate for user <user@email.tld> (signed by XYZ Certification Authority)

Der Benutzer verwendet ein sogenanntes „starkes“ Zertifikat, welches von einer CA signiert wurde.

<W>2013-06-12 22:53:42.326 1 => <94:Benutzername(657)> Requested crypt-nonce resync

und

<W>2013-06-12 22:53:42.326 1 => <94:Benutzername(657)> Requesting crypt-nonce resync

Einige Pakete kamen nicht (Paketverlust) an und deshalb soll die Verbindung resynchronisiert werden bzw. wurde sie schon.

<W>2013-06-08 16:49:56.831 1 => <23:Benutername(1692)> Disconnecting ghost

Ein zweiter Benutzer hat sich mit demselben Zertifikat authentifiziert, deshalb wird der „alte“ rausgeworfen.

Dies passiert z. B. wenn jemand versehentlich Mumble zweimal geöffnet hat und in beiden Sitzungen dasselbe Zertifikat verwendet.

Oder auch, wenn jemand sehr schnell eine neue IP-Adresse von seinem Anbieter bekommt (vor dem Timeout der alten Sitzung) und direkt wieder auf den Server kommt.

SSL-Handshake failed

Ein Client mit einer Version <1.2.0 versucht auf den Server zu verbinden. Clientseitig bekommt man darüber keine Info; der Server wird dann einfach nicht gefunden.

Ab 1.2.4 wird beim Erstellen eines neuen (auch virtuellen) Mumble-Servers automatisch das SuperUser-Passwort für diesen Server erstellt und in der Log angezeigt.

<W>2012-07-01 17:6:44.519 6 => Password for 'SuperUser' set to '1%uyP@6aao'

Die einfachen Anführungszeichen dienen nur als Begrenzer, sie gehören nicht zum Passwort.

Ist auf einem Mumble-Server die Berechtigung „Selbst registrieren“ im Hauptkanal nicht gegeben, so kann sich ein Benutzer nicht selbst registrieren.

<W>2012-05-11 22:19:10.704 1 => <17:Benutzernamex(-1)> Benutzernamex not allowed to Register Self in Root

Mehr Informationen zu Benutzerregistrierungen gibt es unter Registrierte Benutzer (Benutzerverwaltung).

<W>2011-05-13 20:46:26.684 1 => CELT codec switch ffffffff8000000b ffffffff80000010 (prefer ffffffff8000000b)

Siehe unter Codec-Umschaltung.

Informationen zur Registrierung eines Mumble-Servers in der offiziellen Serverliste gibt es unter Mumble-Server in der Serverliste registrieren.

<W>2012-05-15 03:40:14.475 3 => Registration: Registration updated

Der „Masterserver“ auf dem die offizelle Serverliste gehostet wird, kommt einmal in der Stunde vorbei und guckt ob der Server noch existiert.

Im nächsten Fall wurde registerlocation verwendet und eine Registrierung war erfolgreich.

<W>2012-05-15 03:40:14.475 3 => Registration: Registration updated [Location set to DE]

Bei dieser Meldung ist alles OK und der Server sollte in der Serverliste sichtbar sein.

<W>2012-05-15 03:40:14.475 3 => Registration updated [Location must be two-letter country code of certificate or hostname]

Bei dieser Meldung ist keines der beiden Ziele erfüllt, die zur zukünftigen Verwendung von registerlocation notwendig sind. Der Eintrag in der offiziellen Serverliste wird trotzdem aktualisiert.

Bei den Meldungen im Stil von 'Registration failed: xxx' ist xxx die Fehlermeldung, die das Qt-Objekt QNetworkReply zurückliefert.¹⁾.

Eine ungefähre Richtung, was der Fehler sein könnte, kann man folglich in der folgenden Liste nachgucken.

Ähnliches gilt für Fehlermeldungen der Form 'Registration: SSL Handshake Error: yyy' bei dem yyy ein Fehlercode des Qt-Objekts QSslError zurückliefert. ²⁾.

Eine Liste aller möglichen Fehler gibt es hier.

Die relevanten Einträge zu diesem Thema sind z. B. (wobei die letzte Zeile immer auftritt, die beiden vorherigen können anders sein oder fehlen):

<W>2012-05-15 03:40:14.475 3 => Registration: SSL Handshake error: The root certificate of the certificate chain is self-signed, and untrusted
<W>2012-05-15 03:40:14.475 3 => Registration: SSL Handshake error: The issuer certificate could not be found
<W>2012-05-15 03:40:14.475 3 => Registration failed: SSL handshake failed

Der Aussteller der Zertifikats konnte in diesem Fall nicht ermittelt werden, irgendwas mit den Zertifikaten passt nicht. In jedem Fall funktioniert hier etwas mit den beteiligten Zertifikaten nicht.

Nur Registrierungs-Server oder auch eigener Mumble-Server? Todo: Brauche testweise ein Mafia-Zertifikat, jemand zur Ausleihe bereit?

Hier kann man erst einmal unabhängig vom Mumble-Server testen, ob das SSL-Zertifikat des Servers, der für die Registrierung zuständig ist, vom eigenen Server als richtig erkannt wird.

Dies kann man überprüfen, indem man folgendes Kommando auf dem eigenen Server ausführt³⁾:

openssl s_client -connect mumble.info:443 -CAfile /etc/ssl/certs/ca-certificates.crt

Steht in der letzten Zeile der Ausgabe „Verify return code: 0 (ok)“, dann ist alles OK.

Steht dort jedoch soetwas wie „Verify return code: 19 (self signed certificate in certificate chain)“, dann kann die Gültigikeit des Zertifikats auf dem eigenen Server nicht überprüft werden und somit eine Registrierung nicht funktionieren.

Wird das Zertifikat nicht als gültig erkannt, hilft es vielleicht , das Root-Zertifikat von selbst zu importieren:

• Wie das unter Windows funktioniert, steht hier.
• Unter Linux:

<W>2012-07-01 17:11:21.084 5 => Registration needs nonempty 'registername', 'registerpassword' and 'registerurl', must have an empty 'password' and allowed pings.

Eine oder mehrere der genannten Bedingungen ist/sind nicht erfüllt und der Server wird nicht in der offiziellen Serverliste registriert.

<W>2012-05-15 03:40:14.475 3 => Registration failed: HTTP request failed

Vermutlich ist der Registrierungsserver für die offizielle Serverliste vom Server aus, auf dem der Mumble-Server läuft, nicht erreichbar, da z. B. eine Firewall den Port 443 nach außen sperrt?

Details hier.

<W>2012-05-15 03:40:14.475 3 => Registration failed: Host  not found

Bedeutung: Bei amd64 System ia32-libs installieren. ⁴⁾

Ein Neustart des Mumble-Servers ist nicht notwendig.

• https://sourceforge.net/projects/mumble/forums/forum/492607/topic/3823608
• https://sourceforge.net/projects/mumble/forums/forum/492607/topic/4911313

Auszug:
Diese Meldung kommt vom Registrierungsserver; entweder stimmt etwas diesem nicht oder der bei registerhostname verwendete Domainname passt irgendwie nicht.

<W>2012-05-15 03:40:14.475 1 => Registration: No DNS records found: Registration updated

Der Hostname der Variable registerhostname muss ein A- oder AAAA-Eintrag sein, verwendet man einen CNAME-Eintrag verwendet , kommt diese Meldung und statt des Hostnamens wird nur die IP als Adresse in der Serverliste verwendet. ⁵⁾ Eine Registrierung/Aktualisierung in der Serverliste erfolgt aber trotzdem.

<W>2012-04-20 06:37:28.999 1 => <183:Natenom(441)> Authenticated

441 ist die userid.

<W>2012-04-20 06:37:25.687 1 => <148:Natenom(441)> Connection closed: The remote host closed the connection [1]

441 ist die userid und 148 die sessionid.

<W>2012-04-20 06:27:45.278 1 => <36:Natenom-(441)> Renamed user 336 to 'Testbenutzer'

336 ist die userid des Benutzers, der hier in Testbenutzer umbenannt wurde.

Bei Statusänderungen eines Benutzers durch einen anderen Benutzer (stumm, taub, usw.) wird das Ergebnis mit 4 Zahlen dargestellt, hier (0 0 0 0).

In diesem Beispiel wurde der Benutzer durch einen anderen Benutzer entstummt und hat nun keines der Flags gesetzt.

<W>2012-06-05 19:46:07.283 1 => <82:Natenom(1247)> Changed speak-state of Benutzer:20(1076) (0 0 0 0)

Die Bedeutung der eingeklammerten Zahlen am Ende: ⁶⁾

1. stumm (durch einen Admin)
2. taub (durch einen Admin)
3. unterdrückt (suppress) (durch den Server)
4. Bevorzugter Sprecher

<W>2012-11-18 00:46:33.815 5 => <6:MLO(-1)> Rejected connection: Server is full (max 4 users)

Verbindungsversuch wurde verweigert, da alle Slots des Servers bereits belegt sind.

<W>2012-11-28 07:33:57.210 1 => <150:Benutzername(-1)> Rejected connection: Wrong certificate or password for existing user

Ein Benutzer hat versucht, sich mit einem falschen Passwort oder falschem Zertifikat als Benutzername auszugeben.

<W>2013-07-04 02:27:18.026 1 => <2:Admin-Benutzer(1)> Kickbanned DoofUser:3(-1) (Banngrund)

Der Benutzer DoofUser wurde von Admin-Benutzer gebannt mit der Begründung „Banngrund“.

<W>2013-12-30 16:54:09.021 1 => Ignoring connection: 1.2.3.4:51158, Reason: "blupp", Username: "Natenom", Hash: "12234abcdkdk3u9" (Server ban)

Ein gebannter Benutzer versucht, sich zu einem Server zu verbinden.

<W>2013-12-30 16:54:09.021 1 => Ignoring connection: 1.2.4.9:51221 (Global ban)

Ein Benutzer hat einen Global Ban ausgelöst, indem er sich zu oft mit dem Server verbunden hat innerhalb einer bestimmten Zeit. Details dazu siehe hier.

<W>2013-07-04 03:04:25.868 6 => <2:Admin-Benutzer(1)> Kicked DoofUser:3(-1) (Kickgrund)

Der Benutzer DoofUser wurde von Admin-Benutzer gekickt mit der Begründung „Kickgrund“.

<W>2012-11-30 06:48:26.116 1 => <25:Benutzername (123)> Updated banlist

Der Benutzer hat die Bannliste bearbeitet, folgende Aktionen können die Ursache sein:

• Banneintrag geändert
• Banneintrag entfernt
• Banneintrag hinzugefügt

<W>2013-07-04 02:28:32.497 6 => <1:(-1)> Certificate hash is banned: "1234abcddkjd9029e83", Username: "Natenom", Reason: "blupp"

Ein Benutzer, dessen Zertifikat gebannt ist, hat versucht, den Mumble-Server zu betreten.

Der gesamte Vorgang erzeugt folgende Einträge:

<W>2013-07-04 02:28:06.739 1 => <3:(-1)> New connection: 1.2.3.4:56789
<W>2013-07-04 02:28:06.791 1 => <3:(-1)> Certificate hash is banned: "1234abcddkjd9029e83", Username: "Natenom", Reason: "blupp"
<W>2013-07-04 02:28:06.792 1 => <3:(-1)> Connection closed:  [-1]

<W>2012-04-20 07:47:34.998 Added Ice MetaCallback D240DE6D-9671-4DF4-811E-A90AB5211CAE -o:tcp -h 127.0.0.1 -p 48927 -t 5000

<W>2012-04-20 07:47:35.001 3 => Added Ice ServerCallback CB2AE8E7-3940-43D5-84C1-04AEFAC11CAE -o:tcp -h 127.0.0.1 -p 48927

3 ist die server_id des virtuellen Mumble-Servers.