[gelöst] 7170: telefon a127.0.0.1 scheint System lahmzulegen

[jogruni]

Seit 2 Tagen kann ich praktisch nicht mehr telefonieren. Ich höre den Gesprächspartner nur abgehackt. Gleichzeitig steigt die Prozesslast auf über 6 und der Prozess

Load average: 11.18 7.17 6.2
PID PPID USER STAT VSZ %MEM %CPU COMMAND
802 1 root S 5708 19% 40% telefon a127.0.0.1​

hat zwischen 40 unf 50%.
Das Webinterface reagiert auch nur noch träge. Nach einem Neustart der Box läuft es ein paar Minuten normal und sobald die Prozesslast hoch geht, beginnen auch die Störungen (oder umgekehrt). Ich habe in den letzten Tagen keinerlei Änderungen an den Einstallungen der Box gemacht.
Hat jemand eine Idee was sein kann?

 

[Freenetler]

Ich weiß nicht, woher die 127.0.0.1 stammt. Das ist dein eigener Rechner = Localhost.

prüfe mal die Netzwerkeinstellungen in der FB ob da was falsch konfiguriert wurde.

evtl. hast du auch ein virus/Trojaner etc. der deine echte Adresse benutzt und die Fritzbox auf den localhost umleitet.

wenn du Windows hast findest du das in der Datei "hosts" im Systemverzeichnis.

ich nutze die hosts zum Beispiel um die nervigen sexseiten zu blocken.

127.0.0.1 mydirtyhobby.com bsp.

 

[doc456]

Sry, aber das ist Unfug, es ist der Telefon-Dämon der Box und der läuft auf localhost der Box.

@jogruni, mach einen Werksreset und anschließend ein sauberes Recover mit manueller Neueingabe aller Daten in die Box.

 

[jogruni]

Ich habe die Box recovered. Nach einiger Eingaben trat das Problem dann wieder auf. Jetzt versuche ich das Problem einzugrenzen.
Zuletzt habe ich 3 VPN Profile geladen.
Die habe ich erst mal alle deaktiviert und danach scheint das Problem weg zu sein. Jetzt schalte ich die der Reihe nach wieder an um zu sehen was passiert.
Ich verstehe zwar nicht ganz was VPN mit der Telefonie zu tun hat, aber vielleicht gibt es da einen Zusammenhang und der Telefonprozess wartet auf irgendwelche timeouts.

Ohne VPN (alle 3 deaktiviert) seit 3h OK.

Etwas zur Erläuterung:
Die betroffene 7170 steht in Kanada. ist per Kabelmodem und Internet über LAN1 angebunde. 2 kanadische und 3 deutsche Rufnummern eingetragen. Uhr auf PST/PDST gesetzt. TZ_string = "PST+8PSDST+7,M3.2.0/02:00:00,M11.1.0/03:00:00";
VPN Partner1 7390 in Deutschland
VPN-Partner2 7170 ebenfalls in Kanada per DSL-Moden und LAN1 angebunden.

Ergänzung:
Es scheint tatsächlich die VPN Verbindung nach Deutschland zu sein. Sobald die aktiv ist, geht die Last nach einigen minuten nach oben und der Telefon Daemon verbraucht ~50% der Rechenzeit. Sobald ich diese VPN-Verbindung deaktiviere ist alles wieder normal.

 

[doc456]

Ahh, jetzt ja!

Kann es sein, das du an der Kanada-Box in der voip.cfg bei reg_from_outside gefummelt hast?

 

[jogruni]

Sehr guter Tipp :groesste:
Ich hatte tatsächlich vor Wochen mal damit experimentiert, aber spätestens durch das Recovery sollten diese Einstellungen weg sein. Ich habe es such nochmals geprüft und nichts mehr in der voip.cfg gefunden. (in keiner der configs)

Ich verstehe nur nicht, warum das plötzlich begonnen hat. Wie gesagt die letzten 3 oder 4 Wochen habe ich keinerlei Änderungen an einer der Boxen gemacht und keine besonderen Probleme gehabt und plötzlich dieses Verhalten. Ich kann es auch klar an einer Verbindung festmachen. Wenn die aktiv ist, klemmt es.:noidea:

Ich habe noch eine Vermutung, dass es mit der Zeitumstellung zu tun haben könnte und die Boxen habe unterschiedliche Zeitzonen eingestellt. Deutschland hat ja schon umgestellt und Kanada folgt erst in 2 wochen. Aber die funktionierende Box hier in Kanada hat auch die Default Zeitzone. Nur die vom Problem betroffene hat eine andere Zeitzone. Dann müssten beide Verbindungen den Fehler verursachen.

Ich werde jetzt nochmal die VPN Konfiguratonen neu generieren und dann sehen was passiert.

