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.

Foto Vorschau mit Lightbox und Thumbnails in Apache DirectoryIndex dank h5ai

Ich habe die gesamte Fotodatenbank bzw. das Fotoverzeichnis zu Hause auf dem Server liegen und spiegele diese (u.a.) auf mein MediaCenter (MacMini). Per Samba Share oder auch per http kann man also mit allen Devices auf den Server zugreifen, was am Computer auch gut klappt: SMB verbinden und dann mittels der normalen Werkzeuge (Explorer, Finder, Vorschau, ThumbsPlus, ASeeDsee etc.) auf die Bilder zugreifen.

Beim iPad oder iPhone muss man allerdings auf vernünftige SMB Integration (auch per App) verzichten, sodass das hier keine Lösung ist – und ein Zugriff per Browser auf die nackten Apache Verzeichnisse ist wenig elegant oder praktisch.

Daher habe ich immer mal wieder nach einer tauglichen Lösung gesucht, mit der ich das Apache DirectoryListung (aka. Apache DirectoryIndex) um eine Vorschaufunktion erweitern kann. Die meisten Lösungen basierten darauf, die HTML Vorlagen für den DirectoryIndex um etwas JavaScript zu ergänzen und so eine Lightbox nachzurüsten. Das sieht im ersten Moment ganz gut aus, reicht aber fürs Browsing nicht wirklich: Vorschau fehlt, i.d. Regel fehlen vor- und zurück-Funktionen.

Am Wochenende bin ich auf das wirklich großartige h5ai gestoßen, laut eigener Beschreibung „a modern HTTP web server index“. Der Programmautor (Lars Jung) hat da eine sehr leicht einzurichtende Lösung gebaut und offen gelegt, die ich sehr, sehr schick finde.

Schaut so aus:

h5ai_01

h5ai_02

Die Einrichtung dauerte bei mir auf dem Linux Server 5 min. und unter Mac OS X 20 min., weil dort etwas mehr an der Apache Konfiguration angepasst werden musste – also eine kleiner Schritt für den Admin, ein großer Schritt für meine Familie 🙂

Hier nochmal der Link: http://larsjung.de/h5ai/

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 {} \;

Veto Files, .DS_Store, .AppleDouble & Co.: Notizen zu Mac OSX Clients am Linux Server mit Samba

Die Leser, die schon länger OSX Clients mit einem Samba Server bedienen, werden die Besonderheiten kennen: Der Dateimanager des Mac OS (Finder) speichert eine ganze Menge an Metadaten zu Dateien und Ordnern in versteckten Dateien namens .DS_Store, .AppleDouble u.a.

Die Dateien beginnen alle mit einem Punkt und sind daher standardmäßig auf OSX, Windows und ebenso in der Linux-GUI versteckt bzw. unsichtbar. Spätestens wenn man aber per Terminal auf dem Server unterwegs ist, sieht man die Dateien, ebenso wenn man die Anzeige versteckter Dateien auf dem Client aktiviert hat: Das ganze Serverlaufwerk wird mit den Metadateien o.g. „versorgt“, was gerade Mac-Anwendern in heterogenen Netzen vermutlich nicht allzu viele Freunde machen dürfte 😉

Da in den Metadaten nur Dinge wie z.B. die letzte Sortierung o.ä. belanglose Dinge gespeichert werden, kann man deren Erstellung ohne mir bekannte Nachteile deaktvieren.

In meiner Agentur (die Internetagentur dimensional aus Köln) hatten wir das Thema vor vielen Jahren schonmal behandelt. Damals – zu Zeiten älterer Finder-Versionen – hatten wir über die Option veto files im Samba den Rundumschlag gemacht und alles Mac-spezifische verboten. Seinerzeit war da noch etwas mehr nötig als heute:

Aus der alten Samba Konfiguration (smb.conf):

Unerwünschte Dateien verbieten:
(Achtung, alt – richtige/aktuelle Konfiguration folgt weiter unten!)
veto files = /.?Desktop/.finderinfo/*Desktop DB*/resource.frk/.bin/Network Trash Folder/OpenFolderList*/TheVolumeSettingsFolder/.DS_Store/._*

