Beiträge von KaNo

Zitat von pufferueberlauf

sieht erst mal OK aus, bis auf die Latenzspikes... interessanter Weise tauchen die beim eigentlich haertesten Teil, dem Bidirectionalen Test gar nicht auf. Ist das immer so, oder verteilen die sich eher zufaellig uber die Lastphasen?

Ich weiß auch nicht, wie man das wirklich richtig einordnen soll. Die Ergebnisse sind extrem variable auf allen Seiten oder Tools, die einen möglichen Bufferbloat überprüfen, wie zum Beispiel CloudFlare, Waveform und/oder iperf3. Von A+ bis hin zu D war schon alles dabei, wobei A+ bei loaded Download eher selten vorkommt. Es ist auch egal, zu welcher Tageszeit ich den Test starte. Einzig iperf3 lässt mich in Sachen schlechter Download-Tests mit vielen Sender Retries "nie im Stich". Die naheliegendste Erklärung, die ich mal glaubte gefunden zu haben, ist folgende:

Zitat

fq_codel kann auf ingress nicht direkt (ohne Hilfs-Device) verwendet werden.

Das liegt an der Architektur des Linux-Kernels: fq_codel ist ein klassendiszipliniertes Warteschlangenverfahren (Qdisc), das darauf ausgelegt ist, Pakete in einer Warteschlange zu halten und diese verzögert auszuspielen (Shaping/Scheduling). Auf dem ingress-Hook gibt es jedoch standardmäßig keine echte Warteschlange; Pakete werden dort entweder sofort verarbeitet, verworfen (policing) oder weitergeleitet.

Um fq_codel (oder ein anderes komplexes Qdisc wie cake oder fq) auf eingehenden Traffic anzuwenden, müssen Sie den Datenverkehr über ein virtuelles IFB-Device (Intermediate Functional Block) umleiten.

Anbei mal exemplarisch den letzten iperf3-Test bzgl. Up- und Download von meinem Gaming-System:

_iperf3-result-ipv6-20260829-4690-upload.txt

_iperf3-result-ipv6-20260829-4690-download.txt

Inwieweit das Verhalten mit einem eventuell "fehlerhaft konfigurierten“ AON-ONT zusammenhängt, kann ich leider nicht beurteilen. Denn wenn man schon überall mitbekommt, wie sehr man sich seitens des Kunden an dem First-Level-Supports der verschiedenen ISP-Provider bei vermeintlich einfach zu lösenden Probleme die Zähne ausbeißt, wollte ich dieses Fass erst gar nicht aufmachen.

DG 300/150 (Inside FritzBox 4690 270/135) MBit/s

My loaded Downloads were always a PITA

Zitat von JohnStorm

Hi KaNo,

bin über Deinen Beitrag gestolpert, da ich das gleich Setting und Problem (DL geht bei Steam, EPIC, EA innerhalb von Sekunden auf 0) gehabt habe. Ich dachte ebenfalls ich werde wahnsinnig oder klatsche das Ding an die Wand 🤣

Speedtest, Youtube etc. lief problemlos.

Was mir soeben half:

1. Priorisierung deaktivieren: Internet-->Filter-->Priorisierung stand auf deaktiviert, hier habe ich auf Auto gestellt. Das half eine sehr kleine, stabile DL zu bekommen (30Mbps)
2. Deaktivierung von IPv6: Internet-->Zugangsdaten-->IPv6 deaktivieren, stand auf aktiviert.

Seitdem rennt der EPIC DL konstant mit max 😀

Ich hoffe es hilft Dir - einzig für Dich habe ich mich gerade angemeldet - um aus Dankbarkeit zu helfen

Alles anzeigen

Hi John,

erst mal danke für dein Feedback und sorry für die späte Rückmeldung.

Auf der einen Seite freut es mich, dass deine Anpassungen im FritzOS deine Probleme lösen konnten. Diese würde auf meiner Seite jedoch mehr Unruhe als alles andere stiften.

