[Problem] Gibt es einenTimer für die internen SIP Clients?

Ein Telefon neu starten und unmittelbar danach mal die Support-Daten der 7490 auslesen ... dort sollte man im SIP-Teil eigentlich sehen, wenn da irgendwelche Probleme auftreten (und dann wird der Neustart sicherlich wegen des Haussegens möglich sein).

Wobei das ja dann eine "langzeitstabile" 7490 ist ... die ist ja dann vermutlich seit dem Update auf die 06.51 noch nie neu gestartet worden - mit so langen Laufzeiten fehlen mir persönlich jegliche Erfahrungen. Man probiert einfach zu viel herum, auch mit "Produktivboxen", weil sich immer mal irgendeine Zusatzkomponente ändert und dann ein Neustart die "Restart-Festigkeit" solcher Arbeiten umgehend klären kann, ehe beim/nach dem nächsten Stromausfall dann unerwartet nichts mehr geht.

Moins

Und was sagt mir das, außer das sich das Endgerät nicht registriert?

Zum Vergrößern anklicken....

Genauso viel wie uns.

Eine Eigenart des REGISTER ist, dass die erste Antwort des Servers immer Unauthorized ist.
Denn der Server übergibt erst dann das: WWW-Authenticate: Digest realm="fritz.box", nonce="82756F4276F2668C"
Dieses nonce muss der Klient im zweiten Anlauf richtig beantworten.

Ergo solltest du der Vollständigkeit halber auch nachfolgendes REGISTER und dessen Serverantwort posten...

Das gezeigte "Fehlerbild" mit einer 401-Antwort auf den ersten Kontaktversuch ist vollkommen normal ... das liegt einfach daran, daß dort eine Anmeldung verwendet wird, die das Kennwort nicht im Klartext übermittelt.

Damit da auch keine "replay"-Attacke stattfinden kann (also eine ältere, "verschlüsselte" - so eine Hash-Funktion ist tatsächlich eine Einweg-Verschlüsselung - Anmeldung einfach noch einmal gesendet werden kann), gibt es eine einmalige Komponente (genannt "nonce"), die vom Server (hier der FRITZ!Box) vorgegeben wird und die der Client (das OpenStage) in die Berechnung des Anmeldewertes mit einbeziehen muß. Das genaue Verfahren ist im entsprechenden Internet-Standard beschrieben (RFC).

Da der Client beim ersten Anmeldeversuch noch keine Credentials gesendet hat (kann er auch nicht, er braucht erst den aktuellen "nonce" von der Box), kriegt er erst einmal die Antwort "401" ... aber mit dieser Antwort zusammen erhält er jetzt (im "WWW-Authenticate"-Header) den "Namensraum" (realm) und den einmaligen Wert (nonce), mit denen er Benuternamen und Kennwort verknüpfen kann/muß, bevor auf das Gesamtergebnis eine Hash-Funktion angewendet wird.

Den Hash-Wert über dieses Gesamtergebnis muß der Client dann in einer weiteren Anmeldung angeben (im "Authorization"-Header, zusammen mit den anderen Angaben, die er für die Berechnung verwendet hat).

Der Server prüft dann, ob tatsächlich die angegebenen Daten benutzt wurden (in erster Linie, ob der Client wirklich den vorgegebenen "nonce"-Wert benutzt hat und nicht einfach hier wieder einen älteren "unterjubelt") und nimmt seinerseits mit Benutzernamen und Kennwort dieselbe Berechnung vor.

Stimmen die errechneten Hash-Werte überein, hat nach der Theorie (Hash-Kollisionen spielen hier keine wirkliche Rolle) der Client dieselben Ausgangsdaten verwendet, somit muß er sie tatsächlich kennen, ergo ist er "berechtigt" zum Zugriff.