Unerwünschte Dateien verstecken:
(Achtung, alt – richtige/aktuelle Konfiguration folgt weiter unten!)
hide files = /.*/DesktopFolderDB/Trash-For%m/resource.frk/*Desktop DB*/*Desktop DF*/*OpenFolderList*/*Network Trash Folder*/Network Trash Folder*/Icon*/.AppleDouble/TheVolumeSettingsFolder/.index-formatierung

Und noch das Löschen von Ordnern ermöglichen, die ggf. noch solche Dateien enthalten:
(Achtung, alt – richtige/aktuelle Konfiguration folgt weiter unten!)

delete veto files = yes

Jetzt aktuell hatte ich auf meinem Fileserver zu Hause einige eigentümliche Probleme, die m.E. mit der unfassbar grottenschlechten nicht so gelungenen Samba Implementation von Mac OS X und deren Zusammenspiel mit dem Samba Server liegen. Das Hauptproblem war, dass das Kopieren von Dateien auf den Server mit seltsamen Fehlermeldungen fehlschlug. Ein weiteres grundsätzlicheres Problem mit der SMBX genannten „Apple-eigenen“ Samba Implementation sind extrem geringe Transferraten beim Kopieren.

Ich habe mir daher den Server und speziell das Samba File Sharing vorgenommen und einfach mal „Inventur“ gemacht. Rausgekommen an Aufgaben ist:

Der Übersichtlichkeit halber werde ich die Infos auf die o.g. 4 Artikel verteilen.

Update: einer der o.g. Artikel ist schonmal da……weiteres Update folgt!

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 😉

Seiten oder Dateien in Mediawiki per Batch löschen

Ergänzend zum gerade vorher veröffentlichten Kurzartikel zum Import von Bildern hier noch der thematisch passende Hinweis, wie man sein Mediawiki auch wieder schnell von den importierten Dateien befreien kann 🙂

(klappt auch zum „schnell- bzw. batch-Löschen“ von Seiten)

  1. in der LocalSettings.php die Extension „Nuke“ aktivieren (ist seit einiger Zeit Bestandteil der Mediawiki Distribution), also die Zeile einfach in die LocalSettings.php einfügen:
  2. require_once "$IP/extensions/Nuke/Nuke.php";
  3. dann (bei einer deutschsprachigen Installation) die Seite „https://$deine-wiki-url/index.php/Spezial:Massenlöschung“ aufrufen
  4. der Rest sollte halbwegs selbsterklärend sein

iPhone mit iOS 6 erhält keine Verbindung zum WLAN / DHCP Lease Time

Das ist ja kaum zu glauben. Im Netzwerk daheim steht ein WLAN Router und Access Point mit DD-WRT. Dort sind für die regelmäßig im Netzwerk verwendeten Geräte statische IPs definiert, damit nicht jedes Mal eine andere IP zugewiesen wird.

Bisher hatte ich das stumpf mit dem größtmöglichen in das Feld passenden Wert konfiguriert, bei dem o.g. DD-WRT war das „999999999 Minutes“. Mit anderen Worten also die Anweisung an die Wireless Geräte: „keine Nachfragen nötig, Deine IP und Deine Daten werden sich niemals ändern“.

Das funktionierte bisher auch mit allen Devices (iPhone 3 mit iOS 3, iPhone 4 mit iOS 5, MacBook, MacMini, Dell Notebook…) ganz problemlos….bis das iOS 6 Update kam. Ab dem Tag wollte das iPhone 4 sich partout nicht mehr mit dem WLAN verbinden. Sinnvolle Fehlermeldungen gibt es natürlich nicht, also bleibt nur probieren. Nachdem ich ziemlich alle Parameter des WLANs mal testweise angepasst hatte, habe ich als letztes mit der Lease Time experimentiert.

Und siehe da: Setzt man das auf einen niedrigeren Wert, klappt die Connection sofort.

In diesem Artikel wird die maximal als Lease Time zulässige Dauer wie folgt beschrieben:

The DHCP specification allows a lease to be up to 232–2 seconds (49,710 days, or about 135 years).

Das scheint Apple wohl nicht zu wissen….naja, auch viel geringere Werte reichen ja völlig, daher habe ich die nach dem o.g. Erlebnis auch mal reduziert auf 1 Tag, entsprechend 1440 Minuten.

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.

Netgear WLAN Router WNDR3700 mit DD-WRT (alternative Firmware)

