Verzweiflung nach 2 Wochen ausporbieren

[baxter2015]

Hallo zusammen,

mein Kopf raucht ohne ende :ziggi: und deshalb wende mich nun an euch als letzte Hoffnung.

Habe unterschiedliche Fritzboxen hier 7170 | 7272 | 7490 alle natürlich auf dem neusten Firmware stand.

Nun aber zum Scenario:

Haben zwei Häuser, das Haupthaus ist mit ADSL ausgestattet und hängt direkt an einem TP-Link ADSL Router. Das Nebenhaus wird mit Internet per Richtfunk versorgt mit Ubiquity Nanostation M5 (max. 200 Meter Distanz).

Nachdem im Nebenhaus keine Telefonlinie liegt habe ich die FritzBox angeschlossen und Voip von Sipgate Konfiguriert. Port und Nat Freigaben als auch statische IP Adressen vergabe sind alle gemacht und ich habe eingehende Anrufe als auch ausgehende Anrufe.

Juhuu dachte ich mir, alles läuft... falsch gedacht... nach einigen Tagen bin ich eingehend nicht mehr erreichbar! Kann aber ohne Probleme nach aussen Telefonieren.

Laut Sipgate reregistriert sich die Box auch weiterhin alle 5min, nur bin ich Trotzdem nicht mehr eingehend erreichbar. Jetzt hab ich mir gedacht was solls, dann gehe ich halt den einfachsten Software technischen Weg. Habe die debug.cfg bearbeitet und reboote die Box täglich neu um 4Uhr Morgens. Das klappt mal und dann wieder nicht, also der Reboot. Es scheint die Box hängt sich auf und kann die debug.cfg nicht mehr abarbeiten.

Was ich auch sehr komisch finde, manchmal nach einem Reboot wird die Voip-Telefonie von der Fritzbox einfach deaktiviert und in allen Feldern bei Internet Telefonie erschient nur noch er dann muss ich die Box mechanisch vom Strom abziehen, danach Fährt Sie wieder hoch.

PS: Habe den selben effekt ab und zu wenn ich einen Reboot per Tastencode #990*15901590* mache (auch das habe ich automatisiert mittels AutoIT)

Ok nachdem das mit dem Reboot nicht sauber Funktioniert habe ich einen anderen Weg gefunden.

Gehe mittels Remote Zugriff auf die GUI der Box und deaktiviere die Internet Telefonie und aktiviere Sie anschliessend, danach ist alles wieder bestens.

Diese Methode ist total bescheurt, weil ich keine möglichkeit finde diesen Ablauf zu automatisieren. Habt Ihr eine Idee dazu?

PS: Dieses Probleme mit eingehend nicht ereichbar sein tauchen nicht auf wenn ich die Box als Modem nutze, diese Effekte sind nur vorhanden wenn ich die Box am LAN1 betreibe.

Ajaa... bitte keine Lösungvorschläge mit "Kauf Dir eine Zeitschaltuhr oder ähnliches!"

Liebe Grüsse

 

[informerex]

in der 1. F!Box sämtliche VoIP-Accounts eintragen und die anderen Boxen als Nebenstelle. (Sip-Server/Registrar)
somit umgehe ich evtl. Fehler bzgl. Portfreigaben

sollte trotzdem noch ein reboot notwendig werden, ist ein Zeitschaltuhr eine gängige Alternative.

 

[baxter2015]

Hallo Informerex,

ich habe nicht alle Fritzboxen zeitgleich im Betrieb, es hängt immer nur eine Box im Netz. Habe es aber schon mit allen 3 FritzBüxen probiert.

 

[andiling]

Hast Du in den Anschlußeinstellungen "Portweiterleitung des Internet-Routers für Telefonie aktiv halten" aktiviert?

 

[baxter2015]

Ja hab ich auf 30Sek, das sollte doch wie z.B. von Linksys bekannt das Nat Keep Alive sein.

 

[andiling]

Bei mir ist es auf 5 Minuten, weiß aber nicht ob das einen Unterschied macht (ggf. sind 30 Sek too much)

 

