YAML Metadata Warning:empty or missing yaml metadata in repo card

Check out the documentation for more information.

RouterMauer – D-Link als WLAN-Access-Point

Stand: 2026-07-15

Status: abgeschlossen und live verifiziert.

Ziel

Die Fritzbox bleibt der einzige Router, Internet-Gateway und DHCP-Server. Der D-Link stellt zusätzliche 2,4-GHz- und 5-GHz-WLANs sowie LAN-Ports bereit und arbeitet nur noch als Access Point/Bridge.

Internet
   |
Fritzbox 192.168.178.1
   |
   +-- LAN ---- LAN D-Link 192.168.178.2
                    |-- 2,4-GHz-WLAN
                    `-- 5-GHz-WLAN

Der WAN-/Internet-Port des D-Link bleibt im Zielzustand frei.

Was jetzt konkret besser ist

  • Kein Doppel-NAT mehr: Nur die Fritzbox routet zwischen Heimnetz und Internet.
  • Kein DHCP-Wettbewerb mehr: Nur die Fritzbox verteilt IP, Gateway und DNS.
  • Alle Geräte liegen im gemeinsamen Netz 192.168.178.0/24; lokale Freigaben, Drucker, Casting und Geräteerkennung funktionieren dadurch zuverlässiger.
  • Der D-Link ist per Gigabit-LAN angebunden. Anders als bei einem reinen WLAN- Repeater wird keine Funkbandbreite für den Uplink verbraucht.
  • Die D-Link-Oberfläche ist aus dem normalen Heimnetz unter https://192.168.178.2 erreichbar.

Nicht verändert wurde die maximale Funkleistung der DIR-1960-Hardware. Echtes FRITZ!Mesh mit gemeinsamem AVM-Steering entsteht ebenfalls nicht.

Geräte

Hauptrouter

  • Gerät: Fritzbox
  • LAN-Adresse/Gateway: 192.168.178.1
  • Netz: 192.168.178.0/24
  • Rolle: Internetzugang, Firewall, NAT, DNS und DHCP

Access Point

  • Gerät: D-Link DIR-1960
  • Hardware: A1
  • Firmware: 1.11
  • Geräte-MAC: C4:E9:0A:41:64:73
  • Zieladresse: 192.168.178.2
  • Zielrolle: WLAN-Access-Point und Ethernet-Switch
  • Verwaltungsoberfläche im Zielzustand: http://192.168.178.2
  • Vollständiges FRITZ!Mesh: nicht unterstützt

Passwörter werden in diesem Projektordner nicht gespeichert.

Live-Ausgangszustand vor der Umstellung

Am 2026-07-15 direkt in der D-Link-Oberfläche verifiziert:

  • D-Link LAN-Adresse: 192.168.0.1
  • D-Link DHCP-Server: aktiviert
  • ThinkPad im D-Link-Netz: 192.168.0.194
  • D-Link WAN-Adresse von der Fritzbox: 192.168.178.42
  • D-Link WAN-Gateway: 192.168.178.1
  • Uplink: Fritzbox-LAN an D-Link-WAN
  • Ergebnis: funktionierender Routerbetrieb mit Doppel-NAT; noch kein Access Point

Zielkonfiguration am D-Link

Unter Settings -> Network:

LAN IP Address:     192.168.178.2
Subnet Mask:        255.255.255.0
DHCP Server Status: Disabled

Danach wird das Fritzbox-Kabel vom D-Link-WAN-Port in einen der D-Link-LAN-Ports 1 bis 4 umgesteckt. Der WAN-Port bleibt anschließend unbenutzt.

Warum DHCP aus sein muss

In einem gemeinsamen LAN darf nur ein DHCP-Server Adressen, Gateway und DNS verteilen. Im Zielnetz übernimmt das die Fritzbox. Bliebe der D-Link-DHCP aktiv, könnten Clients widersprüchliche 192.168.0.x- statt 192.168.178.x-Adressen erhalten und dadurch zeitweise keinen Internetzugang haben.

Abschlussprüfung

  • D-Link LAN-Adresse ist 192.168.178.2
  • D-Link DHCP-Server ist deaktiviert
  • Fritzbox-LAN ist mit D-Link-LAN verbunden
  • D-Link-WAN-Port ist leer
  • WLAN-Client erhält eine Adresse 192.168.178.x
  • WLAN-Client verwendet Gateway 192.168.178.1
  • Internet funktioniert über beide D-Link-WLAN-Bänder
  • http://192.168.178.2 ist aus dem Fritzbox-Netz erreichbar

Verifizierter Endzustand

Am 2026-07-15 nach der Umstellung real geprüft:

  • D-Link-Oberfläche zeigt LAN-IP 192.168.178.2.
  • D-Link-Oberfläche zeigt DHCP Server Status Disabled.
  • ThinkPad wurde nacheinander über 5 GHz (5180 MHz, Kanal 36) und 2,4 GHz (2422 MHz, Kanal 3) mit dem D-Link verbunden.
  • Beide Funkband-Tests erhielten 192.168.178.24/24 von der Fritzbox.
  • Beide Funkband-Tests verwendeten 192.168.178.1 als Gateway und DNS-Server.
  • In beiden Tests waren Internet und https://192.168.178.2 erreichbar.
  • Das nur für die Prüfung angelegte 2,4-GHz-Testprofil wurde wieder gelöscht.
  • Die temporäre ThinkPad-Hilfsadresse 192.168.0.2 wurde wieder entfernt.

Aktuell ist Smart Connect aktiviert: Beide D-Link-Funkbänder verwenden gemeinsam die SSID Fast. Ein getrennt benanntes Slow-WLAN ist für den Access-Point- Betrieb nicht erforderlich und derzeit nicht aktiviert.

Tatsächlicher Umbauverlauf

  1. DIR-1960 identifiziert und aktuelle Routertopologie ausgelesen.
  2. Wegen verlorenem Adminzugang Factory-Reset über den versenkten Reset-Taster ausgelöst; das orange Statuslicht bestätigte den Reset/Neustart.
  3. Neues Admin-Passwort gesetzt; es wird bewusst nicht in diesem Projekt gespeichert.
  4. D-Link-Weboberfläche unter 192.168.0.1 geöffnet und die echten LAN-/DHCP- Felder unter Settings -> Network -> Advanced Settings identifiziert.
  5. Beim Übergang auf LAN-zu-LAN liefen Fritzbox- und D-Link-DHCP kurz parallel. Der ThinkPad erhielt deshalb vorübergehend keine stabile Internetauflösung.
  6. Zur Reparatur erhielt der ThinkPad temporär die Hilfsadresse 192.168.0.2/24, ohne den Fritzbox-Internetweg zu ersetzen.
  7. D-Link-LAN auf 192.168.178.2 geändert und D-Link-DHCP deaktiviert.
  8. Fritzbox-LAN mit D-Link-LAN verbunden; D-Link-WAN bleibt frei.
  9. Temporäre Hilfsadresse und temporäres 2,4-GHz-Testprofil wieder vollständig entfernt.
  10. Beide Funkbänder, Fritzbox-DHCP, Internetzugang und Verwaltungsoberfläche real getestet.

Betrieb und Fehlersuche

Normaler Zugriff:

Verwaltung: https://192.168.178.2
Gateway:    192.168.178.1
Client-IP:  192.168.178.x

Wenn ein Client über den D-Link kein Internet hat:

  1. Prüfen, dass Fritzbox-LAN wirklich in D-Link-LAN 1 bis 4 steckt.
  2. Prüfen, dass der D-Link-WAN-Port leer ist.
  3. WLAN am Client einmal trennen und neu verbinden.
  4. Prüfen, dass der Client 192.168.178.x und Gateway 192.168.178.1 erhält.
  5. D-Link unter https://192.168.178.2 öffnen und bestätigen, dass der DHCP- Server weiterhin deaktiviert ist.

Warum die D-Link-Startseite „Internetverbindung wurde getrennt“ meldet

Diese Meldung ist im aktuellen Access-Point-Aufbau erwartet. Die DIR-1960- Oberfläche läuft weiterhin im Design eines Routers und bewertet nur den Zustand ihres WAN-/Internet-Ports. Dieser Port ist im Zielzustand absichtlich leer.

Der tatsächliche Internetweg der Clients lautet:

Client -> D-Link-WLAN/LAN -> D-Link-LAN-Port -> Fritzbox-LAN -> Internet

Der Datenverkehr berührt den D-Link-WAN-Port nicht. Deshalb können Websites, OpenAI und andere API-Dienste funktionieren, während das D-Link-Diagramm den WAN-Status als getrennt anzeigt. Das ist eine kosmetische Einschränkung der Routeroberfläche, kein Fehler des Access Points.

Nicht das Fritzbox-Kabel zurück in den D-Link-WAN-Port stecken, nur um die Anzeige grün zu machen. Dadurch würden wieder Routerbetrieb und Doppel-NAT entstehen.

Erweiterung um den Mi Router

Am 2026-07-15 wurde hinter dem D-Link zusätzlich ein Xiaomi Mi Router 4C (MiWiFi-R4CM) angeschlossen. Sein WLAN heißt Swigity Swooty.

Live sichtbarer Zustand:

Internet
   |
Fritzbox 192.168.178.1
   |
D-Link 192.168.178.2
   |
Mi Router 192.168.178.27
   |
Android-Client 192.168.178.20

Dass der Android-Client eine Adresse im Fritzbox-Netz 192.168.178.0/24 erhält, zeigt: Der Mi Router arbeitet bereits transparent als kabelgebundener Repeater/Access Point. Wäre er noch ein eigener Router, läge der Client typischerweise in seinem separaten Netz 192.168.31.0/24.

Der frühere Standardzugriff 192.168.31.1 passt deshalb nicht mehr zum aktuellen Modus. Der Mi Router ist im Fritzbox-Netz unter 192.168.178.27 sichtbar; ein Browserzugriff wurde bisher mit 403 Forbidden beantwortet.

Der Internetzugang über Swigity Swooty ist noch nicht abgeschlossen verifiziert: Websites benötigen teilweise etwa eine Minute, ein Speedtest schlägt fehl. Gleichzeitig wurden im gemeinsamen LAN zwei IPv6-Standardrouter beobachtet:

  • Fritzbox: fe80::4a5d:35ff:fecf:491d
  • D-Link: fe80::c6e9:aff:fe41:6473

Der D-Link-WAN-Port ist leer, dennoch sendet der D-Link weiterhin IPv6-Router-Advertisements. Ein dadurch gewählter D-Link-IPv6-Pfad wäre eine Sackgasse und passt zum beobachteten Timeout mit anschließendem IPv4-Fallback. Das ist eine konkrete, aber am Android-Client noch zu bestätigende Fehlerhypothese — kein bereits abgeschlossener Befund.

Status dieser Erweiterung: ACTIVE. D-Link und Mi Router nicht zurücksetzen. Als nächster einzelner Test wird die automatische IPv6-Adressverteilung und DHCP-PD am D-Link deaktiviert; danach wird Swigity Swooty erneut Ende-zu-Ende getestet.

Warum Netzwerktechnik im Jahr 2026 immer noch schwer ist

Das Zielbild ist einfach:

Die Fritzbox entscheidet.
D-Link und Mi Router funken und verbinden.
Alle Clients liegen in einem gemeinsamen Netz.

Die Umsetzung ist trotzdem schwer, weil heutige Heimnetze mehrere historische und moderne Schichten gleichzeitig betreiben:

  1. Ein „Router“ ist in Wahrheit ein Bündel von Rollen. Ein Consumer-Gerät ist gleichzeitig Router, Switch, Access Point, DHCP-Server, DNS-Relay, Firewall, NAT-Gateway und manchmal Mesh-Controller. Ein Moduswechsel muss mehrere dieser Rollen korrekt abschalten; Herstelleroberflächen zeigen das selten als zusammenhängende Architektur.
  2. IPv4 und IPv6 arbeiten parallel. Das Abschalten des IPv4-DHCP-Servers beendet nicht automatisch IPv6-Router-Advertisements oder DHCP-PD. Ein Gerät kann deshalb unter IPv4 sauberer Access Point sein und sich unter IPv6 weiterhin als Router ausgeben.
  3. Es gibt keine gemeinsame Wahrheit über Herstellergrenzen hinweg. Fritzbox, D-Link und Xiaomi besitzen jeweils eigene Begriffe, Betriebsmodi, Statusanzeigen und Mesh-Systeme. Kein Gerät versteht automatisch die beabsichtigte Gesamtarchitektur.
  4. Fehler werden durch Fallbacks versteckt. Browser und Betriebssysteme probieren mehrere Adressen, Protokolle und Gateways. Ein kaputter Pfad führt daher oft nicht zu einem klaren Fehler, sondern zu einer Minute Wartezeit und anschließend scheinbar funktionierendem Internet.
  5. Statusanzeigen zeigen nur die lokale Perspektive. Die D-Link-Meldung „Internetverbindung wurde getrennt“ bedeutet lediglich, dass sein WAN-Port leer ist. Sie sagt nichts darüber aus, ob Clients über einen LAN-Port und die Fritzbox das Internet erreichen.
  6. Physische Ports und logische Rollen werden sprachlich vermischt. WAN, LAN, DHCP, NAT, DNS, Routing, Repeating und Bridging sind unterschiedliche Kategorien, erscheinen in Consumer-Oberflächen aber oft wie austauschbare Schalter.

Das Problem ist deshalb nicht mangelndes Nutzerverständnis. Die Geräte erlauben mehreren Teilnehmern gleichzeitig, sich als „Chef“ des Netzes auszugeben, ohne den Konflikt verständlich zu melden. Ein zeitgemäßes System müsste die Gesamttopologie erkennen, genau einen Router bestimmen und alle nachgelagerten Geräte automatisch als Bridges konfigurieren.

Reset und Wiederzugriff

Bei verlorenem Adminzugang den eingeschalteten DIR-1960 über den versenkten Reset-Taster zehn Sekunden zurücksetzen und etwa zwei Minuten warten. Danach ist die Standardadresse wieder 192.168.0.1; die Konfiguration muss neu erstellt werden.

Projektinhalt

  • README.md: kanonischer Ist-Stand, Werte, Verlauf und Wiederherstellung
  • POSTMORTEM.md: ehrliche Fehleranalyse und kürzerer Ablauf fürs nächste Mal
  • COMMANDS.md: sichere Aufrufe, Prüfkommandos und Reset-Wiederherstellung
  • scripts/inspect_ap_state.sh: read-only Prüfung von Client, Router und Internet
  • scripts/dlink_ap_control.mjs: eng begrenztes D-Link-LAN/DHCP-Skript mit explizitem Apply-Gate und Passwortübergabe ausschließlich über stdin
  • index.html: lokale visuelle Erklärung und Prüfübersicht
  • DIR-1960_A1_Handbuch_EN.pdf: lokales Herstellerhandbuch
  • evidence/: passwortfreie Screenshots des Vorher-/Nachher-Zustands

Der wiederverwendbare Codex-Skill liegt unter /home/smlflg/.codex/skills/configure-router-as-access-point/ und wird mit $configure-router-as-access-point aufgerufen.

Absichtlich nicht gespeichert werden Admin- oder WLAN-Passwörter sowie der WLAN-Screenshot, der ein Passwortfeld enthalten kann.

Downloads last month

-

Downloads are not tracked for this model. How to track
Inference Providers NEW
This model isn't deployed by any Inference Provider. 🙋 Ask for provider support