Damit ist es eben vollkommen normal, wenn so eine Anmeldung im ersten Versuch scheitert (sie kann - wegen fehlender "nonce" - gar nicht funktionieren) und wenn da seitens des Clients keine weiteren REGISTER-Versuche zu sehen sind, dann werden die entweder nicht gesendet (läge dann am Client, ohne REGISTER dann natürlich auch keine Antwort) oder sie werden tatsächlich von der "Firewall" der FRITZ!Box schon vor dem "voipd" abgewiesen/blockiert.

Das wäre auch denkbar (schließlich kann man mit ständigen REGISTER-Versuchen so ein Gerät auch entsprechend beschäftigen für den Versuch einer DoS-Attacke), wenn die FRITZ!Box tatsächlich die REGISTER-Versuche eines Clients zählt (als absoluten Wert und nicht pro Zeiteinheit) und/oder dabei irgendein Zähler nicht richtig zurückgesetzt wird bzw. nach so langer Zeit dann übergelaufen ist.

Wobei dann die Frage aufkäme, warum es der erste Versuch jeweils durch diese Firewall (ob es dort eine Limitierung der Requests gibt, muß man aber eben auch erst testen, ich stand noch nie vor diesem Problem) schaffen sollte ...

Ich hatte auch noch die Frage vergessen, ob irgendetwas im Eventlog der Box zu sehen ist, was fehlgeschlagene Anmeldungen von SIP-Clients betreffen könnte.

Da die Firewall mit einiger Wahrscheinlichkeit auf der Basis von IP- und/oder MAC-Adressen arbeitet, wäre ein weiterer Test (wenn nicht die Änderung eines einzelnen Kennworts gleich alle Clients wieder funktionieren läßt - ich würde hier auch auf das Zurücksetzen von Zählern beim Aktualisieren so eines SIP-Clients tippen) mit abweichender IP-Adresse für eines der Telefone noch ein denkbare Untersuchung.

Neuere Clients können sich ja offensichtlich weiterhin anmelden nach #1 und der Unterschied zwischen den Siemens-Telefonen und der FRITZ!Box 7240 bei inzwischen gleichen Symptomen könnte in einer anderen Häufigkeit der Erneuerung so einer Registrierung liegen (so ein "keepalive" ist auch nicht richtig standardisiert, das kann über alle möglichen SIP-Nachrichten erfolgen, je nach Implementierung auf beiden Seiten) ... ich würde mal behaupten, daß eine event. schon länger nicht erfolgreiche Anmeldung der 7240 nicht auf Anhieb auffallen würde (ansonsten ist die Theorie auch Schrott, weil die 7240 auch drei Monate gelaufen wäre - die OS ja vier - und das dann schon ein merkwürdiger Fehler/Zufall wäre, wenn zum identischen Zeitpunkt diese Überläufe auftreten würden).

Normalerweise zeigt die FRITZ!Box im Rahmen der Ausgabe von "showvoipdstat" in den Support-Daten auch an, wie lange so ein Client jetzt schon registriert ist ... das wäre auch interessant. Selbst wenn ein OS seit Ende Januar arbeitet, muß das ja nicht zwangsläufig auch heißen, daß die Registrierung über diesen gesamten Zeitraum bestand - insofern "rechnet" es sich schlecht und die Meinung des FRITZ!OS, wie lange so ein Kontakt nun schon besteht, wäre eben interessant.

- - - Aktualisiert - - -

@koy war schneller, meine Erklärung ist umfangreicher ... ich lasse sie stehen.

@koy: Die Erklärung ist soweit richtig ... außer daß der "nonce"-Wert selbst noch kein Hash-Wert ist (auch wenn er event. mittels einer Hash-Funktion ermittelt werden sollte). Das ist einfach eine "Zufallszahl" (hier ja 16 * 4 = 64 Bit). Selbst wenn das bereits ein Hash-Wert wäre (man kann natürlich auch MD5 auf die aktuelle Uhrzeit o.ä. anwenden und dann irgendwo abschneiden beim Ergebnis, denn MD5 liefert ja selbst 128 Bit), muß ja sichergestellt sen, daß sich das "Ausgangsmaterial" vom vorhergehenden unterscheidet, sonst würde sich der "nonce"-Wert nie ändern.