[baxter2015]

Ist zwar schwer vorzustellen das dass der Box das zuviel ist, aber es wäre zumindest eine mögliche Erklärung.

Habe es jetzt mal auf 5 min. gestellt, jetzt heißt es abwarten und sehen was innerhalb der nächsten paar Tage passiert.

 

[PeterPawn]

Habe unterschiedliche Fritzboxen hier 7170 | 7272 | 7490 alle natürlich auf dem neusten Firmware stand.

Habe die debug.cfg bearbeitet und reboote die Box täglich neu um 4Uhr Morgens. Das klappt mal und dann wieder nicht, also der Reboot. Es scheint die Box hängt sich auf und kann die debug.cfg nicht mehr abarbeiten.

Es wäre hilfreich, wenn Du die geschilderten Probleme auch wirklich dem jeweiligen Modell zuordnen würdest und auch eine etwas genauere Erklärung, was in der von Dir bearbeiteten debug.cfg dann steht, wäre wünschenswert.
Ich habe so meine Probleme, mir da einen täglichen Reboot zu einer bestimmten Uhrzeit ohne ausführliche Schleifen mit "sleep" oder exzessive Berechnungen für ein einmaliges "sleep" (oder delay) vorzustellen (was dann bei Stellen der korrekten Uhrzeit auch schnell Makulatur ist).
Dann kommt noch hinzu, daß die 7490 "auf dem neusten Firmware stand" die debug.cfg überhaupt nicht mehr berücksichtigt, da sollte ein "Das klappt mal und dann wieder nicht" eigentlich gar nicht vorkommen dürfen.
Insofern wäre es auch schön, wenn Du nicht wild mit den doch sehr unterschiedlichen Boxen herumexperimentieren würdest, sondern Dich auf ein konkretes Modell (mein Vorschlag wäre dann logischerweise die 7490) festlegen würdest.

Was ich auch sehr komisch finde, manchmal nach einem Reboot wird die Voip-Telefonie von der Fritzbox einfach deaktiviert und in allen Feldern bei Internet Telefonie erschient nur noch er dann muss ich die Box mechanisch vom Strom abziehen, danach Fährt Sie wieder hoch.

Hört sich für mich ehrlich gesagt so an, als wenn da (kommt eben auch wieder auf die Box an, die 7490 hat ein yaffs auf /var/flash und speichert fälschlicherweise als reguläre Datei angelegte Einstellungsdateien wie z.B. die voip.cfg über ein Reboot hinaus, anders als Modelle mit tmpfs auf /var/flash) Deinerseits in irgendwelchen Skripten auf die falsche Art und Weise an den Einstellungen gedreht wird, da wäre dann die o.a. Bitte um konkrete Angaben wieder.

Gehe mittels Remote Zugriff auf die GUI der Box und deaktiviere die Internet Telefonie und aktiviere Sie anschliessend, danach ist alles wieder bestens.

Das sehe ich eher als Bestätigung meiner Vermutung von oben an, da dann wohl die Box ihrerseits die Einstellungen wieder richtig nach /var/flash schreibt.

Und anstatt die Box nur immer neu zu booten, wäre es sicherlich systematischer, wenn Du im Falle der Nichterreichbarkeit erst einmal prüfst, woran das nun liegt. Ob Deine FRITZ!Box das NAT im TP-Link richtig am Leben hält oder nicht, mußt Du dann eben erst einmal eindeutig klären. Die entscheidende Frage in meinen Augen ist, wie lange der TP-Link-Router seinerseits eine UDP-Verbindung offen läßt und ob die FB stabil das "keep-alive" für das NAT im TP-Link absetzen kann (das ist bei der FB ja ein SIP-OPTIONS-Request an den Registrar, der dann die Verbindung "verlängert") - also auch ohne Dropouts auf der Funkstrecke.

