Seit dem upgrade wieder vermehrt packet loss. mehrmals täglich Das Problem hatte ich mit 2.5.11 selten bis gar nicht
Beiträge von xinput
-
-
nun hab jezt vor 3 Tagen von 2.5.11 auf 3.0.17 geupgraded.. vorher war alles wunderbar und jetzt siehe da:
werde das noch ein Paar tage beobachten und im Zweifel wieder downgraden
-
Also ich hab diverse applikationen als docker container laufen:
DashyVaultwarden
Tiny Tiny RSS
yourspotify
Home Assistant
Nginx Proxy Manager
vielleicht nicht unbedingt dinge die man braucht (abgesehn von Vaultwarden, das ist definitiv pflicht m.E.n.), aber wenn man die Resourcen ohnehin zur verfügung stehen hat, warum nicht auch nutzen.
-
Habt ihr eigentlich alle die Firnware 3.0.13 drauf laufen? Ich habe mich bishe rnicht getraut von 2.5.11 zu updaten da im Unifi Forum doch noch recht viele behauptetetn dass 3.0.13 sehr viele Probelem hervorgerufen hatte.
Aktuell kämpfe ich bei 2.5.11 nur mit dem Problem dass ich ca 1x täglich einen Packet loss bekomme und dann für 2-5 Minuten Mein Internety ausfällt (hinter einer Fritzbox im Bridge) aber sosnst läuft alles recht rund.
-
Ich nutze auch Bitwarden, da es ohnehin mein Password Manager ist. Aber habe eine Zeit lang auch Authy benutzt und war mit Authy sehr zufrieden.
-
Natürlich kannst du die IP vom Pihole als WAN DNS nutzen, dann geht jeglicher DNS traffic über dein Pihole. Nachteil an dieser Variante ist aber, dass du den DNS traffic nicht unterscheiden kannst da jeder DNS request auif dem Pi-hole vom USG kommt und somit ggf. Debugging am Ende schwer ist wenn etwas geblockt wird was nicht geblockt werden soll.
Ich emopfehle daher die IP vom Pihole in jedem VLAN als DHCP DNS Server zu hinterlegen, so bekommt jeder client per DHCP seinen DNS server und du siehst auf dem Pihole die DNS requests von den jeweiligen client hostnames. -
Hi, also in meiner unbound config habe ich nur zu IPv6 folgendes eingestellt:
prefer-ipv6: no
EDIT:Habe mir mal die Zeit genommen und den raspberry pi neu aufgesetzt mit aktuellem OS und allem. Geht jetzt wieder.
-
Servus zusammen,
Ich habe bei mir zuhause ein Pi Hole mit unbound (v1.9.0) als lokalen DNS resolver laufen. davor hängt eine UDR die am Bridge Port einer Fritzbox angeschlossen ist.Das ganze lief die letzten 2 Jahre auch Reibungslos.
Jetzt ist es vorgestern vorgekommen, dass es in meiner Wohnung einen Stromausfall gab der eine 4 stunden Downtime meiner Geräte nach sich zog.
Als nach dem Ausfall wieder alles online war ist mir aufgefallen, dass mein unbound resolver mir für einige Domains nur noch ein SERVFAIL zurück gibt. (In meinem speziellen Fall ist es "Trakt.tv")
Mein ersten Lösungsansätze waren wie folgt:
- Unbound restartet
- Pi restartet
- Package updates installiert
- root hints geupdated
Als diese nicht halfen hatte ich den verdacht das DNSSEC das problem sein könnte und habe folgendes in meiner unbound config eingebaut:
unbound restarted und erneut versucht, kein Erfolg.
Also habe ich anschließend die verbosity vom log auf 4 gestellt und habe am ende folgende log einträge gefunden:
Code
Alles anzeigenNov 30 09:23:46 unbound[9873:0] info: processTargetResponse super trakt.tv. A IN Nov 30 09:23:46 unbound[9873:0] debug: added target response Nov 30 09:23:46 unbound[9873:0] info: DelegationPoint<tv.>: 4 names (0 missing), 8 addrs (4 result, 0 avail) parentNS Nov 30 09:23:46 unbound[9873:0] info: ac4.nstld.com. * A AAAA PSIDE_A PSIDE_AAAA Nov 30 09:23:46 unbound[9873:0] info: ac3.nstld.com. * A AAAA PSIDE_A PSIDE_AAAA Nov 30 09:23:46 unbound[9873:0] info: ac2.nstld.com. * A AAAA PSIDE_A PSIDE_AAAA Nov 30 09:23:46 unbound[9873:0] info: ac1.nstld.com. * A AAAA Nov 30 09:23:46 unbound[9873:0] debug: ip6 2001:500:123::30 port 53 (len 28) Nov 30 09:23:46 unbound[9873:0] debug: ip4 192.42.176.30 port 53 (len 16) Nov 30 09:23:46 unbound[9873:0] debug: ip6 2001:500:122::30 port 53 (len 28) Nov 30 09:23:46 unbound[9873:0] debug: ip4 192.42.175.30 port 53 (len 16) Nov 30 09:23:46 unbound[9873:0] debug: ip6 2001:500:121::30 port 53 (len 28) Nov 30 09:23:46 unbound[9873:0] debug: ip4 192.42.174.30 port 53 (len 16) Nov 30 09:23:46 unbound[9873:0] debug: ip6 2001:500:120::30 port 53 (len 28) Nov 30 09:23:46 unbound[9873:0] debug: ip4 192.42.173.30 port 53 (len 16) Nov 30 09:23:46 unbound[9873:0] debug: iterator[module 2] operate: extstate:module_wait_subquery event:module_event_pass Nov 30 09:23:46 unbound[9873:0] info: iterator operate: query trakt.tv. A IN Nov 30 09:23:46 unbound[9873:0] debug: iter_handle processing q with state QUERY TARGETS STATE Nov 30 09:23:46 unbound[9873:0] info: processQueryTargets: trakt.tv. A IN Nov 30 09:23:46 unbound[9873:0] debug: processQueryTargets: targetqueries 0, currentqueries 0 sentcount 4 Nov 30 09:23:46 unbound[9873:0] debug: request has exceeded the maximum number of nxdomain nameserver lookups with 6 Nov 30 09:23:46 unbound[9873:0] debug: return error response SERVFAIL Nov 30 09:23:46 unbound[9873:0] debug: mesh_run: iterator module exit state is module_finished
hab bereits etwas gegoogelt aber keine wirklich hilfreiche antwort zu meinem Problem gefunden.
Hat jemand ne Idee?
Schon mal vielen Dank und beste Grüße
-
Klasse, MSS disabled?
Jap, bzw steht halt nicht auf auto sondern manuell auf 1452
-
-
ich hab mal heute meine Network application version auf 7.2.95 geupdated. Hatte vorher 7.2.91 und bisher sieht es schonmal ganz gut aus. Heute morgen kurz High latency aber sonst stabil
-
Habe ich auch mal getestet, danke für den Hinweis. ich berichte wie es bei mir aussieht.
-
Den Download auf 0 stellen, dann wird da nichts gedrosselt..
doch tatsächlich schon. Der download stand bei mir auf 0, aber sobald smart queues aktiv ist kommen meine endgeräte nicht mehr über 300Mbits. Meist sogar drunter. Habs nun mehrfach getestet und validiert. In der beschreibung von smart queues steht vermutlich deshalb auch dass es nicht empfohlen ist für internet links mit über 300Mbits
-
ich hab dazu nach wie vor ein Ticket offen, halte euch auf dem Laufenden.
kannst du mir ggf den Link zukommen lassen? Ich würde da gerne mal mit einspringen. Smart queues mildert das Problem zwar bei mir aber drosselt auch meine Leitrung runter auf 300Mbits, ist bei ner 1G Leitung leider etwas doof.
-
Auch von mir vielen Dank für den Tipp. Macht das Problem deutlcih seltener. Dennoch taucht es hier und da auf.
Hoffe dass es mit einem zukünftigen update behoben wird. Ein downgrade der Firmware würde ich gerne vermeiden. Alles wieder per hand zu konfigurieren nimmt dann doch leider schon viel Zeit in anspruch
-
bei mir läuft die UDM hinter nem Zyxel Modem im Bridgemodus ...
Meine laienhafte vermutung wäre hier dass es was mit dem Bridge mode zu tun hat.
-
Moin, ich weiss nicht ob das hilft, ich hab jetzt nicht den kompletten thread durchgelesen aber ich hatte exakt das gleiche problem.
Bei mir lag es am ende daran dass meine UDR hinter einer Fritzbox im Bridge modus (Cable internet) hing.
ZUfälligerweise hat sich 1 tag nach dem ich dieses Projekt gestartet habe, meine Fritzbox verabschiedet. Der Bridge Modus ging nicht mehr. Also habe ich meine komplette umgebung umgebaut und betreibe jetzt die UDR als exposed host auf der Fritzbox.Nachdem ich das so konfiguriert hatte ging der SSL request vom NPM direkt durch ohne zu meckern.
Hast du ggf. einen ähnlichen fall?
-
Okay, es scheint als hätte ich das Problem lösen können.
Der Fehler lag hier scheinbar am Bridge mode der Fritzbox. Die UDR läuft jetzt als exposed host hinter der Fritzbox und jetzt klappte alles.
Mysteriös. -
Also die Portweiterleitungen dürften funktionieren. Zumindest die auf Port 80. Habe dennoch schon die Weiterleitungen gelöscht, die UDR neugestartet und die Weiterleitungen neu angelegt. Komme leider zum selben ergebnis.
Hab den anderen Thread leider schon durchgekaut ohne erfolg bisher. -
Nabend zusammen,
ich arbeite aktuell dadran auf einem Pi mit ein Nginx Proxy manager zu installieren.Beim anlegen eines hosts mit SSL komme ich jedoch nicht weiter.
Ich bekomme vom Certbot immer folgenden Fehler:
CodeCertbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems: Domain: subdomain.domain.de Type: connection Detail: xx.xx.xx.xx: Fetching http://subdomain.domain.de/.well-known/acme-challenge/token: Timeout during connect (likely firewall problem) Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.
Die Port weiterleitungen gehen durch und neugestartet habe ich dir UDR auch schon. Der fehler bleibt bestehen.
Wenn ich SSL nicht aktiviert habe kann ich meinen host aus dem internet aufrufen. Also port 80 Weiterleitung scheint definitiv zu gehen.
Meine Forward rules sind wie folgt
192.168.178.7 ist hier mein Nginx Proxy manager host.
hat jemand eine Idee wo hier der Hund begraben liegt?
Danke und VG
Pascal