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

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!

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.

iPhone 4 mit iOS 4.2.1 und Ubuntu 10.10 „Maverick Meerkat“

Nachdem sich der Asus eeePC mittlerweile als überraschend brauchbar gezeigt hat (CPU reicht in jedem Fall für ein bisschen Browser-, E-Mail- und Terminal-Nutzung und sogar für Filme, wenn diese nicht in Full HD vorliegen), waren Verbindungsversuche zum iPhone 4 (iOS 4.2.1) leider nicht sofort von Erfolg gekrönt.

Eine kleinere Google Recherche lässt annehmen, dass das mit iOS 4.2 noch anders war, aber das hilft nach dem Update des iPhones auch nicht weiter. Glücklicherweise arbeiten wir ja mit einem Linux-System und nicht mit Windows – wir haben also Fehlermeldungen 😉

Unable to mount iPhone_ org.freedesktop.DBus.Error.NoReply DBus error: MESSAGE DID NOT RECEIVE A REPLY (TIMEOUT MESSAGE BY BUS)

Plug & Play schaut anders aus – echt lästig, dass Apple seine Geräte mit jedem Softwareupdate an irgendeiner Stelle wieder etwas geschlossener Macht. Wenn MacBook, iPhone & Co. nicht so perfekt auf meine Bedürfnisse passen würden und so gut funktionieren würden müsste man in der Tat aufhören, Geld in Richtung Apple zu transportieren…

Wir haben es hier aber mit einem häufig auftretenden Problem zu tun, sodass die Lösung nicht allzu schwer zu finden war (und zwar hier und hier).

  • es braucht einige Paketupdates, die bisher noch keinen Einzug in die Ubuntu Repositories gefunden haben
  • diese sind unter dem Namen „PPA for Paul McEnery“ bei launchpad.net zu haben
  • zentral hierbei sind die Pakete bgpod und iFuse, es werden aber noch ein paar weitere Pakete mit aktualisiert – wichtiger Hinweis an der Stelle: Der Asus eee PC mit Ubuntu dient für mich nur für 4 Wochen als „Urlaubsbegleiter“ – ich bin daher nicht tiefer eingestiegen und habe nicht intensiv geprüft, wie sich die gepatchten Quellen aus o.g. APT-Repository unterscheiden. Wer es mit der Sicherheit ernst nimmt, will das bitte noch tun, bevor er die Pakete z.B. auf betrieblich oder privat dauerhaft eingesetzten Rechnern installiert!

Die Installation an sich ist ebenso einfach wie sie den Titel „Holzhackermethode“ verdient 😉

Erstmal die o.g. Paketquellen hinzufügen:

sudo add-apt-repository ppa:pmcenery/ppa

updaten & los:

sudo apt-get update

sudo apt-get dist-upgrade

Und voilà – das iPhone wird erkannt….

Asus Eee PC mit Ubuntu 10.10 (Maverick Meerkat)

Auch wenn mein Apple MacBook Pro (13.3 Zoll) ja schon recht handlich ist, so wäre als Reisebegleiter weniger Gewicht und weniger Größe durchaus nett – ich teste daher gerade einen Asus Eee PC (danke an die Kollegen von make.tv für die Leihgabe!).

An Windows mag ich mich aber nicht gewöhnen müssen. Als erstes wurde daher ein Image der bestehenden Platte gemacht und das installierte Windows XP durch ein Ubuntu 10.10 (Maverick Meerkat) ersetzt.

In Ermangelung eines internen CD-/DVD-Laufwerks wollte ich vom USB Stick booten, dies schlug aber fehl. Trotz verschiedener USB Sticks, trotz der Erstellung des bootfähigen Images unter Linux und Mac OS hat der Eee PC partout nicht vom USB Device booten wollen. Mit einem externen USB CD-Laufwerk hingegen klappte die Installation ohne Probleme – bis auf eine Kleinigkeit, die aber schnell zu beheben war:

Displayhelligkeit

Das Display gibt erst einmal ein enttäuschendes Bild ab: Es ist nach der Installation dunkler als beim vorher installierten Windows und läßt sich über die Einstelldialoge von Ubuntu ebenso wenig gut einstellen wie über die Funktionstasten: Die Helligkeit „springt“ zwischen den Stufen stark hin und her – und bei Einstellungen über 79% Bildschirmhelligkeit wird es wieder dunkler (!).

Die Lösung hierfür ist schnell und einfach, gefunden im Blog von Tom Schimana:

Datei „/etc/default/grub“ editieren:

vi /etc/default/grub

Dort zur Zeile GRUB_CMDLINE_LINUX_DEFAULT navigieren und hier folgende Änderung vornehmen bzw. die Zeile durch diesen Text ersetzen:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=Linux"

Mit sudo update-grub2 die Änderungen speichern bzw. die Grub Konfiguration erzeugen, reboot und schon ist das Problem gelöst…

Zwischenfazit

Nachdem nun der Monitor hell strahlt, bin ich mit dem ersten Eindruck sehr zufrieden. Natürlich ist so ein Asus Eee PC kein Ersatz für mein Apple MacBook Pro, aber mit ca. 250.- Ladenpreis kostet das Netbook schließlich auch nur ca. ein Drittel…

Ich nutze den Rechner jetzt ein paar Tage zu Hause und entscheide, ob ich damit in unserer Ferienwohnung im Urlaub für ein paar Stunden arbeiten kann. In dem Falle bleibt der Apple zu Hause – das Asus Gerät ist leichter, kleiner und im Falle eines Diebstahls eher zu verschmerzen 😉