Wenn Du ansonsten keine weiteren VoIP-Aktivitäten im oder hinter dem TP-Link (dessen Modell finde ich auch nirgendwo in Deinen Angaben) hast, könntest Du ja auch einfach die von der FRITZ!Box benutzen Ports, also ganz normal UDP+TCP 5060 für SIP und UDP 7078-7100 für RTP, als Portweiterleitung an die FRITZ!Box im TP-Link-Router einstellen, dann brauchst Du kein NAT-keepalive. Wobei Du ansonsten auch gleich die Frage nach dem verwendeten Protokoll für die Anmeldung bei sipgate klären könntest. Es hängt auch wieder vom Modell ab, ob die FB das nur per UDP oder auch per TCP (wird wohl nur dann probiert, wenn UDP nicht klappt) kann - NAT-keepalive bei TCP ist i.d.R. etwas anders als bei UDP.

 

[baxter2015]

Hallo PeterPawn,

Es wäre hilfreich, wenn Du die geschilderten Probleme auch wirklich dem jeweiligen Modell zuordnen würdest und auch eine etwas genauere Erklärung, was in der von Dir bearbeiteten debug.cfg dann steht, wäre wünschenswert.
Ich habe so meine Probleme, mir da einen täglichen Reboot zu einer bestimmten Uhrzeit ohne ausführliche Schleifen mit "sleep" oder exzessive Berechnungen für ein einmaliges "sleep" (oder delay) vorzustellen (was dann bei Stellen der korrekten Uhrzeit auch schnell Makulatur ist).
Dann kommt noch hinzu, daß die 7490 "auf dem neusten Firmware stand" die debug.cfg überhaupt nicht mehr berücksichtigt, da sollte ein "Das klappt mal und dann wieder nicht" eigentlich gar nicht vorkommen dürfen.
Insofern wäre es auch schön, wenn Du nicht wild mit den doch sehr unterschiedlichen Boxen herumexperimentieren würdest, sondern Dich auf ein konkretes Modell (mein Vorschlag wäre dann logischerweise die 7490) festlegen würdest.

Konzentrieren wir uns auf die 7170, da die mir am liebsten ist, die hat noch kein Lua Login.

Das steht in der debug.cfg, ansonsten habe ich nicht anderes in der debug.cfg stehen. Geschrieben habe ich es mit nvi und mittels cat geprüft, date gibt mir auch das richtige Datum und Uhrzeit aus.

while true
do
sleep 120
date | grep 04:00:
if [ $? -eq 0 ]
then
reboot 10
fi
done

Folgendes ADSL Modem wird genutzt TP-Link AC1750, der Port 5060 TCP+UDP sowie für Audio RTP 7078-7100 sind schon weitergeleitet auf die 192.168.5.50 (Diese Staische IP ist die WAN Port IP der Fritzbox am LAN1). Habe auch keine anderen VOIP Dienste im Netz, nur die der FritzBox. Die Registrierung wird mittels UDP und nicht per TCP durchgeführt, wurde mit Wireshark geprüft. Es wird auch kein Stun oder Proxy genutz.


Aber an einem Punkt wird es mit Sicherheit liegen, habe das vorhin getestet:

1. FritzBox ist eingeschaltet und verbunden, sowie VOIP ist registriert.
2. Beide Nanostation M5 sind an, Funkstrecke steht.
3. TP-Link Router ist an.

Wenn ich jetzt den TP-Link Reboote, bin ich eingehend nicht mehr erreichbar, die 7170 zeigt VOIP nicht Registriert nach paar min. zeigt die Box VOIP wieder an Registriert

So nun wieder alles auf Ursprungs zustand.

Trenne ich nun die Funkstrecke und verbinde Sie erneut nach Paar min. bin ich erneut nicht eingehend erreichbar, bis ich eine Reboot mache oder die VOIP Telefonie deaktiviere und erneut aktiviere.

PS: Der SIP Helper ist auf dem TP-Link auch aktiviert.

 

[PeterPawn]

Konzentrieren wir uns auf die 7170, da die mir am liebsten ist, die hat noch kein Lua Login.

Ok, die mag ich zwar am wenigsten, da ich kein Image zum Nachschlagen habe (und mir jetzt auch keines dafür zulege).

