Beiträge von Uwe

  • DECT Hardware

    bitte nicht DECT-Reichweite und WLAN-Reichweite in einen Topf schmeißen und bei den "bei mir reicht einer für x m²" Angaben dazu schreiben, ob ihr von DECT oder WLAN sprecht. Geht sonst glaube ich grad etwas durcheinander.

  • DECT Hardware

    DECT ist was die Reichweite angeht, sehr unkritisch. Haben auch nur eine Basisstation, die überhaupt nicht mittig steht. DECT geht trotzdem über 4 Etagen und im ganzen Garten

  • UDM pro auf Dream machine SE keine WAN IP bei PPPOE

    Zitat von dreambox1234567

    Wieso beides?


    Draytek stellt nur die DSL Verbindung her und die UDM SE soll die Einwahl machen

    weil Du einmal schreibts, dass es mit PPPoE immer funktioniert hat, mit der UDM SE aber nicht. Dafür würde hier DHCP funktionieren. Das kann aber eigentlich nicht sein, Weil eben kein Provider BEIDES anbietet.
    Drum passt da noch irgendwas bei Deinen Beschreibungen nicht.

  • Voucher Landingpage wird bei Apple Geräten nicht angezeigt

    Du müsstest ein paar mehr Infos liefern.


    Paar Screenshost, wie das am Apple Gerät aussieht.


    Außerdem: Hast Du am iPhone VPN, Private WLAN-Adresse, Tracking beschränken etc. aktiv? Dann würde ich es zumindest zur Fehlersuche ausschalten (sollte nicht die Ursache sein, macht die Suche aber einfacher)

  • UDM pro auf Dream machine SE keine WAN IP bei PPPOE

    mit der Pro hat ja aber angeblich PPPoE funktioniert.


    Mir ist zumindest kein Anbieter bekannt, der beides wahlweise anbietet und ich mich als Kunde selbst entscheiden kann.

    Insofern wäre der Anbieter hier interessant und welchen Zugangsweg er verlangt.


    Und wenn es PPPoE mit VLAN ist, dann schauen wo das VLAN eingestellt ist. Ich hatte VLAN 7 (Telekom) immer im Draytek und bei der PPPoE Einwahl in der UDM kein VLAN angegeben. Geht auch genau umgekehrt.

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