Immerhin ein Fortschritt - und eine Sorge weniger.
Beiträge von ::1
-
-
Aber ich bearbeite Beiträge auch aus anderen Gründen nachträglich (auch längere Zeit später, tw. sogar Jahre, ist zumindest schon vorgekommen), z.B. aufgrund neuer Erkenntnisse bzw. um falsche Aussagen zu korrigieren, damit das nicht weiter falsch dasteht. Allerdings gehört es dabei m.E. auch zum guten Ton, dass man das nicht versucht zu "verheimlichen", falsche Textabschnitte lösche ich daher nicht sondern streiche die nur durch (mittels BBCode
…), sodass man die Änderungen nachvollziehen kann (auch wenn die Forensoftware es nicht erlaubt ältere Versionen von Beiträgen anzuzeigen) und weiße ggf. auch auf die Änderungen hin (und mitunter auch die Gründe bzw. Quelle der neuen Erkenntnisse). Bei bestimmten Beiträgen mit häufigeren Änderungen habe ich unten dann sogar eine Art "Changelog" angefügt. Daher bin ich auch gegen eine Zeitlimitierung beim editieren.So sollte es sein --> in die Forums-Netiquette aufnehmen?
-
Es ist aber häufig so, dass sich eine allgemeine Nützlichkeit eines eigenen Beitrags im Verlauf eines (fremden) Threads erst später ergibt. Für mich ist jedenfalls die Schwelle, einen Thread in der Absicht zu erstellen, der Welt irgendeine Weisheit permanent verkaufen zu wollen, sehr hoch.
So etwas könnte allenfalls ein zweiter Schritt sein, indem man einen "Nachschlage"-Bereich etabliert, in dem ein Autor eines solchen Beitrags (nach erwiesener Nützlichkeit für die Forums-Leserschaft) eine Kopie des letzten Standes erstellt, die er fortwährend weiterpflegen/aktualisieren kann.
Der Bereich "Blog" wäre dafür doch ggf. geeignet - der ist aber völlig ungenutzt.
-
Na, dann bin ich ja froh, wenn meine Beiträge nützlich sein können.
Vielleicht hilft es im Sinne der Selbsterkenntnis, wenn man in seinem Personenprofil erfahren könnte, durch wie viele Nutzer man ignoriert wird - der selbst-reflektierende Beitragende könnte dann daraus seine Schlüsse ziehen.
Grundsätzlich würde ich im Sinne der Ausgangsfragestellung zustimmen, das Editieren der eigenen Beiträge nach einem bestimmten Zeitfenster zu blockieren. Ich habe allerdings einen Beitrag, den ich hin und wieder um Informationen ergänze und in anderen Threads referenziere. Ersteres wäre dann natürlich nicht mehr möglich.
-
-
-
Tests als Referenz zu deinem Vorschlag:
20260820 - FritzBox 4690 - Windows curl Tests 1 - PC via Switch:
20260820 - FritzBox 4690 - Windows curl Tests 1 - PC via Switch.txt
Also, etwas Erläuterung wäre vielleicht nicht schlecht ...