Wenn das nicht in der 7170 vollkommen anders gehandhabt wird mit dem Aufruf der debug.cfg, ist es keine gute Idee, dort direkt irgendwelche Aktionen auszuführen.

In modernerer Firmware läuft/lief der "Aufruf" der debug.cfg über ein "source"-Kommando (auch als '.' möglich, das ist dasselbe), damit werden also die Anweisungen in der debug.cfg an dieser Stelle "eingefügt". Macht man dort jetzt eine Schleife auf, die nicht endet (wie in Deinem Falle), wird der Rest des Skripts, das die debug.cfg abarbeitet, nicht weiter ausgeführt (und damit der init-Prozess quasi an dieser Stelle angehalten, bis die Abarbeitung der debug.cfg beendet ist). In neuerer Firmware kam da (solange die debug.cfg noch berücksichtigt wurde) z.B. noch die Initialisierung der PowerManagement-Funktionen (oder zumindest die Initialisierung für deren Anzeige) und eine debug.cfg wie bei Dir verhinderte dann diesen Prozess.

Wenn man also in der debug.cfg irgendwelche länger laufenden Prozesse starten will, schreibt man sich ein Shell-File an eine definierte Stelle und startet dann die Abarbeitung dieses Shell-Files asynchron zum Rest der Verarbeitung. Ich empfehle da gerne das "delay"-Kommando von AVM, das einen verzögerten und asynchronen Start von weiteren Prozessen ermöglicht (hat ein "usage help" eingebaut, einfach lesen).

Das steht in der debug.cfg, ansonsten habe ich nicht anderes in der debug.cfg stehen. Geschrieben habe ich es mit nvi und mittels cat geprüft, date gibt mir auch das richtige Datum und Uhrzeit aus.

EDIT: Ok, beim Korrekturlesen habe ich das mit "date" dann auch endlich richtig verstanden, es geht ja gar nicht um das Dateidatum, ignorier den nächsten Absatz einfach. [/EDIT]
Das verstehe ich dann bei einer 7170 nicht. Entweder das char-Device existiert ... dann ändert ein Schreibzugriff mit "cat" (etwas anderes macht ja nvi auch nicht) nach meinem Dafürhalten nicht das Datum des Devices. Oder die Datei existiert nicht ... dann bringt auch ein 'nvi' oder ein 'cat' kein passendes char-Device hervor und ein reguläres File hat dann sehr wohl einen passenden Zeitstempel, ist bei einer 7170 dann aber auch beim nächsten Booten wieder spurlos verschwunden. Also achte mal bitte darauf, um was für ein File es sich bei Deiner "debug.cfg" überhaupt handelt. (Bei der 7490 bleiben allerdings auch reguläre Files in /var/flash erhalten, aber über die reden wir ja wohl nicht.)

Aber egal, zum Telefonie-Problem:
Wenn die Weiterleitung externer Pakete über den TP-Link an die FRITZ!Box auf dem UDP-Port 5060 korrekt eingerichtet ist, muß ja die Signalisierung von SIP-Calls an die FB weitergeleitet werden. Ich kenne allerdings den "SIP-Helper" des TP-Link-Routers nicht, was soll der denn machen ? Wenn der irgendwie die SIP-Pakete mit einer "Deep Packet Inspection" analysiert und z.B. irgendwelche RTP-Ports automatisch öffnet oder im Paket ändert, würde ich ihn abschalten, da er einfach nicht benötigt wird bei einer funktionierenden Portweiterleitung (und auf Layer 5 hat so ein DSL-Router imho ohnehin nichts zu suchen). Dann ist das gesamte NAT-Keepalive ja definitiv nicht Dein Problem, das braucht es nur, wenn ansonsten ankommende Pakete von außen keine "offene" Verbindung finden, an die sie im LAN weitergegeben werden können. Bei einer Portfreigabe spielt ja das Vorhandensein einer Connection "von innen" keine Rolle, die Pakete werden in jedem Falle nach dem Umschreiben der Zieladresse an den eingetragenen Client weitergeleitet.