Ergänzung:
Auch nachdem ich die VPN profile neu erzeugt habe, legt das starten des VPN-Kanals nach Deutschland die Telefonie lahm. Jetzt bin ich etwas ratlos

 

[Freenetler]

Telefon-Dämon der Box und der läuft auf localhost der Box.

Oh! Danke, wieder etwas gelernt. Habe mich schon gefragt, woher die Angaben stammen.

Kann man das irgendwo aus der FB auslesen? In meinen Push-Protokollen stehen ja nur die IP Daten der Gegenstelle, aber nirgends die Daten, die beim Kanadier im Thread standen.

 

[jogruni]

Bei mir ist telnetd aktiviert und ich habe auf dem USB-Stick eine erweiterte Version von busybox installiert, die auch die Befehle wie "top" ausführen kann. "top" zeigt an welche prozesse gerade die meiste CPU % Auslastung haben (man kann auch nach anderen Kriterien sortieren).

Zum Problem:
Seit heute kann ich wieder beide VPN Verbindungen aktivieren, ohne dass der "telefon" Daemon die Leistung frißt. Jetzt "idled" die Box wieder 90-95%. Werde das heute noch mal beobachten, bevor ich [erledigt] an den Thread schreibe.
Muss man das immer verstehen?

 

[doc456]

Neee, verstehen muß man so manches nicht, aber seltsam ist das schon...

Hattest du reg_from_outside wieder raus genommen?

 

[jogruni]

Wie gesagt, ich hatte vor Wochen mal damit experimentiert. In den Einstellungen VOR dem Recover war unter "extentions" "reg_from_outside = no;" eingetrahen. In den Einstellungen NACH dem Recover/Werksreset ist kein Eintrag. Aber mit diesen Einstellungen trat der Fehler auch auf.

Ich hatte am Samstag, als das Problem begann einige male auch Probleme mit der Erreichbarkeit verschiedener Domains aus dem Shaw-Cable (Kanadischer Internetanbieter) Netzwerk heraus. Bestimmte Seiten wurden per DNS nicht aufgelöst. Vielleicht hatte die Box vorübergehend irgendwelchen DNS probleme. Das DNS Problem war aber Samstag Abend wieder weg. Mein Lastproblem war aber noch da. Der dyndns name der deutschen Box war aber immer erreichbar.

Bis gestern Abend wirklich eindeutig nachvollziebar.
VPN nach DE an (eine weitere VPN nach CA war immer an) - Telefon nach 10-20sec lahmgelegt.
VPN nach DE aus - Telefon OK.
Hatte zig mal ein und ausgeschaltet - immer reproduzierbar.

Jetzt sind beide VPN an und Telefon ist okay und ich hoffe das bleibt so :nock on wood:

 

[doc456]

Prima! Dann beobachte das mal. Zur Not kill einfach den Dämon und starte ihn neu, bevor du die Box wieder resetest.

 

[jogruni]

Wenn Du mit "kill den daemon" meinst dass ich das lastfressende "telefon" mit kill abbrechen soll, dann hat das nicht geholfen, denn sobald der eine daemon tot war, hatte ich soweit ich mich erinnern kann kein freizeichen mehr und der nächste telefon Daemon fraß die Leistung. Aber so ganz genau kann ich das jetzt nicht mehr sagen, weil nicht mehr nachvollziehbar.

 

[doc456]

Uhhh, dann lass es lieber und starte die Box dann neu. Aber Hauptsache es geht jetzt...

 

[jogruni]

Habe es jetzt doch wieder etwas abgeschwächt. Aber damit auch eingekreist.

Hat wohl mit der Last auf dem VPN Kanal zu tun. Die letzten Tage, wurden relativ viele Daten über den VPN kanal syncronisiert (rsync auf interne IPs).

Heute wurden praktisch keine Daten syncronisiert und das Problem war weg.

Wenn ich per interner VPN auf eine Webcam in Deutschland zugreife, dann gibt es Störungen und "telefon" Last ist um die 20-30%.

Bei rsync über VPN geht die Last von telefon auf 50% und die Störungen sind stark.

Bei Zugriff auf die Webcam über die externe IP/Dyndns und Portweiterleitung gibt es keine Störungen.

Die Box scheint wohl mit dem VPN überlastet zu sein (andere Seite ist eine 7390) und ich muss die Syncronisierungen wohl auf die externen IPs umstellen und dann ist die VPN Verschlüsselung/Komprimierung nicht belastet.

Das schein wohl die Ursache zu sein.

Ich habe Ende letzter Woche Einstellungen an einem Filesyncronisations-job auf einem Linux Rechner geändert. Bisher ging das über 2 Ecken. DE-7390VDSL -> Strato-dedicated-server -> CA-7170 (rsync ohne VPN). Und letzte Woche habe ich das auf DE-7390VDSL -> CA-7170 über VPN geändert. Da muss ich wohl besser diese großen datenmengen über externe IP machen und damit die 7170 mit der Verschlüsslung verschonen. Die machen dann die Linux Rechner.