Auf der einen Seite betrifft es überwiegend Downloads seitens des ÖRR CDN, der nachwievor nur via IPv4 angesprochen werden kann, auf der anderen Seite betreibe ich einen Proxy, der nur via IPv6 funktioniert, da ich seitens DG IPv4 und IPoE hinter einem CG-NAT hänge.

Guckst du:

# IPv4
C:\Windows\system32>curl.exe -v -o nul https://arteptweb-a.akamaihd.net/am/ptweb/127000/127400/127469-008-A_SQ_0_VOA_11425053_MP4-2200_AMM-PTWEB-80963092414100_tMVKA.mp4
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Host arteptweb-a.akamaihd.net:443 was resolved.
* IPv6: (none)
* IPv4: 185.22.140.18, 185.22.140.10
*   Trying 185.22.140.18:443...
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* ALPN: server accepted http/1.1
* Connected to arteptweb-a.akamaihd.net (185.22.140.18) port 443
* using HTTP/1.x
> GET /am/ptweb/127000/127400/127469-008-A_SQ_0_VOA_11425053_MP4-2200_AMM-PTWEB-80963092414100_tMVKA.mp4 HTTP/1.1
> Host: arteptweb-a.akamaihd.net
> User-Agent: curl/8.13.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Type: video/mp4
< Server: AkamaiNetStorage
< Last-Modified: Tue, 18 Aug 2026 04:21:37 GMT
< ETag: "1b9b057856b060ad35a36c4f27968701:1787026884.356583"
< Content-Length: 451885356
< Date: Mon, 05 Oct 2026 14:08:41 GMT
< Connection: keep-alive
< Access-Control-Max-Age: 86400
< Access-Control-Allow-Headers: *
< Access-Control-Allow-Methods: GET, HEAD, OPTIONS
< Access-Control-Allow-Origin: *
< Vary: Origin, Access-Control-Request-Headers
< X-EINBLIQIO-CDN-EDGE-IP: 185.22.140.18
< Access-Control-Max-Age: 86400
< Access-Control-Allow-Credentials: true
< Access-Control-Expose-Headers: Server,range,hdntl,hdnts,Akamai-Mon-Iucid-Ing,Akamai-Mon-Iucid-Del,Akamai-Request-BC,X-EINBLIQIO-CDN-EDGE-IP
< Access-Control-Allow-Headers: origin,range,hdntl,hdnts,CMCD-Request,CMCD-Object,CMCD-Status,CMCD-Session
< Access-Control-Allow-Methods: GET,POST,OPTIONS
<
{ [15500 bytes data]
100  430M  100  430M    0     0  22.9M      0  0:00:18  0:00:18 --:--:-- 24.6M
* Connection #0 to host arteptweb-a.akamaihd.net left intact

# IPv6
C:\Windows\system32>curl.exe -6 -v -o nul https://arteptweb-a.akamaihd.net/am/ptweb/127000/127400/127469-008-A_SQ_0_VOA_11425053_MP4-2200_AMM-PTWEB-80963092414100_tMVKA.mp4
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Could not resolve host: arteptweb-a.akamaihd.net
* shutting down connection #0
curl: (6) Could not resolve host: arteptweb-a.akamaihd.net

Aktuell würde ich meinen Vorrednern da eher zustimmen wollen.

Wenn der Download mal wieder ins stocken gerät, oder gar mit 0 MBit/s hängen bleibt, und ich gleich darauf einen Download seitens z.B. https://releases.ubuntu.com/26.04/ubuntu-2…sktop-amd64.iso starte, läuft der Download im Single-Stream mit der vollen zugesicherten Bandbreite (+/- 1-3 MBit/s) in einem Guss durch.

Auch das rumspielen mit den Priorisierungsoptionen im FritzOS 8.25 für das Heimnetz brachte bei mir keinerlei Besserung.

Meine 4690 läuft jetzt seit knapp 40 Tagen ohne Probleme, mit stabilen Temps, CPU-Last und RAM-Auslastungen.

Nachwievor gilt in meinem Fall, dass ich wohl mehrere Entwicklungen über die Jahre hinweg verpennt habe, und mir diese erst beim Tausch meines Routers aufgefallen sind, da man dann „genauer“ hinschaut.

Ob es in 2026 noch sinnvoll erscheint IPv6 im Dual-Stack zu deaktivieren, muss jeder für sich selbst entscheiden. Natürlich spielen hier auch technische Überlegungen am jeweiligen Anschluss mit eine Rolle.

Zu deiner Randinfo: Da Wilhelm-Tel nach kurzer Recherche wohl bei allen möglichen Einwahlverfahren auf PPPoE setzt und im Dual-Stack-Betrieb auf DS-Lite, kann man auch hier keinen direkten Vergleich mit meinem Anschluss seitens DG auf Basis IPoE im Dual-Stack an einem ONT ziehen.

Ich drücke dir dennoch die Daumen, dass das FritzOS 8.50 ggf. dann endlich auch bei dir grundlegend Abhilfe für dein Problem schafft.

Zitat von Funker

Wenn es wirklich nur um den Fall AON-Ethernet IP/DHCP geht, kann man auch Router mit vorinstalliertem OpenWrt plus GUI kaufen, z. B. von gl-iNet. Da brauchst du dann gar nicht in die Tiefen der Konfigurationssprache absteigen, kannst es aber bei Bedarf.

Die Eingabemaske für die MAC-Adresse ist ja ein global übliches Standardfeature, das man überall findet.

Das wäre jetzt nicht so das Problem.

OpenWrt 25.12.5 x86-64 Bare Metal:

/etc/config/network (ACHTUNG: LAB-ONLY-SYSTEM NO RA DHCP v4 v6)

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	list ipaddr '127.0.0.1/8'

config globals 'globals'
	option packet_steering '1'
	option dhcp_default_duid ''

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan0'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option multipath 'off'
	list ipaddr '192.168.178.254/24'
	option gateway '192.168.178.1'
	list ip6addr 'fdab::x:y/64'
	list ip6addr 'fe80::x:y/64'
	option ip6assign '64'
	list dns '192.168.x.y'
	list dns '192.168.x.y'
	list dns 'fe80::x:y'
	list dns 'fe80::x:y'

config device
	option name 'wan0-xyz'
	option macaddr '08:96:d7:xx:yy:zz'

config interface 'wan'
	option device 'wan0-xyz'
	option proto 'dhcp'
	option multipath 'off'
	option clientid 'ffd7xxyyzz00030001-xyz'
	option hostname 'fritz.box'
	option vendorid 'AVM DHCPC v9.04.395'
	option defaultreqopts '0'
	option reqopts '1 3 6 15 26 42 120 121 158 212 249'
	option peerdns '0'
	list dns '192.168.x.y'
	list dns '192.168.x.y'

config interface 'wan6'
	option device 'wan0-xyz'
	option proto 'dhcpv6'
	option multipath 'off'
	option clientid '00030001-xyz'
	option reqaddress 'try'
	option reqprefix '::/56:-xyz'
	option norelease '1'
	option noclientfqdn '1'
	option defaultreqopts '0'
	option reqopts '3,17,23,25,31,56,83,86'
	option sendopts '16:00000368A'
	option ip6ifaceid '::-xyz'
	option peerdns '0'
	list dns 'fe80::x:y'
	list dns 'fe80::x:y'

Mein "Problem mit OpenWrt & Co" ist der reibungslose Betrieb am ISP-Anschluss (in meinem Fall IPoE OHNE VLAN seitens PtP AON) hinsichtlich

IPv6 PD inkl. IA_NA + IA_PD + IAID

im Allgemeinen, als auch über owut upgrade hinweg, zzgl. des reibungslosen Austauschs der jeweiligen Geräte, ohne dass man 1+ Stunde Wartezeit in Kauf nehmen muss, damit man wieder einen vollständigen Dual-Stack-Betrieb vorweisen kann.

GL.iNet, CWWK, Topton, NanoPi & Co sind nicht so mein Fall.

Zitat von silo81

Hallo zusammen.

Hab die Erfahrung machen müssen, daß erst nach dem vollständigen Recovern der Box mit nochmals anschließenden Werksreset die Box erst sauber war.

Bei der Einrichtung unbedingt den Assistenten abschließen und nicht abbrechen. Sonst spinnt die ganze Box.

Danach haben bei mir die Boxen keine Zicken mehr gemacht.

Interessanter Ansatz.

Und ja, Assistenten könnten durchaus ein Teil des Problems sein.

Deswegen meide ich selbige in der Regel, wie der Beelzebub das Weihwasser (bitte nicht so ernst nehmen, wie es klingen mag).

Auch das Einspielen von Konfigurations-Backups unterlasse ich in der Regel. Andere Baustelle gleiches Prinzip wie zuvor.

Zitat von ::1

Der Zack-Test von AVM ist zwar schon besser geworden (bisher hat er eher Mondergebnisse angezeigt) - ich mache lieber mehrere Tests mit einer repräsentativen Auswahl bewährter Tools (nPerf, Ookla, Breibandmessung, ...), die dann auch etwa gleiche Ergebnisse liefern.

Den Zack-Test habe ich nur gemacht, falls der Fritz-Support (ehemals AVM) hier mitlesen sollte.

In der Regel benutze ich (auch) die Tests seitens Waveform, Cloudflare und iperf3 im download/upload Modus.

Zitat von ::1

Guess what: Ich arbeitete einfach mit dem FB-Standard-Profil "Deutsche Glasfaser"...

Wenn ich das FB-Standard-Profil "Deutsche Glasfaser" benutze, kann ich leider nicht die entsprechende MAC-Adresse in den Zugangsdaten vergeben. Deswegen muss ich den Internet-Zugang via „Anderer Internetanbieter“ einrichten.

Zitat von frank_m

Ich bin mir nicht sicher, ob Mediatheken gute Server für Speedtests sind. Eine Mediathek geht davon aus, dass ein Nutzer in etwa mit der Bandbreite des Videos streamt - vielleicht immer mal in schnelleren Chunks, aber im Mittel passt das. Ich könnte mir durchaus vorstellen, dass es da eine Bandbreitenbegrenzung pro Verbindung gibt.

Sorry, dass ich mich erst jetzt zurückmelde, aber ich wollte nicht schon wieder in den eigenen Bestätigungsfehler hineinlaufen.

Grundlegend würde ich dir nicht widersprechen wollen. Insbesondere, wenn man Tools wie yt-dlp in Kombination mit anderen Mediatheken benutzt, hast du natürlich recht.

Leider sind einige Entwicklungen der letzten Jahre an mir vorbeigegangen:

• ÖRR CDN und Streaming OS (neues Rate-Limiting, Kontingente oder beides?)
• Deutsche Glasfaser wendet Insolvenz endgültig ab
• Deutsche Glasfaser - Umstellung AON zu GPON/XGS-PON

Ich habe dann nochmals die Boxen gegeneiander getauscht, und eine etwas standardisiertere Testmethodik benutzt. Und siehe da, das gleiche Verhalten war nun ebenfalls zu beobachten, wenn die 7490 am ONT hing. Ich wäre demnach auf kurz oder lang mit der 7490 mit einer vergleichbaren Fragestellung konfrontiert worden.

Schlussendlich habe ich mich dann doch dazu entschieden die 4690 zu behalten. Ob diese allerdings, vergleichbar mit der 7490, für 12+ Jahre bei mir als Router am ISP-Anschluss laufen wird können, kann nur die Zukunft zeigen.

Danke nochmal an alle, die mir ihre Unterstützung angeboten haben, und/oder mich durch entsprechende Korrekturen nebst Hinweise in die richtige Richtung verwiesen haben.

Gruß KaNo

Kann ich gerne auch da nochmal tun.

Anbei schon mal zwei Messungen, welche ich direkt nach der Erstverbindung nach dem Reset gemacht habe:

20260824 - FritzBox 4690 - WAN-Port mit ONT P2410 LAN1-Port verbunden 36 - Waveform.txt

Muss jetzt erst mal ne Runde um den Block, bis später...

Zitat von ::1

Ist LAN1 im Powermode?

After Reset: In Power Mode

Before Reset: In Power Mode

"Ich will nicht mehr, ich kann nicht mehr, ich halte das alles..." - Sebastian Kurz -

Wie versprochen, habe ich nur den Interzugang eingerichtet, sonst nichts!

ONT P2410 LAN1 > FritzBox 4690 WAN > FritzBox 4690 LAN1 > PC

HubeBube

Copy.

Dann trenne ich jetzt (gleich) die Verbindung via Patchkabel (CAT6e) zwischen der FritzBox und dem ONT, belasse den ONT dabei am Netzteil (ONT wird NICHT stromlos gemacht), und stelle mir nen Timer auf 65 Minuten.

Währenddessen tausche ich die 7490 wieder mit der 4690 OHNE diese mit dem ONT zu verbinden. Ich lasse den Switch komplett außen vor, und verbinde meinen Hauptrechner direkt mit den LAN1-Port der 4690 (CAT6e), stelle die Werkseinstellungen der 4690 wieder her, und konfiguriere danach lediglich den Internet > Zugangsdaten > Internetzugang a la:

Alles andere lasse ich vollständig unangetastet. Frühestens nach Ablauf der 65 Minuten, verbinde ich den WAN-Port der 4690 mit dem LAN1-Port des ONTs via Patchkabel, und schaue, was passiert...

Zitat von HubeBube

KaNo: es gäbe da noch eine andere mögliche Lösung

1. Setze die 4690 erneut auf Werkseinstellungen zurück.
2. Trenne alle Geräte von dem ONT
3. Warte 65 Minuten
4. Nun verbindest Du die 4690 als einziges Gerät mit dem ONT
5. Konfiguriere die 4690 Manuel, keine Backups einspielen!
6. Führe erneut einen Speedtest durch

Exakt in dieser Reihenfolge vorgehen.

Ich kam nicht umher, die 7490 gestern nochmal mit dem ONT zu verbinden. Würde jetzt aber gerne mit deinem möglichen Lösungsansatz fortfahren wollen. Dazu noch ein paar Fragen, um hoffentlich alle Unklarheiten meinerseits auszuräumen:

zu 2 & 3: Soll der ONT weiterhin unter Strom bleiben, und das für die gesamten 65 Minuten? Oder soll der ONT stromlos gemacht werden, und das für 65 Minuten? Ich nehme an, du beziehst dich hierbei auf die ISP-DHCPvX-Lease-Time von 3600 Sekunden plus 5 Minuten?

zu 1: Möchtest du, dass die 4690 beim Zurücksetzten auf die Werkseinstellungen nur mit meinem Hauptrechner via LAN1 verbunden ist, um also den Switch sozusagen dabei komplett aus dem Spiel zu nehmen? Des Weiteren, soll (muss) die 4690 beim Zurücksetzten auf die Werkseinstellungen mit dem ONT verbunden bleiben (sein)?

Danke schon mal im Voraus für deine Zeit!

F

Wenn ich jetzt die ganze Zeit falsch getestet habe, dann (...) aber warten mer mal den heutigen Tag noch ab.

Erklärt jedoch immer noch nicht das Verhalten in Firefox.

pufferueberlauf : Danke für die Korrektur/Richtigstellung.

Danke für deine Rückmeldung.

Zitat von ::1

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?

Damit wir nicht aneinander vorbeireden:

Das verstehe ich aktuell unter Provisionierung (hat Einfluss auf den Shaper Scheduler der Box fq_codel):

Von Default 300/150 laut Tarif, über jeweils -1% bis runter auf -10% durchgetestet. Aktuell nutze ich -5%.

Das verstehe ich aktuell unter Priorisierung (hat Einfluss auf den Shaper Scheduler der Box fq_codel):

Habe hier sämtliche Optionen durchgespielt.

Auszug aus den Support-Daten der 4690:

WAN QoS: yes
  downstream scheduler: fq_codel
  upstream scheduler: fq_codel

LAN QoS: no

Zitat von ::1

Wozu die Messungen mit gesetztem Rate-Limit 25M (~ 210 MBit/s)?

Um den Shaper Scheduler der Box zu "umgehen" / "nicht zu triggern". Deswegen dasselbe File, einmal ohne und einmal mit "--limit-rate 25M" seitens curl. Es ist/war/ist ein Versuch aus der Not heraus, um das Verhalten der Box ggf. besser einordnen zu können.

Exemplarisch für einen wabernden Download der 4690:

Wenn ich mit der 7490 solche Downloads fahre, zieht diese die Datei runter wie ein Strich a la CR7 beim Freistoß. Fluktuationen der 7490 begrenzen sich auf 1 - 2 MBit/s. Ich dachte mir, es wäre besser CURL mit der Verbose-Option als Referenzwerte hier zu posten, zwecks besserer Einordnungen, nebst Vergleichbarkeit.

Zitat von ::1

Eine Geschwindigkeitsmessung mit den üblichen Tools (Empfehlung: "Breitbandmessung") ist da doch ratsamer, oder?

Ich würde sagen nein, da eine reine Geschwindigkeitgsmessung lediglich eine punktuelle Beschreibung der Situation zum Zeitpunkt der Messung ist, und kein Tagesgeschäft abbildet.

Da ich das CDN der ÖR-Sender schon seit Jahren nutze, kann ich hier das Verhalten im Download (auf all meinen Geräten) recht gut einordnen.

Als Alternative habe ich dann noch das CDN seitens Ubuntu gewählt, um auch hier weiter vergleichen zu können. Ein Recherche seitens Google ergab, dass die CDNs der Linux-Distros in der Regel keine Bandbreitenbeschränkungen aufweisen.

Ich bin gerne bereit ein CDN nach Vorgabe zu nutzen.

Zitat von HubeBube

KaNo: es gäbe da noch eine andere mögliche Lösung

1. Setze die 4690 erneut auf Werkseinstellungen zurück.
2. Trenne alle Geräte von dem ONT
3. Warte 65 Minuten
4. Nun verbindest Du die 4690 als einziges Gerät mit dem ONT
5. Konfiguriere die 4690 Manuel, keine Backups einspielen!
6. Führe erneut einen Speedtest durch

Exakt in dieser Reihenfolge vorgehen.

Copy.

Werde ich dann am Wochenende so durchspielen, und ggf. das auch so noch mal mit der letzten Labor-Firmware. Dass aber auch nur, damit man mir zu guter Letzt (seitens des Fritz-Support) nicht vorwerfen kann, ich hätte nicht alles versuchen wollen.

Zitat von ::1

Moin, nur um die Zahl möglicher Fehlerquellen auf ein Minimum zu reduzieren, schlage ich testweise folgendes Minimal-Setup vor:

• In der 4690 WLAN abschalten.
• Den Zyxel von der 4690 abklemmen.
• Nur einen Test-PC direkt an einen LAN-Port der 4690 anklemmen. Am Test-PC, falls vorhanden, WLAN-Adapter deaktivieren.

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

20260820 - FritzBox 4690 - Windows curl Tests 2 - PC dirket am LAN1 Port der Box ohne Switch folgen:

Zitat von Sandalenmacher

Zieh doch einfach mal das aktuelle Labor 8.40 drauf.

Was soll schon passieren? Entweder es läuft oder du gehst zurück zu 8.25.

Als im September die 4690 angekündigt wurde, dachte ich mir: Geilo. Genau das was ich suche.

Nach der Markteinführung im März 2025 kam dann auch gleich schon der erste Dämpfer.

Probleme mit der Box am ONT en masse, obwohl diese genau für diesen Anwendungsfall entwickelt wurde. Da WLAN bei mir keinen allzu großen Stellenwert hat, waren die WALN-Probleme eher sekundärer Natur für mich.

Ich habe dann hin und wieder mal nachgeschaut, was das FritzOS bzgl. der neuen Boxen so über die Zeit hinweg ggf. doch alles so korrigiert. Nicht wirklich viel. Das war dann der zweite Dämpfer.

Anfang Mai 2026 habe ich damit angefangen, mich nach Alternativen umzuschauen: OpenWrt auf Bare Metal x86-64 > MikroTik RB5009 > ein Rolling Release auf Basis systemd-networkd und firewalld.

Zunächst war ich in Bezug zu den Möglichkeiten der oben genannten im Vergleich zu einer „Fritz(Black)Box“ total gehyped. Schlussendlich fielen doch alle immer wieder irgendwie negativ auf, sobald Dual-Stack (IPv4 und IPv6 im Verbund) in welcher Form auch immer beim ISP-Anschluss eine Rolle spielt.

Mit FritzOS 8.25 sollten ja dann (angeblich) sämtliche Probleme dahingehend gefixt worden sein. Und da jeder ISP-Anschluss durchaus seine individuellen Macken haben kann, und ich wirklich keine Lust (mehr) auf einen Nebenjob als Every-Day-A-Little-Surprise-As-An-Enduring-Home-Lab-IT-Admin hatte (ich bin/werde zu alt für diesen Scheixx), dachte ich mir: Komm, gib der 4690 ne Chance.

Der Rest ist Geschichte.

Wenn man sich für eine Alternative zur FritzBox entscheidet, weiß man nach geraumer Zeit, worauf man sich einlässt. Da gibt es zunächst erst mal kein Fire-And-Forget, oder auch mitunter (extrem) steile Lernkurve genannt.

Das ist auch der Grund, warum ich kein Freund (mehr) von Fritz-Labor bin.

In den letzten Jahren hat die Anzahl der Bananen-Produkte (reifen beim Kunden), auch bei den renommierten Herstellern, immer mehr an Fahrt aufgenommen.

Die 4690 ist ja nun jetzt wirklich nicht mehr taufrisch. Dass man sich mit der Box aber immer noch ein Ü-Ei ins Haus holt, wäre ja auch noch zu verschmerzen, wenn der Fritz-Support wenigsten mitspielen würde.

Wenn aber nach fünf bis sechsmaligem Kontaktversuch, das einzige was kommt eine „Wie fanden sie unseren Support zur ihrer Anfrage“ E-Mail ist, hat man wirklich kaum noch Lust den Beta-Tester zu spielen.

Bitte nicht falsch verstehen Sandalenmacher, dass ist absolut KEIN rant in deine Richtung!

FYI: Heute wurde die fritzbox-4690-labor-8.40-135705 angekündigt.

Zitat von HubeBube

Wie hast Du die WAN MAC Adresse der 7490 ermittelt?

Wie hast Du die WAN MAC der 7490 in die 4690 eingegeben?

# 7490

Sowohl über das WebUI der 7490 via Internet > Zugangsdaten > Internetzugang

als auch via

FritzBox-Support > Paketmitschnitt (if-vcc0 und if-eth0/LAN1=WAN): icmp6 or port 547 or port 67

# 4690

Über das WebUI der 4690 via Internet > Zugangsdaten > Internetzugang > Anderer Internetanbieter.

Alle anderen Optionen lassen es nicht zu, eine MAC-Adresse zu hinterlegen. Aber hier kann ich mich auch irren !!!

Nur der Vollständigkeit halber nochmal zur Ersteinrichtung:

Image von hier heruntergeladen.

SHA256 FRITZ.Box_4690-08.25.image: 3f4f14ec924d29bb3820e35efd8fc074468727abfbe60cdb48b93bc273886ec8

Einen Zweitrechner über einem LGS105-EU mit der 4690 verbunden. Es bestand zu keiner Zeit eine Verbindung zum restlichen LAN.

Via System > Update > FritzOS-Datei die Box geupdatet

Nach Neustart der Box nochmals auf Werkseinstellungen zurückgesetzt.

Am LGS105-EU zunächst nur eine Grundkonfiguration vorgenommen.

Dann die 7490 ausgeschaltet, abgeklemmt, die 4690 angeklemmt, und dann erst das Netzteil an die 4690 angesteckt.