Wenn ich jetzt den TP-Link Reboote, bin ich eingehend nicht mehr erreichbar, die 7170 zeigt VOIP nicht Registriert nach paar min. zeigt die Box VOIP wieder an Registriert

Die FB (wieder nur definitiv für wenigstens eine 7270) sendet in regelmäßigen Abständen (je nachdem, was man bei "Offenhalten" einstellt) SIP-OPTIONS-Requests an den Registrar und erwartet dann natürlich auch eine passende "200 OK"-Antwort von diesem. Bleibt die Antwort aus, denkt sie "Aha, nicht registriert ..." und probiert es gleich noch einmal (nach einem kurzen TO, kann eingestellt werden). Klappt das dann auch noch nicht (weil der TP-Link noch nicht geht), wird die Zeit bis zum nächsten Versuch verlängert. Irgendwann ist dann auch wieder der TP-Link da und - wenn dann mal wieder ein Versuch seitens der FRITZ!Box "dran" ist - es kommt auch wieder eine Antwort vom Registrar.

Trenne ich nun die Funkstrecke und verbinde Sie erneut nach Paar min. bin ich erneut nicht eingehend erreichbar, bis ich eine Reboot mache oder die VOIP Telefonie deaktiviere und erneut aktiviere.

Wenn auch länger warten nicht hilft (s.o. die Zeit wird i.d.R. bis zu einem max. Wert verdoppelt), könnte ich mir noch vorstellen, daß die Box auf der Funkstrecke (diese Geräte bei Dir kenne ich auch nicht im einzelnen) das Abbauen/Aufbauen der Verbindung nicht richtig "mitbekommt". Für sie ist es ja eine kabelbasierte LAN-Verbindung (inkl. Media-Sensing), je nachdem, wie sich die Funkstrecke dann verhält, kriegt die Box den Aufbau der Verbindung vielleicht gar nicht mit (dann sollte sie auf ihrem GUI aber auch eine unterbrochene Internet-Verbindung anzeigen). Es ist eben eine etwas ungewöhnliche Situation, wenn eine FRITZ!Box mit statischer WAN-IP-Adresse an einem LAN-Kabel an LAN1 mit einem anderen Router verbunden wird und dann dieses Kabel nicht "reliable" ist.

Insofern ist das - bis auf das "Dauer-Aus" nach dem Trennen der Funkverbindung - auch alles klar und - für mich - logisch nachvollziehbar. Einen Zusammenhang mit der Funkstrecke hatte ich - ohne konkrete Begründung, dafür kenne ich Deine Geräte nicht genug - ja angenommen, deshalb der Hinweis auf die "stabile" Verbindung zwischen FB und TPL.

Warum dann aber vom TPL (auch der ist natürlich zur FB auf die stabile Funkverbindung angewiesen) in bestimmten Situationen die SIP-Pakete nicht an die Box weitergeleitet werden, verwirrt mich auch etwas. Ich könnte mir wirklich nur noch einen Paketverlust auf der Funkstrecke vorstellen (UDP ist ja connection-less, da gibt es kein ACK o.ä.). Diesem solltest Du aber mit einem Wireshark-Mitschnitt einmal des Verkehrs des TPL im LAN und andererseits der FRITZ!Box im "WAN" (für die ist ja LAN1 dann WAN) und dem Vergleich der Pakete problemlos auf die Schliche kommen können. Wenn Du das gleich beim Mitschnitt schon mit einem passenden Filter machst (z.B. an einem Hub zwischen Funkstrecke und FRITZ!Box oder mit einem Switch mit Monitor-Port, falls Du so etwas hast), kannst Du das auch mal über einen längeren Zeitraum laufen lassen, ohne am Ende Gigabytes an Netzwerkdaten zu haben (was beim Packetdump der FRITZ!Box selbst wohl nicht zu vermeiden ist).

 

[eisbaerin]

Konzentrieren wir uns auf die 7170, da die mir am liebsten ist,