Es ist ja wirklich seltsam: Da kauft man einen WLAN Router, nimmt ihn mit der Standardsoftware in Betrieb…und wundert sich darüber, dass das „High Tech Teil“ so weit hinter den Erwartungen zurückbleibt, die der Hersteller geweckt hatte.

So geschehen z.B. bei meinem Buffalo WHR-HP-G54, der mit der installierten Firmware des Herstellers zwar halbwegs funktionierte, aber dauernd Verbindungsabbrüche bei Windows Rechnern erzeugte, sobald Mac OS Clients zum WLAN verbunden waren. Hinzu kam eine eher enttäuschende Performance. Glücklicherweise ist der Markt der WLAN Router das Hardwaresegment, wo ein Austausch der Hersteller-Firmware gegen freie Software problemlos möglich ist (wobei Buffalo ja sogar GPL-Software als Basis für seine Firmware verwendet).

Nach einiger Recherche hatte ich mich aufgrund des nicht allzu leistungsstarken Prozessor des Buffalo G54 Gerätes für die Tomato Firmware entschieden, die mit einem ausreichenden Funktionsumfang, einem sehr schlanken, tauglichen Interface und nicht zuletzt mit extremer Stabilität auftwarten kann.

Also die Firmware installiert, alle Einstellungen vorgenommen – et voilà: Alle Probleme gelöst. Außer anläßlich eines Umzugs musste ich das Gerät seitdem nicht mehr neu starten oder vom Stromnetz trennen. Statt dessen erfreue ich mich an Eigenschaften, die man sonst einem buckligen Auto nachsagte: Er läuft und läuft und läuft.

Für ein zweites Netzwerk bei mir nebst eigenem DSL Anschluss kam vor einigen Monaten ein Netgear WNDR3700 ins Haus (siehe auch Produktseite bei Netgear.de). Wie immer bei Technikprodukten darf der geneigte Leser davon ausgehen, dass ich mich vor dem Kauf umfassend informiert hatte 😉

Der Funktionsumfang stimmte also, auch die Leistungsfähigkeit der Hardware (Atheros AR7161 680 MHz CPU, 64MB RAM, 16 MB Flash, Realtek RTL8366SR Switch, Dual Band Technologie mit 2.4 GHz/AR9223 und 5 GHz/AR9220…).

Schade nur, dass die Performance so gar nicht stimmen wollte – insbesondere im internen Netz. Da sich hier sehr unterschiedliche Devices zum WLAN verbinden (iPhone 1, iPhone 4, ein alter Dell Laptop, ein MacBook Air, ein MacMini u.v.m., wenn die Familie zu Besuch ist..), kann ich auf einen „mixed mode“ nicht verzichten. Auch Device-spezifische Optimierungen scheiden somit eigentlich aus, wenn ich zu Hause nicht die ganze Zeit IT-Support leisten will. Wir erwarten also nicht das letzte Quentchen an Performance, wenn ich das brauche, greife ich auf Gigabit Ethernet Verkabelung zurück 😉 Dennoch: Mehr als 1 MB/Sek. dürfte schon gerne zwischen den Clients erreicht werden – auch wenn die Rahmenbedingungen (hinsichtlich der Geräte) alles andere als ideal sind.

Gut, dass bei der Auswahl des Gerätes auch der volle Support des Gerätes durch DD-WRT (Link zum Wikipedia Artikel) ein Entscheidungskriterium war.

Ich habe also anhand der guten gerätespezifischen Dokumentation im Wiki auf DD-WRT.com die DD-WRT Firmware eingespielt und eingerichtet, was nur ca. 20 Min. in Anspruch genommen hat (inklusive Vornahme aller Einstellungen für das Netzwerk wie WPA2 Verschlüsselung, Gästenetz mit einfacherem Zugang etc. pp.).

Die gesamte Installation und Einrichtung lief völlig problemlos, die Ping-Zeiten sind erheblich gesunken und im Ergebnis gehen nun nicht mehr 1 MB/Sek., sondern immerhin mal 5 MB/Sek. übers interne Netzwerk (via WLAN). Operation erfolgreich, würde ich sagen 😉

Und getreu dem Motto „if it ain’t broken, don’t fix it!“ werde ich mir weitere Optimierungen jetzt erstmal sparen, das kommt ggf. später. So „out of the box“ läuft das Gerät ja bereits erstaunlich gut.

Google für Admins, Google über die Shell

Endlich. Siehe Screenshot und Link.