Aber ich habe mir mal die Mühe gemacht, die Essenz deines Test1 hier herauszuschreiben - und den "Average Dload" von "k" (Multiplikation des Wertes mit 8*2^10/10^6) bzw. "M" (Multiplikation mit 8*2^20/10^6) einheitlich in MBit/s (diese Einheit weggelassen) umzurechnen:
Code
Alles anzeigen# 300/150 | ONT LAN1 > 4690 WAN > GS1200-8 Port 3 > GS1200-8 Port 2 > PC % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 4 6216M 4 253M 0 0 48,4 0 0:17:57 0:00:43 0:17:14 6913k <-- FILE1 2 6216M 2 153M 0 0 72,2 0 0:12:02 0:00:17 0:11:45 10.9M <-- FILE1 mit rate limit 25M 100 3145M 100 3145M 0 0 98,1 0 0:04:27 0:04:27 --:--:-- 10.9M <-- FILE2 100 3145M 100 3145M 0 0 80,0 0 0:05:33 0:05:33 --:--:-- 12.0M <-- FILE2 mit rate limit 25M # 288/144 | ONT LAN1 > 4690 WAN > GS1200-8 Port 3 > GS1200-8 Port 2 > PC % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 6216M 100 6216M 0 0 291,1 0 0:02:59 0:02:59 --:--:-- 35.7M <-- FILE1 14 6216M 14 882M 0 0 61,6 0 0:14:06 0:02:00 0:12:06 8118k <-- FILE1 mit rate limit 25M 71 3145M 71 2236M 0 0 125,0 0 0:03:31 0:02:30 0:01:01 6524k <-- FILE2 38 3145M 38 1226M 0 0 82,2 0 0:05:20 0:02:04 0:03:16 13.9M <-- FILE2 mit rate limit 25MJetzt frage ich mich allerdings:
- Wozu die Messungen mit gesetztem Rate-Limit 25M (~ 210 MBit/s)?
- Was ist der Unterschied zwischen 300/100 für die ersten 4 Downloads und 288/144 für die zweiten - sind das verschiedene in der Fritzbox gesetzte Download/Upload-Raten?
Und schließlich habe ich so meine Zweifel, ob Download-Messungen von irgendwelchen Servern ideal für Geschwindigkeitsmessungen des eigenen Anschlusses sind - schließlich kann der Download-Server am anderen Ende auch eine Bremse sein.
Eine Geschwindigkeitsmessung mit den üblichen Tools (Empfehlung: "Breitbandmessung") ist da doch ratsamer, oder?
-
Da hat dein LLM Quatsch gelernt. Der richtige Ansprechpartner ist die Rechtsabteilung und die erreicht man zuverlässig mit einer Anwaltskanzlei im Briefkopf.
Tja, so ein (nicht mein) LLM weiß eben auch nicht immer, was richtig ist. Wie gut, dass du es uns nun so eindringlich mitgeteilt hast.
-
Also sobald man 192.168.101.0/24 bei sich irgendwo verwendet gibt das Probleme. Würde dann im rebind enden,
Ja, würde ich auch so sehen - aber ist wahrlich nicht im Sinne des Erfinders.
Vielleicht verschwindet das auch alles, nachdem DG auf ihrer Seite deinen Anschluss (hoffentlich bald) ordentlich konfiguriert. Nicht funktionierendes IPv6 ist evtl. aussitzbar, und es kann sein, dass sich das nach ein paar Wochen/Monaten von selbst in Luft auflöst (ich denke, DG weiß sehr genau um seine IPv6-Provisionierungsprobleme). Aber Nicht-Erreichbarkeit ihrer IPv4-DNS-Resolver ist nicht akzeptabel - ok, du kannst/musst einstweilen als Workaround andere DNS-Resolver verwenden. Und Nicht-Erreichbarkeit der Login-Seite für das Kundenportal ist auch untragbar (Workaround über anderen Internetzugang).
-
Ich nehme an alles was ich machen kann ist warten? Bringt druck etwas? Oder hat jemand einen Trick wie man irgendwie seinen Anschluss dazu bringen kann in irgendeiner Form neu konfiguriert zu werden?
Ich habe mal eine KI bemüht anlässlich einer anderen Angelegenheit, meinen Anschluss betreffend (Anstieg der Latenz von vormals 8-10 ms auf nun dauerhaft 20-24 ms ab 06.08.2029 01:30 UTC, wunderbar per Datensammlung per RIPE-Atlas-Probe nachweisbar), wie man den sinnlosen 1st-level-Support der DG am besten umgehen könnte (die KI meinte, dass man Support-Tickets, in denen der Kunde Begriffe verwendet, die auf Netzwerk-Expertise hindeuten, sogleich aussortiert und schließt).
Die KI schlug z.B. vor, das Problem in Foren wie diesem hier darzustellen, weil da ggf. Mitarbeiter der DG (inoffiziell) mitlesen und ggf. eine kurzen Weg zum 2nd- oder gar 3rd-Level-Support herstellen könnten - weiß nicht, gibt es hier im Forum jemanden? fiberv6 würde sich für Unterstützung freuen.
Ansonsten schlug die KI noch den Schriftweg vor mit folgendem Entwurf eines Anschreibens:
Hier ist eine rechtlich fundierte und technisch unmissverständliche Vorlage für Ihr Einschreiben. Der Text ist so formuliert, dass er die Scan-Software der Poststelle triggert, um direkt in der Beschwerde- und Netzmanagement-Abteilung zu landen, anstatt im Standard-Kundenservice.
________________________________________
Absender:
[Ihr Vorname Nachname]
[Ihre Straße und Hausnummer]
[Ihre PLZ und Ort]
[Ihre E-Mail-Adresse]
[Ihre Telefonnummer] [1, 2]
Empfänger:
Deutsche Glasfaser Wholesale GmbH
– Abteilungsleitung Netzbetrieb / Core Network Engineering –
– Qualitätsmanagement & Beschwerdeabteilung –
Am Kuhm 31
46325 Borken
[Ihr Wohnort], den [Aktuelles Datum, z. B. 20.08.2026]
Per Einwurfeinschreiben
Formelle Störungsanzeige wegen erheblicher Leistungsminderung (Routing-Fehler am BNG)
Kundennummer: [Ihre Kundennummer]
Vertragsnummer: [Ihre Vertragsnummer, falls zur Hand]
Anschlussadresse: [Straße, PLZ, Ort Ihres Anschlusses]
Sehr geehrte Damen und Herren, [3]
...Und hier kannst/solltest du dich mit aller Fachlichkeit einbringen, um das Problem inklusive Nachweisen zu beschreiben,
-
Aber das wird halt problematisch wenn man 192.168.101.0/24 in LAN verwendet.
Stimme zu, falls ein DHCPv4-Renew per Unicast dahin geschickt würde. Kannst du ja evtl. mal mitschneiden...
-
Ja, habe auch nochmal tatsächlich im RFC2131 nachlesen müssen.
Die DHCP-Antworten kommen vom IPv4-Default-Gateway 100.72.224.1, das dir auch als Option 3 zugewiesen wird - soweit normal (ist bei meinem DG-Anschluss ebenso).
- Aber es ist ein DHCP-Relay im Spiel: giaddr=100.127.140.129.
- Und der Server-Identifier (zugleich auch siaddr) = 192.168.101.1
Habe ich so an meinem Anschluss nicht - aber kann ok sein, da DG an neuen Anschlüssen wie deinem hier evtl. eine geänderte Vorgehensweise hat.
Du bekommst ja schlussendlich auch valide IPv4-Werte zugewiesen, mit denen du prinzipiell arbeiten kannst.
Dass du die DNS-Server (Option 6: 185.22.44.50, 185.22.45.50) damit nicht erreichst, ist natürlich ein Fehler auf der DG-Seite, denn ausgewählte IP-Ziele im Internet kannst du ja erfolgreich pingen.
IPv6: Soweit eigentlich alles mustergültig - nur für IA_NA wieder relativ kurze Timer, während du für IA_PD schon den Stundenwert bekommst. Muss in Folge schon ein Renew für IA_NA nach 5 Minuten erfolgen. Auch die ICMPv6-RA mustergültig.
PINGv6 von der WAN-Adresse funktioniert. Du müsstest halt noch mal mitschneiden, dass ausgehende IPv6-Pings aus deinem LAN nicht beantwortet werden.
Und wie in meinem letzten Post schon angemerkt, ist das IPv6-Renew-Verhalten wackelig.
-
Ähm, aber bitte auch mit IA_NA, wie sich das gehört! Und nicht so plain hier rein posten - das ist ziemlich mühsam zu analysieren. Aber du kannst mir gerne eine PCAP-Datei (oder in anderes Wireshark-lesbares Format) des Mitschnitts per PM schicken, so dass ich das mit Wireshark anschauen kann. Und mir etwas Zeit zum Anschauen lassen.
Ja, icmp, icmp6, dhcpv4, dhcpv6 solle reichen.
-
Ja ist merkwürdig - in einem DHCPv4-Mitschnitt an meinem DG-Anschluss antwortet der DHCPv4-Server mit einer Adresse aus 100.64.0.0/10.
DHCPv6 ist auch merkwürdig:
- die erste Transaktion (xid=a7c41d) ist ein Renew, der mit der negativen Antwort "status-code NoBinding" endet: Der DHCPv6-Server hat schlicht keine Lease für deinen IA_PD
- also startet als zweite Transaktion (xid=eefff2) ein Rebind, die aber ohne Antworten ins Leere läuft (es gibt eben keinen zweiten DHCPv6-Server)
- Schließlich als dritte Transaktion (xid=de8939) ein DHCPv6-Neustart: Solicit - Advertise - Request - Reply - allerdings neues IA_PD mit extrem kurzen pltime=vltime=600 und T1=300 und T2=400.
- Deshalb (T1=300) schon nach 5 Minuten ein Renew (xid=4218a0), in dessen Antwort nun immerhin pltime=vltime=3600 und T1=1800 und T2=2880 gesetzt ist.
Ich denke aber, spätestens nach einer Stunde geht diese etwas kaputte Spiel von vorne los.
-
Hast du noch DHCP-Relay (192.168.101.1) dazwischen?
-
Dein erster Absatz entspricht soweit den bekannten Erfahrungen in anderen Fällen: Das (Rück-)Routing deines IPv6-PD-Blocks funktioniert bei DG nicht.
Die IPv4-Probleme sind aber ungewöhnlich: Ist denn deinem WAN-Port eine IPv4-Adresse aus 100.64.0.0/10 per DHCPv4 zugeordnet worden?
-
Mein Firefox-Browser-Plugin "IPvFoo" sagt mir, dass "Steam" und "GeForce NOW" nur über IPv4 erreichbar sind.
Ich würde daher darauf tippen, dass IPv4 an deinem PC bei Verwendung von Ethernet-LAN nicht funktioniert, IPv6 hingegen schon. Deshalb erreichst du dann nur IPv6-Ziele (z.B. Netflix) im Internet.
Bei Verwendung von WLAN scheinen hingegen beide Protokolle ordnungsgemäß zu arbeiten.
Code
Alles anzeigenC:\>nslookup Standardserver: localhost Address: ::1 > store.steampowered.com. Server: localhost Address: ::1 Nicht autorisierende Antwort: Name: store.steampowered.com Address: 23.52.182.122 > play.geforcenow.com. Server: localhost Address: ::1 Nicht autorisierende Antwort: Name: d37fmfghjt329d.cloudfront.net Addresses: 108.157.4.87 108.157.4.102 108.157.4.126 108.157.4.52 Aliases: play.geforcenow.com > www.netflix.com. Server: localhost Address: ::1 Nicht autorisierende Antwort: Name: www.prod.ftl.netflix.com Addresses: 2a00:86c0:2043::1 2a00:86c0:2042::1 207.45.73.1 207.45.72.1 Aliases: www.netflix.com -
Allerdings habe gestern hyper-v wieder deaktiviert. Das geschilderte problem besteht weiterhin
Dann sollte ein "ipconfig /all" aber etwas anderes als auf deinem letzten Screenshot anzeigen !?
-
Ich will nur ausschließen, dass deine alte 7490 noch im Netz läuft - zwar ohne Uplink zum Internet, aber immer noch LAN-seitig und parallel zur 4690 mit am Zyxel hängt. Das wäre ggf. fatal, wenn beide Router parallel versuchen, das LAN zu bedienen.
Mach also die 7490 wirklich stromlos, wenn die 4690 aktiv ist.
Oder meinst du den Zyxel von LAN1 Port komplett abklemmen, und dort den Hauptrechner aufschalten?
Ja, ich würde wirklich dein ganzes restliches Netz abklemmen und nur den Aufbau ONT <-WAN-> 4690 <-LAN ohne Switch-> PC testen.
-
Du hast an deinem PC offenbar Hyper-V aktiviert - eigentlich macht man das nur, wenn man zusätzlich virtuelle Maschinen auf dem nun zum Hyper-V-Server mutieren PC betreiben will.
Für den physischen Ethernet-Adapter des PC (=HyperV-Host) ergibt sich dann ggf. eine Umkonfiguration dahingehend, dass er nur noch als Ethernet-Bridge ohne gebundene Protokolle wie IPv4/IPv6 arbeitet und einen vSwitch anbindet - auf dem wird dann ein virtuelles (Ersatz-) Interface generiert, das den Hyper-V-Host selbst adressiert - möglicherweise das, was in deinem Screenshot als vEthernet-Adapter angezeigt wird.
Das kann aber auch ein Host-only-Adapter sein, der nicht im Bridging-Modus arbeitet - die Adresse 172.19.112.1/20 könnte ein Hinweis darauf sein, wenn das nicht deinem am Router definierten LAN-Range entspricht ( bei einer Fritzbox typischerweise 192.168.178.0/24).
Andererseits ist es bei mir schon viele Jahre her, dass ich mich mit Hyper-V gut auskannte - bin da heute nicht mehr trittsicher. Ich vermute jedenfalls, dass darauf dein Problem beruht - deshalb: Deaktiviere doch am besten die Hyper-V-Funktion an deinem PC.