Mir auch, habe noch 5 am Laufen, nur am VDSL mußte ich leider eine andere nehmen.

sleep 120

Die 120 ist zu groß, deshalb

Das klappt mal und dann wieder nicht, also der Reboot.

Weil du dann von 03:59 auf 04:01 springst, und dann erfolgt kein reboot.
Der sleep sollte also maximal 60 sein, ich würde ihn auf 50 setzen.

Aber in die debug.cfg würde ich so eine endlos Schleife auch nicht packen.
Extra eine Datei machen und diese dann in der debug.cfg starten lassen.

 

[baxter2015]

Hallo zusammen,

so lasse nun einen Mitschnitt per Wireshark machen, die Auswertung folgt in paar Tagen.

Bei der Endlosschleife habt Ihr natürlich völlig recht! Habe sie nun ausgelagert und lasse Sie asynchron laufen mit einem Delay vom 2500ms.

|Schlag auf den Kopf!| Klar gibt es troubles mit 120sec., habe es runter auf 50sec. gesetzt.


------------------------------------------------------------------------------------------?

Frage mich im Moment ob ein vollständiger Reboot überhaupt notwendig ist. Ich weiß zwar noch nicht wie, aber für die Voip Telefonie sollte es doch einen eigene Prozess geben, den man doch sicherlich neustarten kann und das halt eben auch über die debug.cfg (ausgelagerte Shell natürlich)


@Edit
Jop habe es gerade gefunden: /etc/init.d/rc.voip

Also jetzt passe ich noch die shell an, die für den Reboot zuständig war damit kein Reboot sondern ein /etc/init.d/rc.voip restart umgesetzt wird.

Gibt es dazu irgendwelche Einwände?

 

[baxter2015]

Hallo zusammen,

mittels /etc/init.d/rc.voip restart Funkioniert das nicht solange es in eine While Schleife ist, fragt mich nicht warum, obwohl es wenn ich es ohne einer While Schleife direkt per Telnet angebe gibt es keine Probleme.

Aber innerhalb einer While Schleife geht es mit dem voipd Daemon:

voipd -U #tell voipd to unregister and disconnect all calls now.
voipd -R #tell voipd to register now.

sleep 43200 #Alle 12 Stunden VOIP Reregister

if [ $? -eq 0 ]; then
echo "VOIP Restart Start"
voipd -U
sleep 5
voipd -R
echo "VOIP Restart Done"
fi
done

Vielen Dank an mühevollen Antworten, die viel Zeit und Hirnschmalz in Anspruch genommen haben!

#SOLVED

 

[GottSeth]

Folgendes ADSL Modem wird genutzt TP-Link AC1750, der Port 5060 TCP+UDP sowie für Audio RTP 7078-7100 sind schon weitergeleitet auf die 192.168.5.50 (Diese Staische IP ist die WAN Port IP der Fritzbox am LAN1). Habe auch keine anderen VOIP Dienste im Netz, nur die der FritzBox. Die Registrierung wird mittels UDP und nicht per TCP durchgeführt, wurde mit Wireshark geprüft. Es wird auch kein Stun oder Proxy genutz.

Ja hab ich auf 30Sek, das sollte doch wie z.B. von Linksys bekannt das Nat Keep Alive sein.

Hier wird dein "Problem" liegen = doppelt gemoppelt !

Nimm mal die Port-Weiterleitung raus - nur "keep alive" reicht völlig

 

[baxter2015]

Das sollte dann doch eigentlich bei einer Port-Weiterleitung doch gar nicht mehr greifen bzw. es sollte Irrelevant sein ob keep alive an oder aus ist.

Da so oder so alle UDP oder RTP Packete an die Box Forwarded werden.

 

[GottSeth]

Sollte/könnte/müsste

Es macht ja auch keinen Sinn, auf nem PC 5 verschiedene Firewalls und 10 Virenscanner zu installieren, weil sich das Zeugs ständig in die Quere kommt !

Du sagst ja auch, es funzt ne ganze Zeit lang - vermutlich so lange, bis beide Regeln zeitgleich "greifen" wollen