Beiträge von Uwe

  • Logs die mehr Aufschluss über Internetausfälle geben?

    dns.telekom,de gefällt mir gut der steht auf jeden Fall näher als Cloudflare/Google. Ok, sind auch 5 hops und Cloudflare 7. Kein gigantischer Unterschied, aber innerhalb des Telekom Netzes sollte es trotzdem zuverlässiger sein.



    Code
      1     1 ms     1 ms     1 ms  unifi.lan [10.1.1.253]
  2     3 ms     2 ms     2 ms  p5092800d.dip0.t-ipconnect.de [80.146.128.13]
  3     6 ms     6 ms     5 ms  m-ea10-i.M.DE.NET.DTAG.DE [62.154.28.98]
  4     6 ms     6 ms     6 ms  217.0.39.193
  5     5 ms     5 ms     5 ms  m-nxr-a02.isp.t-ipnet.de [217.0.43.162]
    Code
      1     1 ms    <1 ms    <1 ms  unifi.lan [10.1.1.253]
  2     2 ms     2 ms     2 ms  p5092800d.dip0.t-ipconnect.de [80.146.128.13]
  3     7 ms     7 ms     7 ms  m-ef2-i.M.DE.NET.DTAG.DE [217.0.200.78]
  4     7 ms     6 ms     7 ms  m-ef2-i.M.DE.NET.DTAG.DE [217.0.200.78]
  5    10 ms    11 ms    10 ms  80.150.168.185
  6     *       10 ms     *     cloudflare-gw.cr0-muc1.ip4.gtt.net [141.136.100.98]
  7     8 ms     8 ms     8 ms  one.one.one.one [1.1.1.1]

  • UniFi OS Requires a Restart

    Die gestern veröffentliche 4.0.6 hat den Fix schon mit drin. Ist jetzt installiert.

    die .bak ist wieder weg, die .so ist wieder da.


    Ob's hilft, wird sich zeigen, Fehler kam so grob 1x pro Woche.

  • UniFi OS Requires a Restart

    Wenn eine .so unter Linux sowas wie ne .DLL unter Windows ist, dann wird die beim Neustart neu angelegt?

    (Sorry für die doofen Fragen, aber Linux liegt von mir aus betrachtet stark Richtung Böhmen...)

  • UniFi OS Requires a Restart

    UI schreibt:


    Zitat

    Thank you for bringing this to our attention. Our development team has investigated the issue and identified it for resolution in one of the upcoming versions. We appreciate your understanding and patience as we work on releasing the fix. We don't have a set timeframe right now, but we recommend keeping an eye on the community.ui.com/releases page for updates.

    als Fix soll ich entweder eine Custom-FW laden oder diesen Befehl ausführen:


    Code
    mv /usr/lib/aarch64-linux-gnu/ulogd/ulogd_inpflow_NFCT.so /usr/lib/aarch64-linux-gnu/ulogd/ulogd_inpflow_NFCT.so.bak systemctl restart ulogd2

    Meine Linux Kenntnisse sind marginal.


    Also "ulogd_inpflow_NFCT.so" wird umbenannt und damit "unschädlich" gemacht, oder?

    Danach der Service/Dämon neu gestartet, richtig?


    Das ist irgendein Teil von der FW, oder?

  • Logs die mehr Aufschluss über Internetausfälle geben?

    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:

    Zitat von Networker

    Providerseitige 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önnten

    Zitat von NetNovice

    Nur 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?

  • Logs die mehr Aufschluss über Internetausfälle geben?

    Zitat von NetNovice

    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?

    Zitat von NetNovice

    im Modem protokolliert

    ist ein Telekom-GF-Modem 2. Da ist nicht viel mit Protokoll.


    Zitat von NetNovice

    normaler Reconnect

    sollte es bei GF-Anschluss meines Wissens gar nicht geben. (und bei DSL vorher gabs das auch schon lange nicht mehr)

    Zitat von Uwe

    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.

  • Herstellerdaten für MAC-Adresse fehlerhaft

    Einreichen kann man noch immer. Kann man sich aber auch sparen. Das interessiert niemanden.

    Weiß nicht, wie es bei den MAC von Grundig ist, aber grundsätzlich sind viele Zuordnungen falsch hinterlegt. Ich hab da vor ca. 2 Jahren mal einiges an Mühe reingelegt und falsche Einträge dokumentiert und die korrekten Daten inkl. Nachweise beigefügt und über den Support gemeldet.

    Man hat sich lieb bedankt und das war es dann auch. Das interessiert da leider niemanden.