Netgear WNDR 3700 Firmware Update mittels Beta Version

Netgear WNDR3700 WLAN RouterMein WLAN Router zu Hause ist ein Netgear WNDR3700 (V2), mit dem ich seit Installation der DD-WRT Firmware auch völlig zufrieden bin.

(siehe dd-wrt.com/…/Netgear_WNDR3700 für alle Infos zur Installation und vor allem zur Auswahl der korrekten Firmware!)

Beunruhigend fand ich allerdings immer, dass die Stable Version der Firmware schon arg staubig war: Das Releasedatum 19.03.2012 sagt mir, dass es nicht um die Frage geht, ob dort ungepatchte Sicherheitslücken bestehen sondern welche 😉

Installiert war also bisher V24-SP (SVN Rev. 1877) und da ich nie ein neues stable Release sah, blieb das auch bisher so. Heute habe ich mir endlich die Zeit genommen, mal zu recherchieren und was zu ändern.

Ergebnis: Die DD-WRT Entwickler geben eher selten überhaupt stable Versionen heraus (eigentlich fast logisch, wenn man sich den Testaufwand für deren Releases vorstellt bei einer solchen Vielzahl an unterstützten Devices..).

Das Projekt ist aber unverändert sehr aktiv und es gibt regelmäßige Builds für die Betaversionen. Diese sind zu finden unter ftp.dd-wrt.com/betas/

Dort stehen die Beta-Builds dann nach Jahr, Build-Datum und nach Router zum Download bereit, und zwar jeweils in 3 Versionen. Gebraucht wird logischerweise immer nur eine davon – je nachdem, was man hat/will:

  • wndr3700v2-factory.img – zum Flashen eines WNDR3700 Routers, der noch die Originalfirmware hat
  • wndr3700v2-factory_NA.img – zum Flashen eines US- oder Kanada-Modells (NA = North America) des Routers, der noch die Originalfirmware hat
  • wndr3700v2-webflash.bin – zum Flashen eines bereits mit DD-WRT laufenden Routers

Oder in anderen Worten:

Note: factory.img is for worldwide units flashing from NETGEAR firmware to DD-WRT, or recovering from TFTP mode. factory_NA.img is the same except for North American units. Webflash is from upgrading an existing DD-WRT firmware to a newer build via update firmware option.

Dass man das Flashen der Firmware niemals nicht übers WLAN macht sondern stets über ein Netzwerkkabel, ist sicher jedem klar. Ist es doch, nicht? 🙂

Flashen mit der wndr3700v2-webflash.bin ging bei meinem Router völlig unproblematisch. Hinsichtlich Funktionalitäten oder Performance kann ich auf die Schnelle ich keinen Unterschied ausmachen, aber es ging ja auch um Sicherheitsbedenken und nix anderes.

Achtet auf jeden Fall darauf, beim Update dieses Routers auf die Hardwarerevision zu achten! Es gibt beim Netgear WNDR 3700 eine V1, V2, V3 und V4 – nimmt man die falsche Firmware, kann (wird!) dies den Router „bricken“ – er ist dann nur mit etwas mehr Aufwand noch zu retten.

Apple-spezifische Dateien wie .AppleDouble, .DS_Store etc. löschen (mittels find)

Wie im etwas längeren Artikel zu den Mac-spezifischen Dateien (.AppleDouble, .DS_Store etc.) und Veto Files angekündigt:

Haben sich einmal Mac-User mit dem Server verbunden, bevor deren Rechner oder der Server richtig konfiguriert worden sind, hat man den Salat: Alle Verzeichnisse sind voll mit den lustigen Finder-Metadaten.

Diese kann man finden mittels…

find \( -name ".AppleDouble" -or -name ".DS_Store" -or -name ".Trashes" -or -name "._*" -or -name ".TemporaryItems" \)

…und löschen mittels…

find \( -name ".AppleDouble" -or -name ".DS_Store" -or -name ".Trashes" -or -name "._*" -or -name ".TemporaryItems" \) -execdir rm -Rv {} \;

Backup / Sicherung von Fritzbox (bzw. korrekterweise „FRITZ!Box“) erstellen

Ein Blogeintrag für die Erstellung einer Datensicherung für die Fritzbox scheint fast absurd – schließlich hat die FRITZ!Box eine halbwegs taugliche Admin-Oberfläche, innerhalb derer man das Backup per Klick erzeugen und downloaden kann.

…wäre da nicht eine Kleinigkeit (s.u.)…

Regulär ist es wie einleitend bemerkt kinderleicht, seine Daten zu sichern:

  • in die Verwaltungsoberfläche gehen
  • dort den Menüpunkt „System / Einstellungen sichern“ aufrufen
  • den Tab„Sichern“ aufrufen
  • Sicherung durchführen

Man hat hier die Möglichkeit, ein Passwort zu vergeben. Schade nur, dass der Hersteller AVM an dieser Stelle nicht darauf hinweist, dass dies zwingend erforderlich ist, wenn man das Backup in ein anderes Gerät (z.B. wie in meinem Fall eine Austausch-Hardware) einspielen möchte.

RTFM, könnte man sagen, denn im Handbuch steht es drin:

Um Ihre gesicherten Einstellungen in eine andere FRITZ!Box gleichen Modells zu laden oder um für Ihre FRITZ!Box Einstellungen einer FRITZ!Box anderen Modells zu übernehmen, muss die Sicherungsdatei jeweils mit einem Kennwort versehen sein.

Darauf will man also achten 😉

SSH Agent Key forwarding auf Mac OS X Systemen

SSH Agent Key Forwarding ist toll, wenn man mit vielen Hosts hantiert. In meinem konkreten Anwendungsfall will ich mich mit meinem SSH Key auf dem Server eines Kunden authentifizieren, wenn ich Daten von einem unserer Server auf das Kundensystem synchronisere.

Der Key wird also in diesem Use Case durchgereicht (mein Rechner –> interner Server –> externer Server), sodass ich sicher auf den externen Server zugreifen kann, ohne Passwörter zu verwenden oder meinen Key auf den internen Server legen zu müssen.

Sehr praktisch – wenn es denn funktioniert. Auf meinem Mac tat es das nie, obwohl ich mittels ssh -A $servername um das Key Forwarding bat. Auch eine Unterstreichung der Bitte über den Eintrag ForwardAgent yes in der SSH-Konfiguration (/etc/ssh_config) brachte leider nicht das erwünschte Ergebnis.

Ich habe mir dann immer damit abgeholfen, dass ich mich stets über ein Linux System eingeloggt habe, wo der Key auch hinterlegt war.

Anscheinend habe ich aber bei der heutigen erneuten Recherche geeignetere Suchbegriffe gewählt und endlich den passenden Hinweis gefunden:

Man muss unter OSX erstmal dem SSH-Agent die RSA- oder DSA-Identität (den Key) manuell bekannt machen.

Dies passiert einfach mittels ssh-add.

Was dann passiert beschreibt die Manpage mit…

ssh-add adds RSA or DSA identities to the authentication agent, ssh-agent(1). When run without arguments, it adds the files ~/.ssh/id_rsa, ~/.ssh/id_dsa and ~/.ssh/identity. After loading a private key, ssh-add will try to load corresponding certificate information from the filename obtained by appending -cert.pub to the name of the private key file.

…und das war es auch schon – der Key wird forgewarded und das Login auf dem externen Server klappt.

Google für Admins, Google über die Shell

Endlich. Siehe Screenshot und Link.