Hallo,
in welchem Log könnte ich Hinweise auf Verbindungsabbrüche finden?
Danke
Logs die mehr Aufschluss über Internetausfälle geben?
-
- Privat
- UDM
- Dream Machine Pro (UDM-Pro)
- offen
- Uwe
Es gibt 24 Antworten in diesem Thema, welches 3.921 mal aufgerufen wurde. Der letzte Beitrag () ist von Uwe.
-
Welches Gerät stellt bei dir die Verbindung zum Internet her?
-
System Log --> Filter "critical".
-
Ich meinte über SSH irgendwas, wo man vielleicht bischen mehr sieht.
Du kannst in /var/log/messages nach „wan-failover-„ Einträgen suchen. Da siehst du die Logeinträge der dpinger Prozesse. Falls du die Defaulteinstellung „ping.ui.com“ unter „Internet Verification Server“ nicht geändert hast, werden 1.1.1.1 (Cloudflare) und 8.8.8.8 (Google) standardmässig angepingt und zum Checken der Internetverbindung verwendet. Man sieht aber halt auch nur, daß die Verbindung unterbrochen wurde und nicht den Grund.
Du schreibst, dass die UDM-Pro die Internetverbindung aufbaut. Läuft das über PPPoE? Dann würde ich nach entsprechenden Logeinträgen suchen.
-
Da steht in der Regel auch nichts sinniges drin. Die Verbindung timeouted halt. Keine Antwort von der Gegenseite halt.
-
Mich interessiert in erster Linie, ob die Verbindungsprobleme auf den "letzten Kilometern" passieren und ich gegebenenfalls durch einen Reboot des Kabelmodems etwas dagegen unternehmen kann. Deshalb habe ich als "Internet Verification Server" den 1. Hop meiner Verbindung konfiguriert. Seitdem sind die sporadischen Warnungen wegen hoher Latenz und Abbrüchen verschwunden.
-
Deshalb habe ich als „Internet Verification Server“ den 1. Hop meiner Verbindung konfiguriert
Die Idee ist gar nicht schlecht.
Und danke für die Tipps, ich werde da mal bisschen stöbern. Ach so, und ja, per PPPoE.
-
Gibt es wirklich Unterbrechungen der Internetverbindung, die du auch spürst oder stehen die nur im Protokoll?
Es kommt manchmal vor, dass die UTM Probleme mit dem Internet meldet obwohl z.B. das Moden davor keinen Fehler erkennt. Wurde in verschiedenen Foren schon öfter diskutiert.
Geholfen hat da den ARP Cache Timeout in der UTM auf 30 zu stellen.
-
Falls jemand mal einen „Deep Dive“ in die Funktionsweise des Internet Verification Server machen will, kann ich dieses Video empfehlen. Die Stimme des Youtubers finde ich etwas gewöhnungsbedürftig. Aber seine Unifi Videos gehen ganz schön ans Eingemachte.
-
Gibt es wirklich Unterbrechungen der Internetverbindung, die du auch spürst oder stehen die nur im Protokoll?
Also zumindest zum Teil waren es spürbar echte Unterbrechungen. Den ARP Wert kontrolliere ich trotzdem mal.
-
Also zumindest zum Teil waren es spürbar echte Unterbrechungen. Den ARP Wert kontrolliere ich trotzdem mal.
Vielleicht mal abgleichen ob alle Unterbrechungen auch im Modem protokolliert werden oder ob es nur ein Teil davon ist.
Vielleicht ist es auch ein normaler Reconnect.
Bei mir ist Vodafone auch mal auf die Idee kommen das mittags zwischen 10 und 14 Uhr zu machen.
-
Geholfen hat da den ARP Cache Timeout in der UTM auf 30 zu stellen.
wollte ich gerade prüfen/ändern. Finde ich aber nicht. Was genau meinst Du, bzw. wo genau ist das?
im Modem protokolliert
ist ein Telekom-GF-Modem 2. Da ist nicht viel mit Protokoll.
normaler Reconnect
sollte es bei GF-Anschluss meines Wissens gar nicht geben. (und bei DSL vorher gabs das auch schon lange nicht mehr)
bzw. wo genau ist das?
gefunden. Das ist eine Device Einstellung. Dachte eine Network-EInstellung.
Hast Du das dann auf allen Switches geändert? Vorgabe, wenn ich auf Custom gehe, ist bei mir schon 30.
-
Nur in der Einstellung der UTM.
-
sollte es bei GF-Anschluss meines Wissens gar nicht geben. (und bei DSL vorher gabs das auch schon lange nicht mehr)
Du muss ich (leider) widersprechen: Providerseitige Reconnects haben und hatten nie mit der Übertragungstechnologie zu tun. Dies war schon immer eine rein firmenpolitische Entscheidung zur Gängelung der eigenen Nutzerschaft. Für unterbrechungsfreie Leitungen musstest Du früher z.B. SDSL-Tarife buchen. Da hattest Du 1/3 der Übertragungsleistung für den 5-fachen Preis eines DSL/VDSL-Anschlusses.
Die Telekom war vor Jahren irgendwann mal so "nett" und hat den Zwangs-Disconnect von 1x täglich auf 2x jährlich gestreckt - seither spüren die meisten User ihn nicht mehr, abgeschafft wurde er aber nicht.
Bei VDSL von 1&1, Vodafone, Telefonica etc. wirst Du meines Wissens nach bis heute 1x täglich rausgeworfen.
Leider beschützt Dich die Glasfaser also nicht automatisch vor blödsinniger Provider-Politik, wobei es schon so zu sein scheint, dass viele der neuen GF-Provider sich diese Gängelung erfreulicherweise tatsächlich verkneifen.
-
Ich schreib hier mal, was mir in den Logs so auffälliges über den Weg gelaufen ist. Vielleicht kann jemand zu dem ein oder anderen Punkt was sagen.
messages:
- zehntausende Einträge mit "UDM-ET kernel: nf_conntrack: nf_conntrack: table full, dropping packet"
- versteh ich das richtig? Müsste man da die state timeouts reduzieren?
- hunderte Einträge mit WAN-Failover, mehr oder weniger immer diese drei Beispiele, wobei das "could not resolve" auf verschiedene Domains geht.
- UDM-ET ubios-udapi-server[1255]: wan-failover-monitor-icmp: wf-monitor-ppp0-2-icmp (87.166.104.251->193.99.144.80) has dpinger update: 193.99.144.80 is down {"alarm":true,"id":"ppp0-mon2-193.99.144.80-heise.de","latencyAverage":5911.0,"latencyStdDev":540.0,"lossPercentage":52.63159942626953}
- UDM-ET ubios-udapi-server[1255]: wan-failover-monitors: wf-monitors-container-ppp0 (87.166.104.251) could not resolve google.com (a): Unsupported address family
- 2024-06-15T07:30:00+02:00 UDM-ET ubios-udapi-server[1255]: wan-failover-monitor-dns: wf-monitor-ppp0-3-dns (87.166.104.251->1.1.1.1) has dns-monitor update: 1.1.1.1:ui.com is up
2024-06-15T07:30:00+02:00 UDM-ET ubios-udapi-server[1255]: wan-failover-monitor-dns: wf-monitor-ppp0-4-dns (87.166.104.251->8.8.8.8) has dns-monitor update: 8.8.8.8:ui.com is up 2024-06-15T07:30:00+02:00 UDM-ET ubios-udapi-server[1255]: wan-failover-interfaces: wf-interface-ppp0 (87.166.104.251) is up [_DUU___] 2024-06-15T07:30:00+02:00 UDM-ET ubios-udapi-server[1255]: wan-failover-group-base: wf-group-1-single is up [u](ppp0)
error:
- tausende Einträge immer abwechselnd die zwei:
- dns-cache-db[2928]: dns-cache-db[2928]: dns-cache-db.cache_init(): Unable to import DNS cache from file /run/dns-cache-db/.dns-cache-974210.cache; dnsmasq may not be ready yet.
- dns-cache-db[2928]: dns-cache-db[2928]: dns-cache-db.import_dns_cache(): Failed to parse JSON file: /run/dns-cache-db/.dns-cache-974210.cache, line: 1, column: 19176, position: 19176, error: '}' expected near 'bidderrequest'
ppp0.log:
- da sieht ein Abbruch und Neuverbindung so aus:
Code
Alles anzeigenSend PPPOE Discovery V1T1 PADI session 0x0 length 12 dst ff:ff:ff:ff:ff:ff src 74:ac:b9:5e:f9:fb [service-name] [host-uniq c6 05 00 00] error sending pppoe packet: Network is down error receiving pppoe packet: Network is down Send PPPOE Discovery V1T1 PADI session 0x0 length 12 dst ff:ff:ff:ff:ff:ff src 74:ac:b9:5e:f9:fb [service-name] [host-uniq c6 05 00 00] Send PPPOE Discovery V1T1 PADI session 0x0 length 12 dst ff:ff:ff:ff:ff:ff src 74:ac:b9:5e:f9:fb [service-name] [host-uniq c6 05 00 00] Recv PPPOE Discovery V1T1 PADT session 0x42 length 0 dst 74:ac:b9:5e:f9:fb src 7c:e2:ca:bd:b0:0e Timeout waiting for PADO packets Unable to complete PPPoE Discovery Send PPPOE Discovery V1T1 PADI session 0x0 length 12 dst ff:ff:ff:ff:ff:ff src 74:ac:b9:5e:f9:fb [service-name] [host-uniq c6 05 00 00] Recv PPPOE Discovery V1T1 PADO session 0x0 length 42 dst 74:ac:b9:5e:f9:fb src 7c:e2:ca:bd:b0:0e [AC-name ERLJ03] [host-uniq c6 05 00 00] [service-name] [AC-cookie 63 9c d1 ad 73 c5 bc 27 3d 20 2d de d9 e1 d2 f7] Send PPPOE Discovery V1T1 PADR session 0x0 length 32 dst 7c:e2:ca:bd:b0:0e src 74:ac:b9:5e:f9:fb [service-name] [host-uniq c6 05 00 00] [AC-cookie 63 9c d1 ad 73 c5 bc 27 3d 20 2d de d9 e1 d2 f7] Recv PPPOE Discovery V1T1 PADS session 0x42 length 42 dst 74:ac:b9:5e:f9:fb src 7c:e2:ca:bd:b0:0e [service-name] [host-uniq c6 05 00 00] [AC-name ERLJ03] [AC-cookie 63 9c d1 ad 73 c5 bc 27 3d 20 2d de d9 e1 d2 f7] PADS: Service-Name: '' PPP session is 66 Connected to 7c:e2:ca:bd:b0:0e via interface eth10.7 using channel 1 Using interface ppp0 Connect: ppp0 <--> eth10.7 sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xe2a5fce>] rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0xe2a5fce>] rcvd [LCP ConfReq id=0x27 <mru 1492> <auth pap> <magic 0x7611fdcc>] sent [LCP ConfAck id=0x27 <mru 1492> <auth pap> <magic 0x7611fdcc>] sent [LCP EchoReq id=0x0 magic=0xe2a5fce] sent [PAP AuthReq id=0x1 user="0026167920365503171595960001@t-online.de" password=<hidden>] rcvd [LCP EchoRep id=0x0 magic=0x7611fdcc] rcvd [PAP AuthAck id=0x1 "SRU=275000#SRD=1099607#"] Remote message: SRU=275000#SRD=1099607# PAP authentication succeededProviderseitige Reconnects haben und hatten nie mit der Übertragungstechnologie zu tun
das da kein technischer Zusammenhang besteht, ist schon klar. Aber wie du selbst schreibst, ist es bei GF eher unüblich.
Und ich bin bei Telekom, gut, das 2x/Jahr kam mir in der Tat wie "gar nicht" vor. Zumindest schließt sich das als Ursache für 3 Abbrüche pro Woche dann aus. Darum ging es ja, ob die ReConnects der Grund sein könntenNur in der Einstellung der UTM.
hab ich dann auch gemerkt und wollte das in meinem Beitrag gleich noch mit ergänzen. Leider vergessen abzuschicken...
Welchen wert hast Du eingetragen?
- zehntausende Einträge mit "UDM-ET kernel: nf_conntrack: nf_conntrack: table full, dropping packet"
-
das da kein technischer Zusammenhang besteht, ist schon klar. Aber wie du selbst schreibst, ist es bei GF eher unüblich.
Und ich bin bei Telekom, gut, das 2x/Jahr kam mir in der Tat wie "gar nicht" vor. Zumindest schließt sich das als Ursache für 3 Abbrüche pro Woche dann aus. Darum ging es ja, ob die ReConnects der Grund sein könntenIch meine das auch nicht belehrend und hoffe, es kam nicht so rüber. Man muss sich nur vergegenwärtigen, dass in so einem Forum ja viele Leute mitlesen, im Zweifel auch nach Jahren noch über Suchmaschinen auf diesen Thread stoßen.
Daher finde ich es wichtig, mit allem möglichst präzise zu sein und ungenaue/falsche Aussagen zurecht zu rücken. Auch hier gibt es ja oft genug Leute, die mit irgendwo im Internet aufgeschnapptem Halbwissen zunächst mal ihr Vorhaben kräftig gegen die Wand fahren.
Aber Du hast natürlich Recht, dass dies nicht das eigentliche Thema des Threads ist.
-
hab ich dann auch gemerkt und wollte das in meinem Beitrag gleich noch mit ergänzen. Leider vergessen abzuschicken...
Welchen wert hast Du eingetragen?
Ich habe da 30 Sekunden eingetragen. Die Empfehlung kommt von einem UniFi Support aus einem Forum Beitrag.
Seit dem habe ich deutlich weniger Unterbrechungen im Protokoll. Die normalen Reconnects stehen natürlich weiterhin drin.
-
1. Hop meiner Verbindung konfiguriert.
Fand die Telekom wohl nicht lustig. Seit heute beantwortet der keine Pings mehr....
Was wäre denn ein guter, also sehr verlässlich erreichbarer Server, der Pings beantwortet?
