Das längste Thema

  • Apt-Log von Mittwoch

    Code
    Start-Date: 2018-04-03  10:49:37
    Commandline: apt-get upgrade
    Requested-By: pzillmann (1000)
    Upgrade: openssl:amd64 (1.1.0f-3+deb9u1, 1.1.0f-3+deb9u2), libsystemd0:amd64 (232-25+deb9u2, 232-25+deb9u3), libicu57:amd64 (57.1-6+deb9u1, 57.1-6+deb9u2), udev:amd64 (232-25+deb9u2, 232-25+deb9u3), libudev1:amd64 (232-25+deb9u2, 232-25+deb9u3), systemd-sysv:amd64 (232-25+deb9u2, 232-25+deb9u3), libpam-systemd:amd64 (232-25+deb9u2, 232-25+deb9u3), systemd:amd64 (232-25+deb9u2, 232-25+deb9u3), libssl1.1:amd64 (1.1.0f-3+deb9u1, 1.1.0f-3+deb9u2), libssl1.0.2:amd64 (1.0.2l-2+deb9u2, 1.0.2l-2+deb9u3), tzdata:amd64 (2018c-0+deb9u1, 2018d-0+deb9u1)
    End-Date: 2018-04-03  10:50:30

    Am Abend darauf fingen die Probleme an. Aktuell wieder ICMPv6 Probleme zu zwei Hosts.

    Hat jemand gerade ähnliche Probleme? Ist kein Root-Server

    Mach uns ein paar Traceroute6, bitte. UDP oder ICMP oder TCP, egal...

  • Mach uns ein paar Traceroute6, bitte. UDP oder ICMP oder TCP, egal...

    Code
    traceroute to ldap.h6g-server.net (2a03:4000:2:62b::1), 30 hops max, 80 byte packets
     1  gw01.netcup.net (2a03:4000:6:d000::2)  0.937 ms  0.863 ms  0.881 ms
     2  ldap.h6g-server.net (2a03:4000:2:62b::1)  3.321 ms  3.420 ms *
    
    traceroute to ldap2.h6g-server.net (2a03:4000:9:391::1), 30 hops max, 80 byte packets
     1  gw01.netcup.net (2a03:4000:6:d000::2)  0.617 ms  0.685 ms  0.656 ms
     2  * ldap2.h6g-server.net (2a03:4000:9:391::1)  0.498 ms  0.596 ms
  • Ich könnte mir vorstellen, dass die fehlenden Antworten nicht zwangsläufig auf ein Problem hindeuten müssen. Mittlerweile sind Router beizeiten so intelligent unter Last nur einen Teil der RTTs zu beantworten. Sorgen würde es mir machen, wenn auch Paketverluste auftreten.

    Siehst Du einen Unterschied, wenn Du reine ICMP-Traceroutes (traceroute -I) oder TCP-Traceroutes (traceroute -T) anstelle von Standardtraceroutes machst?


    Du könntest auch einmal schauen, ob die beiden Hosts nicht ohnedies einander linklokal sehen. -> ping6 -c2 fe80::[EUI64 von ldap2] und vice versa. Wäre dies der Fall, müssen wir den Gateway erst gar nicht bemühen, sofern das zugelassen wird.

  • Ist ja nicht nur auf IPv6 beschränkt.

    Nur ICMPv6 ist gerade am Auffälligstem. Aktuell pegelt er sich im LAN bei 200 ~ 30 ms ein.

    Meine Firewall ist für ICMP-Traceroutes zu den ldap Kisten zu restriktiv.


    Sporadisch gehen ja Pakete verloren.

  • Ich wollte eure Diskussion nicht unterbrechen, tu dies aber trotzdem.


    Ist hier unter uns ein WLAN Guru?


    Ich verzweifle seit einigen Tagen/Wochen an Verbindungsabbrüchen bei meinen UniFis.


    Ich habe hier im Haus 3 Stück davon, relativ nah bei einander.


    Im 2,4GHz Netz hab ich in einem Raum das Problem, dass andauernd eine ‚Passwort fehlerhaft‘ Meldung aufspringt und ich die Verbindung verliere.


    Überlappende Kanäle gibts so gut wie garkeine. Weder von mir selbst, noch von Nachbarn. Ich nutze auf dem 2,4GHz Band die Kanäle und 1,6,11.


    Zudem ist sehr auffällig, dass ich sehr viele verworfene und wiederholte Pakete habe, was sich auch auf der Auslastung des Kanals wiederspiegelt.


    Mein FireTV mit Kodi (connected auf meine Vu+) ruckelt auch bei HD-Streams pausenlos, obwohl das Signal mit gut 60-70db gut bis sehr gut ist.


    Ich bin leider mit meinem Latein am Ende.

    Achja, 5GHz funktioniert ohne Abbrüche, aber ebenfalls mit Ruckeln beim FireTV Stick..



    lg.

  • Nanü? Beide Endpunkte zeigen auch von meinem Internetanschluss einzelne Pakete mit hoher Antwortzeit.

    Ein Neustart der Beiden hat es jetzt gerichtet - obwohl beide erst seit 30 Tagen laufen.

    (die zwei anderen waren wohl statistische Ausreißer dazu...)


    Kernel 4.14.20

  • Nanü? Beide Endpunkte zeigen auch von meinem Internetanschluss einzelne Pakete mit hoher Antwortzeit.

    Ein Neustart der Beiden hat es jetzt gerichtet - obwohl beide erst seit 30 Tagen laufen.

    (die zwei anderen waren wohl statistische Ausreißer dazu...)


    Kernel 4.14.20

    Strange... was die ICMPs anbelangt... request, reply und message to big sollte man (in der jeweils sinnvollen Richtung) immer durchlassen - sonst gibt's früher oder später einmal MTU Probleme, was sich vor allem bei Verschlüsselung bemerkbar macht.

  • Mit Ubnt UniFy habe ich keine Erfahrung, kann also nur das Demo-System nützen: https://demo.ubnt.com/manage/site/default/dashboard

    WLAN-Geräte „relativ nah beieinander“ sind an sich keine gute Idee, da im unmittelbaren Nahbereich Übersteuern im gesamten 2.4 Band möglich ist. Bei den alten WRT54G/GL, die noch 802.11b/n nützten hat das einmal jemand bei Funkfeuer Graz gemessen. Den Link finde ich nicht mehr. Das Phänomen wird aber auch mit QAM-Modulationen unter ac noch auftreten.


    Überlappende Kanäle:

    https://de.wikipedia.org/wiki/Wireless_Local_Area_Network empfiehlt für 802.11b 1,6,11, hingegen für 802.11g und 802.11n 1,5,9 und 13.

    (bei b sind aufgrund DSSS 11 MHz Flanke von der Mittenfrequenz anzunehmen sohin 22 MHz Mindestabstand zu den Kanälen, während g mit OFDM „steilere“ und klar abgegrenze Flanken zeigen. Bei n mit 40MHz wird zeitweise nur die Verwendung von 3+ und 11- empfohlen, für ac weiß ich das nicht - bei 80MHz weiss das Gerät es am besten...). Ich tendiere mittlerweile dazu, auf automatische Kanalwahl zu stellen, da der Router so auf Störungen im Sendebereich schneller mit Kanalwechsel reagieren kann, als der Client den AP wechselt. Und Störungen können von der Mikrowelle über das Babyphon, die analoge VÜ bishin zu kaputten WLAN-Geräten reichen.


    Gegen zahlreiche verworfene Frames hilft nur die Absicherung der Übertragung zumindest durch CTS-to-self oder RTS/CTS. Übermäßige Verwendung von RTS/CTS ist aber auch nachteilig - Stichwort: RTS-Flooding.


    Das Ruckeln von Kodi am FireTV-Stick kann unterschiedliche Ursachen haben: Erstens die Wlan-Qualität, zweitens das Audio-Decoding (Audio Passthrough einstellen für IPTV Simple), drittens das Decoding und Buffering - weiss nicht mehr ... durchprobieren, viertens Empfangsstörungen der Sat-Anlage (wenn es denn SAT>IP wäre) auf den HD-Sendern.


    Also zusammenfassend: Packet Aggregation aktivieren, RTS/CTS mit hoher Schwelle 2344 oder 2345 einstellen, Kanalwechsel automatisieren, APs beträchtlich weiter als drei Meter auseinanderstellen, Sendeleistung eher reduzieren als voll aufdrehen (Faustregel 2dB mehr als gerade noch gut geht). Tip: APs niemals auf Metallregale stellen.

  • MTU Probleme im Netcup-internen Netz? Halte ich für sehr unwahrscheinlich.

    Im ICMPv6 sind einige Message-Types freigeschaltet. Vorher gab es in die Richtung ja eher keine Probleme.

    Unwahrscheinlich ja, aber vollkommen unmöglich wird es wohl nirgendwo sein. Die Troubles mit pMTUd treten aber meiner Erfahrung nach eher auf den Internetleitungen wo DSL, UMTS und LTE und Co im Spiel sind (PPP*+VLAN einerseits, Tunneling beim Carrier andererseits, einhergehend mit Fragmentierung auf dieser Ebene.). Man sieht beizeiten so einiges...


    Wie schaut es mit der Erreichbarkeit über die linklokalen Adressen aus? Wenn dabei kein Paketverlust auftritt, wäre das die Differentialdiagnose, die bestätigt, dass intern soweit einmal Einiges richtig läuft, wenn die Host in derselben Broad- respektive der richtigen MC-Domain liegen.


    BTW - eventuell ähnliche Meldung vor zwei Stunden https://forum.netcup.de/netcup…routing-kaputt/#post93151

  • Bevor ich deswegen den Support kontaktiere wollte ich kurz hier mal nach Bestätigung fragen:

    Ist mir jetzt mit mehreren Domains passiert: der DNSSEC Haken verschwindet nach dem Speichern


    Reproduzieren:

    1. Bei einer Domain im CCP mit DNSSEC auf Speichern klicken (DNSSEC Haken bleibt erstmal korrekt gesetzt)
    2. 1-2 Minuten warten
    3. DNS Einstellung der Domain neu laden => Haken für DNSSEC weg

    Es dauert auch ca. >15 Minuten bis die Einstellungen auf yes springen.

  • Ich habe mal ne Frage zur Bash, da ich absolut keine Ahnung hab, wie man das ohne großen Aufwand umsetzen könnte oder wie man das ganze ergoogeln könnte.


    Gibt ja n normalen Zähler, wo man einmalig i=1  setzt und dann immer mit i=$i+1 erhöht. Gibt es da eine Möglichkeit, immer 4 Stellen mit Nullen aufzufüllen, also statt 1 -> 0001 oder 123 -> 0123. Mir fällt da nichts praktikables ein.


    EDIT: Man könnte die Stellen von i abfragen, nur wie geht das? (Manuell Nullen setzen lassen ginge, sind ja nur 3,4 Stück und keine 100000)

  • Entsprechende Einstellungen für PA, RTS/CTS finde ich nirgendwo. Auch sind drei Meter Abstand etwas untertrieben. Ich habe mal versucht eine Skizze anzufertigen. Meine Zeichenkünste haben dabei sehr geholfen ;)

    Der Abstand der APs liegt bei rund 30 Metern im Keller und 8m zum Dachboden (sehr grob geschätzt).

    Auch habe ich die Leistung mittlerweile möglichst niedrig gestellt.


    Ich werde das Ergebnis mal ein paar Tage beobachten. Danke schonmal :)


    lg.

  • @03simon10 Mit Nullen auffüllen, da ist printf Dein Freund! ;)


    z.B. mit %04d als Format.


    Und für den Rest such mal nach "bash increment" im Internet.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Windows ist doch echt für'n Arsch. In Ordner A haben alle Dateien das Änderungsdatum X, verschieb ich alles in Ordner B, so haben die Dateien Änderungsdatum Y. Verschiebt man das ganze zurück, so ist's in Ordner A wieder Änderungsdatum X.

    Ich krieg's Kotzen

  • Windows ist doch echt für'n Arsch. In Ordner A haben alle Dateien das Änderungsdatum X, verschieb ich alles in Ordner B, so haben die Dateien Änderungsdatum Y. Verschiebt man das ganze zurück, so ist's in Ordner A wieder Änderungsdatum X.

    Ich krieg's Kotzen

    Bei mir unter Windows 10 bleibt das Änderungsdatum beim Verschieben erhalten. Aber ja: Windows ist für'n Arsch.

    Meine Minecraft-Plugins auf SpigotMC (Open Source): www.spigotmc.org/members/mfnalex.175238/#resources

    Discord: discord.jeff-media.com

  • Danach war's komischerweise nicht mehr - davor aber... Nach ~ 6000 teilweise falsch benannten Dateien kriegt man da echt's Kotzen.


    20XX-08-03_1105-jpg - oh was könnte das wohl sein, ein Weihnachtsbaum, jawoll