Kann man die Priorität für die VPN verschlüsselung herunterdrehen?

Damit kommt doch etwas Lich ins Dunkle :idea:

 

[doc456]

Hi,

Kann man die Priorität für die VPN verschlüsselung herunterdrehen?

was meinst du mit Priorität? Meinst du die bei laufendem Dämon im Speicher? Nee, nicht das ich wüßte, es sei denn mit Freetz.

Versuch es doch mit dem Drehen des Verbindungsaufbau's, denn der, der die Verbindung aufbaut hat, handelt imho die Verschlüsselung aus, ergo hat der die Schlüsselverwaltung. :noidea:

 

[jogruni]

Hi,was meinst du mit Priorität?

Es gibt doch die Möglichkeit bestimmte Pakettypen (Media, VoIP, HTTP,...) verschieden zu Priorisieren. Also Priorität für VoIP hoch und VPN herunter.
Aber leider kann man bei Priorisierung VPN nicht auswählen.

Versuch es doch mit dem Drehen des Verbindungsaufbau's, denn der, der die Verbindung aufbaut hat, handelt imho die Verschlüsselung aus, ergo hat der die Schlüsselverwaltung. :noidea:

Ich weiß nicht ob Verschlüsseln mehr oder weniger Rechenlast erzeugt, aber es kommt auf die Richtung des Datenstroms an, wo ver- und wo entschlüsselt wird, nicht auf den Verbindungsaufbau.

Ich kann mir aber vorstellen, dass die 7390 wesentlich mehr Daten verschlüsseln kann, als eine 7170. Daher hann ich mir schon vorstellen, dass bei maximaler Ausnutzung der 5MBit Upload bei der 7390, diese Daten dann in der 7170 (16MBit Anbindung) auch 5MBit ankommen und entschlüsselt werden müssen. Die 7170 muss daher einen 5MBit Stream entschlüsseln. Damit könnte dann die 7170 einfach überfordert sein.

Die 2. Verbindung 7170<->7170 hat auf der meiner Seite 1MBit upload und auf der anderen Seite 0.5MBit. Daten kommen also hier nur mit 500kBit an. Also muss die 7170 500kBit entschlüsseln als 10% der Menge wie bei den Daten der 7390. Das schafft die 7170 sicher besser.

Habe jetzt auch festgestellt, dass die VPN Übertragung meist nur 1-2MBit geschafft hat, während die normale Übertragung jetzt fast die 5MBit schafft. Zeigt eventuell, dass die 7170 Entschlüssung der Flaschenhals ist.

Ist zwar nur eine Vermutung, aber scheint mir inzwischen schlüssig und erklärt die Beobachtungen.

 

[doc456]

Ach die Priorisierung meintest du.

Und ja, die 7390 kann erheblich mehr durch höhere Prozessorleistung.
Daher könnte deine Erkenntnis mit der Ver-/Entschlüsselung schon stimmig sein.

Und wenn du dann noch bei Telefonie den Codec aushandeln lässt, dann wird er haarig auf der 7170. Stell mal "immer Festnetzqualität nutzen" ein, das sollte Abhilfe schaffen.

 

[jogruni]

Stell mal "immer Festnetzqualität nutzen" ein, das sollte Abhilfe schaffen.

80% der Gespräche werden in G711 geführt und 20% G711u. Ich denke das sind alles gering komprimierte Verfahren, die den Prozessor nicht alzu sehr belasten sollten.

Ich habe nochmal nachgemessen und die Ergebnisse untermauern meine Vermutungen:

Wöhren der Messung habe ich den AB abgehört:

Prozente für voipd und idle(Leerlauf)
keine Daten ~10% voipd ~75% idle keine Störungen

von 7390 empfangen
VPN 4MBit ~70% voipd ~2% idle unverständlich
normal 5MBit ~10% voipd ~60% idle keine Störungen

an 7170 gesendet
VPN 1MBit ~30% voipd ~30% idle keine Störungen

von 7170 empfangen
VPN 0,5MBit ~20% voipd ~66% idle keine Störungen​

1MBit VPN Datenstrom verkraftet die 7170 aber bei 4MBit ist die 7170 am Ende. Ich denke man kann maximal mit 1-2MBit VPN Strom verarbeiten, was dem maximalen Upstream an einer DSL-Leitung entspricht.

Für mich steht fest, dass die 7170 mit dem 5MBit VPN Datenstrom überlastet ist. Ich werde halt die großen Datenmengen nicht über VPN übertragen.

@doc:
Danke für die hilfreichen Tipps. Ich hatte schon an Geister geglaubt aber jetzt doch eine plausible Erklärung.
:shock:Obwohl es war Halloween:beerdigu:

 

[doc456]

Gerne! Bis denne...