Laut Doku soll dieser DC5200 Raid Controller SATA II mit 3Gbps koennen. Tja, in der Praxis faellt der Controller dabei aber auf die Schnautze:

[ 9.171954] ata1.00: exception Emask 0×52 SAct 0×3 SErr 0x400c01 action 0×6 frozen
[ 9.171954] ata1.00: irq_stat 0×08000000, interface fatal error
[ 9.171954] ata1: SError: { RecovData Proto HostInt Handshk }
[ 9.171954] ata1.00: cmd 60/80:00:8f:3a:7c/00:00:18:00:00/40 tag 0 ncq 65536 in
[ 9.171954] res 50/00:00:8f:3a:7c/00:00:18:00:00/40 Emask 0×52 (ATA bus error)
[ 9.171954] ata1.00: status: { DRDY }
[ 9.172028] ata1.00: cmd 60/80:08:60:00:00/01:00:00:00:00/40 tag 1 ncq 196608 in
[ 9.172029] res 50/00:00:8f:3a:7c/00:00:18:00:00/40 Emask 0×52 (ATA bus error)
[ 9.172826] ata1.00: status: { DRDY }
[ 9.172896] ata1: hard resetting link

Irgendwann schaltet der Kernel dann auf 1.5Gbps SATA und Ruhe ist. Das kanns natuerlich nicht sein.

Bei Debian Lenny schafft man sich nur Abhilfe damit, gleich von Anfang an auf 1.5Gbps zu limitieren:
In der Datei /etc/modprobe.d/options folgendes hinzufuegen:
options libata force=1.5G
(ggf. muss die Datei erst einmal erstellt werden.)
und dann mit update-initramfs -u die Aenderungen ins initramfs schreiben.

Wenn alles Richtig laeuft, meldet die Kiste beim naechsten reboot

ata1: FORCE: PHY spd limit set to 1.5Gbps

im dmesg.

Update: ich hatte mit diesem RAID-Controller noch ein Problemchen mit GRUB:
Wen ich im grub-boot-menu immer fix enter gedrueckt habe um den default kernel zu booten war alles in Ordnung. Sollte die Kiste aber ohne Eingabe booten, meckerte Grub mit grub error 18.
Verwirrend. Nach einiger recherche kam ich drauf: savedefault=false in der menu.lst ergibt das gewollte boot-Verhalten.

Debian bereitet die /etc/apache2/mods-available/suphp.conf schon richtig vor, im Verzeichniss /usr/share ist suphp also abgeschaltet. Nun hilft es leider nicht, einfach mod_php hinzu zuladen.
Vorher muss man die config des su_php leicht umschreiben nach folgendem Muster:

in der Datei /etc/suphp/suphp.conf die Zeile:

application/x-httpd-php=php:/usr/bin/php-cgi

in:

application/x-httpd-suphp=php:/usr/bin/php-cgi

aendern. Also ein “su” in den apptype hinzufuegen.
Ebenso in der Datei /etc/apache2/mods-available/suphp.conf:

AddType application/x-httpd-php .php .php3 .php4 .php5 .phtml
suPHP_AddHandler application/x-httpd-php

in:

AddType application/x-httpd-suphp .php .php3 .php4 .php5 .phtml
suPHP_AddHandler application/x-httpd-suphp

aendern. Hier also 2 Zeilen zu aendern.

Nun kommen sich die beiden php Arten nicht mehr in die Quere und man kann mit a2enmod php5 modphp wieder zuschalten, sofern man dies noch nicht getan hat.

Mit dieser Aenderung sollte jedes Zentral per apt installiertes script funktionieren, solange nicht vergessen wird, fuer den vhost oder alias die suphp engine abzuschalten, solange es sich nicht in /usr/share befindet.
Warum Debian dies nicht gleich so macht, ist mir allerdings ein Raetsel.

Uebrigens: ich hatte waehrend meiner Tests nen wunderbaren Bug im Firefox gefunden. Bot dieser einmal bei einem alias wie /phpmyadmin/ die index.php zum download an, weil noch kein handler installiert war, cached diese diese Information. Man kann am Server nun konfigurieren was man will…

Doku findet sich wie Sand am Meer. Zum testen entschied ich mich der Einfachheit halber fuer dnsmasq und einen TFTP Server fuer OSX. Ersteres sollte mein Fallstrick werden.
Die dnsmasq.conf benoetigt nur ein paar Zeilen:

dhcp-range=192.168.42.200,192.168.42.220,12h
dhcp-host=XX:XX:XX:XX:XX:XX,eeebox,192.168.42.219,infinite
dhcp-option=3,192.168.42.1

Hier fehlt eigentlich nur noch die boot-file anweisung fuers PXE. In einer Doku stand folgendes Beispiel:

dhcp-boot=/pxelinux.0,pos,192.168.1.11

Beim Bootversuch warf meine eee Box allerdings folgenden fehler:

PXE-T02 access violation
PXE-E3c tftp error access violation.

Es brachte mich zur Weisglut, denn die Fehlermeldung ist total Missfuehrend. Ich suchte am TFTPServer und fand nichts, wenn ich tftpget verwendete, bekam ich das bootfile. Nach vielen Versuchen und Vergleichen mit anderen Anleitungen fiel mir dann der / vor dem filename auf…
Eine fuer meine beduerfnisse richtige Version waere dann:

dhcp-boot=pxelinux.0,hermes,192.168.42.42


Nun klappts auch mit dem PXE-Boot via dnsmasq. Weiterfuehrende Doku:

Syslinux (fuers pxelinux.0)
Erklaerung der PXE config files und Demos
GRML ueber PXE booten ohne NFS (sehr elegant, wie ich finde)
Die Debian PXE Doku (und hier ist sogar der Eintrag fuers dnsmasq richtig )

Ernsthaft… Das Teil in allen Ehren, so auffem Schreibtisch. Aber das Innenleben…. Das heben der Frontplatte war noch das kleinste Problem, im Web gibts diverse Anleitungen. Letzterer link bietet sogar das Original Service Manual an! Doch dann laechelte mich etliche qcm schwarze Folie an. Diese ist an den Metallkanten festgeklebt und galt geloest zu werden. Die Festplatte verbirgt sich natuerlich hinter dem Display was bei der Gelegenheit also auch noch geloest werden muss. Da es aber nur hochgeklappt werden muss, reicht es, die schwarzen Alufolien links und rechts zu loesen. Klingt alles nicht so kompliziert, nach wenigen Minuten hielt ich die alte Platte auch schon in der Hand. Halterungen an die neue HDD schrauben, Kabel wieder dran, Display anschrauben, Folie wieder aufkleben, Deckel drauf. Puh… das wars erstmal, oder? Ein blick nach rechts und mich schaut ein Unschuldiges Kabel an…. Der Temperaturfuehler der Festplatte. Gnaaaaaa…. Also alles nomma auf. Zwischendurch wieder 5 (Arbeits-)Telefonate und die Flunder ist wieder zu und steht auf dem Schreibtisch. Ein click auf den Einschalter und der Chime ertoent. “Gute Arbeit!”
Doch dann das naechste boese Erwachen, einer der drei luefter faengt langsam an, Vollgas zu laufen. Was ist denn das nun? Ein kurzes surfen auf dem Laptop ergab, dass genau dieses Modell wohl hin und wieder Probleme mit seinem SMC hat, also muss es das sein und ich installiere mutig weiter Leopard.
Die Installation ist schnell durch und auch die Updates sind irgendwann drauf. Langsam bin ich von der Lautstaerke doch etwas angepisst und ich versuche, das SMC zu resetten…. Ohne Erfolg. Gedanken schiessen durch den Kopf. Doch was vergessen? Was passiert wohl, wenn die Lueftersteuerung einen Fuehler nicht findet? iStat zeigt mir allerdings sowohl Luefter Informationen als auch Tempfuehler…
Egal, irgend ein Fuehler muss fehlen, sonst wuerde das Ding nicht so aufdrehen. Also wieder auf. Langsam hab ich ja uebung. Was laechelt mich diesmal an? Das verdammte Festplattenfuehlerkabel, was diesmal zwar an der Platte klebt, aber vor lauter Telefonterror vergessen wurde, auf der Platine auch angeklemmt zu werden *FLUCH*
Naja, beim dritten mal geht alles schneller und nun rennt die Kiste erstmal bestens. Auch die Leopard installation hat so einiges gebracht. Selbst auf meinem 12″ Poserbook wirkt es deutlich schneller. Einen wahren Unterschied wird die Zeit zeigen.
Jedenfalls ist nun erstmal Progamme aufspielen und Userdaten wieder einspielen angesagt. Das geht allerdings echt gut von der Hand denn fuer die meisten Programme reicht es, vor ihrem ersten Start die entsprechenden Files in den ~/Library/Application Support Folder gelegt zu bekommen.

Damit das ganze nicht so eintoenig wird, meldet Timemachine auch mal lustige Fehlermeldungen:

Hier hat wohl jemand das Wort “mehr” vergessen

Mit
parted /dev/sdb print
bekommen wir raus, wie es um die disk geometry bestellt ist:

Disk geometry for /dev/sdb: 0.000-2336501.250 megabytes
Disk label type: msdos
Minor Start End Type Filesystem Flags
1 0.031 239348.502 primary ext3 boot
Information: Don't forget to update /etc/fstab, if necessary.

Wie hier zu sehen, Disk label type ist noch msdos. Wir merken uns aber schonmal start und endgroesse der “Platte”.
Nun muessen wir (Achtung, Datenverlust ab hier) mit

parted /dev/sdb mklabel gpt

den label type umstellen und mit

parted /dev/sdb mkpart primary 0 2336501

die Partition wieder anlegen. Die Start und Endwerte uebernehmen wir aus der parted /dev/sdb print Ausgabe. Mit selbigem Befehl kann man auch ueberpruefen, ob alles korrekt gelaufen ist. Ab hier kann man wieder wie gewoehnlich ein filesystem anlegen, in meinem Fall mit mkfs.ext3 -m0 /dev/sdb1 -L/vz

Das -m0 verhindert die gewoehnliche 5% root Reservierung, die hier Platzverschwendung waere. Mit -L schreibe ich ein filesystemlabel mit, welches die z.B. CentOS fstab so moechte. Noch eine Warnung: aeltere fdisks luegen auch jetzte noch mit der disk geometry, neuere verweisen sinnvollerweise direkt auf parted. Also auf keinen Fall mehr benutzen.

Viel Spass mit dem >2TB Volume

Ich scheiterte schon daran, dass auf meiner PSP noch die CFW 3.10OE-A schlummerte. Derzeit ist auf Dark Alex Homepage die Version 3.71M33-3 zu bekommen. Also steht mal ein Upgrade an. Aber auch dies erweisst sich als garnicht so einfach. Besonders, wenn man kein Forumkiddie ist
Als ich das letzte mal flashte war das allerdings alles noch viel komplizierter. Dark Alex schreibt zwar neue features in die Firmware, vertreibt aber nur seinen eigenen Code uebers Netz, die fehlenenden (Sony) Firmwareteile muss man sich selbst besorgen und daraus ein EBOOT.PBP bauen, mit dem man dann upgraden kann. Dies geschah damals mit einer Windowsanwendung.
Die Zeiten aendern sich gluecklicherweise, heute ist es wesenlich weniger kompliziert. Das Zusammenbauen des updaters geschieht direkt auf der PSP. So will man das.
Nun muss man allerdings eine seltsame Upgrade Hierarchie befolgen, da man nicht direkt auf die neueste DA FW upgraden kann.
Um direkt auf die CFW 371 m33 zu upgraden muss man mindestens eine CFW 3.52 M33-3 laufen haben.

Das folgende Howto ist fuer die erste Generation PSP, also NICHT die PSP Slim. Bis auf ein paar Kleinigkeiten unterscheidet sich die vorgehensweise allerdings nicht. Hierzu bitte die entsprechenden Readmes beachten!

Also schnappt ihr euch das 352 Upgrader Paket. Z.B. hier.
Kleiner Tip: Auch wenn die neuen Firmwarebuilder einen Integritaetscheck machen, ist es ratsam seine Quellen zu verifizieren. Dieses Pack hier behinhaltet gleich noch das original Sony Upgrade. Wie auch immer, dieses Pack tat bei mir und bei nem Kumpel.

Nach dem auspacken seht ihr 3 Ordner von Step1 bis Step3. Vorsicht: Natuerlich besteht hier immernoch die kleine Chance, dass beim flashen was schiefgeht. Das heisst, eure PSP wird nicht mehr starten und muss z.B. mit einem Pandora Akku gerettet werden. Ausserdem sollte der Akku mindestens 75% geladen sein und das Netzteil angeschlossen.

• Schritt 1: Step 1 brauch man NUR wenn ihr noch eine PSP mit original Firmware 1.50 habt. Ihr kopiert also den die Ordner kxploitpatcher und kxploitpatcher% nach ms0:/PSP/GAME/. Also auf dem Memorystick und fuehrt die Anwendung einmal aus, dann kann sie wieder geloescht werden.
• Schritt 2: Kopiert den Ordner M33CREATOR nach “ms0:/PSP/GAME” (bei 1.50 Firmwares) oder “ms0:/PSP/GAME150″ (bei SE/OE Firmwares). Nun fuehrt ihr den 3.52 M33 Creator aus, damit wird das eigentlich Update erstellt. Hier wird noch nichts geflasht, die Anwendung zieht sich aus dem im selben ordner liegenden Original Sony FW 3.52 die noetigen Dateien. Hiernach kann man nun das neu erstellte M33 Update starten. Anweisungen befolgen und auf keinen fall die PSP ausschalten bis eben diese Meldung kommt. Mit X oder O schliesst ihr das Upgrade ab (Diesen Schritt auf keinen Fall uebergehen). Es kann sein, dass man die PSP hier manuell ausschalten/rebooten muss, das ist normal, allerdings erst nachdem ihr vorher X oder O gedrueckt habt!. Die beiden Creator/Update Ordner koennen nun geloescht werden.
• Schritt 3: Im Ordner Step 3 liegt das Update auf Version 3.52 M33-4. Nach kopieren in den Ordner “ms0:/PSP/GAME150″ wird dies nun gestartet und man sieht, warum fuer den spaeteren updater eben diese Mindestversion gebraucht wird, es werden hier naemlich nur bestimmte Teile im flash ausgetauscht, nicht das ganze Firmware. Auch dieser Ordner kann nach erfolgreichem Update geloescht werden.

Nun zum Upgrade auf CFW 371:
Die Release Version gibts auf Dark Alex Seite zu downloaden. Auch das neuste Update sollte man herunterladen. Ausserdem braucht man das original Sony 3.71 Update. Das gibts hier.
Kleine Info fuer Homebrew Fans an dieser Stelle. Die 371M33 enthaelt KEINEN 1.50er Kernel mehr. Dieser kann ueber das “kernel 1.50 v2” Addon hinzugepatcht werden (hier muss aus Platzgruenden der LocationFree Player entfernt werden) oder man laed die Anwendungen ueber den eLoader. Ansonsten gelten die selben Warnungen wie schon beim Update zuvor…

• Schritt 1: Der UPDATE Ordner muss nach “ms0:/PSP/GAME” und das 371.PBP nach “ms0:/PSP/GAME/UPDATE”
• Schritt 2: “M33 Update” starten. Nach einem kurzen schwarzen Screen startet der Updater, der dem Sony Updater sehr aehnlich sieht. Alle Anweisungen befolgen und am Ende wieder X oder O druecken, wenn der Upgrader das fragt. Wie auch zuvor, diesen Schritt auf keinen Fall uebergehen. Nach Abgeschlossenen Update kann der UPDATE Ordner wieder geloescht werden.
• Schritt 3: Nun kommen die Updates dran. Man kann direkt von der Release auf 371M33-3 updaten, bei spaeteren Versionen bitte Readme beachten. Kopiert hierzu den UPDATE Ordner nach “ms0:/PSP/GAME” und fuehrt ihn die Updateranwendung aus.

Soweit, so gut. Ihr solltet jetzt also auf Version CFW 3.71 M33-3 sein. Leider geht Remote Play hier noch immer nicht. Dazu sind die folgenden, letzten Schritte zu befolgen.

Zunaechst braucht ihr das Original Sony Update 3.72, welches es hier gibt. Ausserdem braucht ihr den NEW PSARDUMPER von Dark Alex.

• Schritt 1: Kopiert den PSARDUMPER nach “ms0:/PSP/GAME” und das 3.72 EBOOT.PBP ins root Verzeichniss der Memcard, “ms0:/” und startet den Dumper. Nach dem Druecken von Quadrat (um alle Dateien aus dem eboot zu extrahieren) legt der Dumper auf dem Memcard ein Verz. “F0″ an. Aus diesem Verzeichniss brauchen wir die folgenden Dateien: “vsh/resource/premo_plugin.rco” und “vsh/module/premo_plugin.prx” zunaechst auf eurem Rechner.
• Schritt 2: Schaltet die PSP komplett aus (Powerknopf 5sec halten oder Akku raus) und beim Einschalten haltet die die R Taste. Im Recovery Menu geht ihr auf “Advanced” und dann auf “Toggle USB (flash0)”. Wenn ihr jetzt das USB Kabel wieder anschliesst, mounted ihr direkt das Firmwareflash. Nun muesst ihr nur noch die Dateien “vsh/resource/premo_plugin.rco” und “vsh/module/premo_plugin.prx” mit den vorhandenen ersetzen. Kurze Info: Die Dateien im Flash sind sowohl Schreibgeschuetzt als auch “Systemdateien” – Unter Windows muesst ihr den Explorer so einstellen, dass er diese Dateien auch zeigt. Nach dem Ersetzen nicht vergessen, das Schreibschutzflag wieder anzumachen. Sauber unmounten und via “back” und “Exit” das Recovery Menu verlassen.

Nun sollte Remote Play auch mit einem “alten” 3.71er Firmware funktionieren. Viel Spass

Dieses Phaenomen hab ich nun auf 2 grundverschiedenen Debian Etch Installationen. Einmal nahezu leer und einmal schon mit nen paar Paketen installiert.
Ein Blick in die /tmp/autoinstaller3.log zeigt die komplette APT Fehlermeldung. Beim zweiten Server liegt es lediglich am fehlenden bind9 Paket.
“apt-get install bind9” _vor_ der Plesk Installation behebt also dieses Problem. Kann der Autoinstaller das nicht selbst??

Wie dem auch sei, der zweite Server weigert sich immernoch. Das Log sagt was seltsames:

The following packages have unmet dependencies:
psa: Depends: psa-php4-configurator (>= 1.3.0) but it is not going to be installed or
psa-php5-configurator (>= 1.3.0) but it is not going to be installed
psa-updates: Depends: psa-php4-configurator (>= 1.3.0) but it is not going to be installed or
psa-php5-configurator (>= 1.3.0) but it is not going to be installed

Das heisst also, Plesk Pakete koennen selbst keine Abhaengigkeiten loesen? Tolle Show. Also weiter im Text, ich habe PHP5 auf dem Rechner. Will heissen, ich versuche rauszufinden, welche dependencies das “psa-php5-configurator” Paket hat. Garnicht so einfach, das gibt es naemlich nicht!
“psa-php4-configurator” hingegen will ein paar PHP4 Pakete. Nach einem “apt-get install php4-common php4-domxml php4-gd php4-mysql php4-imap php4-cli php4-curl libapache2-mod-php4” kann der Autoinstaller “psa-php4-configurator” auch installieren.
Die Installation laeuft nun also durch.

Schoen, dass ich nun PHP4 Leichen im System habe fuer ein Pleskmodul, welches vermutlich nichtmal mehr gebraucht wird.
Grosse bitte an SW-Soft: Wenn ihr meine Supportanfrage schon ignoriert, und ich bin nicht der Einzige, dann raeumt wenigstens fuer 8.2.2 die .debs auf… Danke.

UPDATE:
mit folgendem Eintrag in der /etc/apt/sources.list kann man den psa-php5-configurator nachinstalliern:
deb http://autoinstall.plesk.com/debian/PSA8 etch all
dann ein:
apt-get update && apt-get install psa-php5-configurator

Abhilfe schafft dafuer freie Scalp, sowie einige ein paar andere. z.B. das kommerzielle FTP iCal Calendars. Scalp soll wohl auch SSH/SFTP koennen, leider bekam ich hier immer auth failed.

Nichts destotrotz bin ich etwas entaeuscht von Apple… Features anbieten aber nur halbherzig unterstuetzen, hauptsache man promoted .Mac

Das Killerspielzeug schlechthin ist allerdings Earthview und hat Ausnahmsweise mal nichts mit Google zu tun
Anders als bei Google Earth wird hier auf LIVE Bilder diverser Wettersatelliten zurueckgegriffen. Klar, die Aufloesung ist noch nichtmal annaehernd so gut, aber z.B. Wolkenformationen oder die Nachtbilder rocken schon. Man sieht doch sehr eindrucksvoll wo auf der Welt viel Geld in die Beleuchtung des Himmels gesteckt wird. So fiel einem Kanalinsassen ein doch sehr heller Punkt mitten in der Algerischen Wueste auf. Bei naeherem betrachten wurde schnell klar, der “Punkt” ist heller als Berlin und das mitten in der Wueste. Was kann das sein?

Dank Google Earth und meines ausgereiften topografischen Koennens (ich sage nur NOF ) war der Ort schnell dingfest gemacht. Es handelt sich um Hassi Messaoud, eines der groessten Oel Raffinerien dieser Welt. Das Licht kommt also nicht nur von etlichen Lampen sondern von Gasbrennern welche das Gas, das nicht verwendet werden kann, abfackeln!

Update: via google earth sieht man die Fackeln sogar per Satelliten!

Heute stolperte ich ueber einen coolen Artikel in dem alle moeglichen Messenger erwaehnt werden. Ok dachte ich mir, neuer Versuch. Die Bedingungen sind klar, moeglichst gute E61 Keyboard unterstuetzung und Multiprotokoll. Ersteres kann ich natuerlich nur nach Installation selbst testen, nach Multiprotokoll liess sich schnell filtern. Diese blieben uebrig:

• Agile Messenger Symbian – $44,95
• IM+ Symbian – $29.95
• Causerie MIDP – $19.99 Symbian Version laeuft nicht auf E61

und folgende “scary” Services auf die ich gleich eingehe.

• Nimbuzz
• Mova Messenger
• Eqo
• fring
• yehba
• mobichat
• Xberggi
• Talkonaut

Causerie gefaellt mir ueberhaupt nicht. Der look ist von Vorgestern und die Bedienung ein Krampf. IM+ und der Agile kommen da schon etwas frischer daher. Den Agile hatte ich wie erwaehnt schonmal getestet, drum kann ich gerade die aktuelle Version nicht connecten lassen, viel scheint sich allerdings nicht geaendert zu haben. Beim IM+ faellt das automatisch einblendete Fenster auf, wenn man in einem vorhandenen Dialog anfaengt zu tippen. Ein “durch etliche Menues hangeln” wie bei Jimm faellt hier also flach. Beide koennen wohl Bild Transfer und IM+ wohl volles Filetransfer.
Allerdings gibts bei IM+ keinerlei quote Funktion zum Text weiterleiten usw. URLs, zumindest wenn korrekt gesendet, als clickbarer link angezeigt.

Kommen wir zu den restlichen Clients. Warum sage ich scary? Ganz einfach. Es gibt neuerdings eine vielzahl an mobilen IM Clients, die alle “besondere” Funktionen gebundled haben. Hauptmerkmal dieser Clients sind, dass, bevor man seine Handynummer preisgibt keine Services verfuegbar sind. Sowas laesst mich natuerlich aufschreien und erstmal zu den EULAs rennen. Da lesen sich dann Saetze wie:

• Provide you personalized content and advertisements
• Conduct research about your use of the Site and Services
• We may transfer your Personal Information within fring or to fring's third-party service providers and business partners, but only to provide services on the Site and Services or to you, across borders, and from your country or jurisdiction to other countries or jurisdictions around the world.
• Nimbuzz collects and processes, or has third party service providers who collect and process on Nimbuzz’s behalf, personal data relating to You, as permitted to (1) provide the Nimbuzz Services, in particular to convey the communications You make by means of the Nimbuzz Software and/or the Nimbuzz Services, (2) invoice to You Your use of the Premium Services and (3) carry out Nimbuzz marketing activities.

brr, genug davon, die Liste geht hier ins unendliche. Sowas will man natuerlich nicht. Aber wie so oft wird alles mit bunten Bildchen und “FREE DOWNLOAD” angekuendigt. Klar.

Talkonaut wiederrum hat eine interessante Faehigkeit. HTTP Binding. Damit laesst sich dieser Dienst z.B. mit einer O2 WAP Flatrate benutzen. Dafuer bundled Talkonaut ihren Jabber mit GTalk2VoIP und jede Menge bots.

Bei der Gelegenheit ist vielleicht noch Chatnu zu erwaehnen. Die Seite ist zwar (noch) in daenisch, aber hier wird ein funktionierendes Wireless Village zu ICQ und MSN Gateway geboten. Hat man ein ungebrandetes Sony Ericsson Handy hat man einen IMPS Client eingebaut (das E61 hat auch einen). Der Client pollt ueber http in regelmaessigen Abstaenden zum Server und holt sich updates. Das funktioniert natuerlich auch mit der O2 WAP Flatrate! Aber vorsicht, auch hier wird eine Rufnummer verlangt. Hier noch fix ein kleines Howto.

Hier die Loesung.
Scheinbar schaltet das E61 in dieser Situation quasi staendig zwischen UMTS und GPRS hin und her. Per Surfen oder sonstige Anwendung direkt per Handy scheint das nicht zu passieren, aber im Modembetrieb gibts hier nur Stress.
Wenn man das E61 direkt auf UMTS Betrieb festklopft, funktioniert der Modembetrieb auch bei ganz schlechtem Empfang wunderbar!
Leider muss man dazu das Telefon komplett rebooten beim umstellen.

System->Einstellungen->Netz->Netzbetrieb auf UMTS statt Dualmodus.

Also sah ich mir den Router mal etwas genauer an. Dieser hat einen tollen Formfaktor, kaum groesser als eine Zigarrettenschachtel (BigBox). Drin steckt wohl ein mit Linksys’ WRT54-GL baugleiches Innenleben. Die Leistung ist auch nicht schlecht, die Moeglichkeiten, ins Netz zu gelangen gehen von DHCP, statischer IP bis hin zu PPPoE. Netterweise ist das OS ein Linux, basierend auf OpenWRT. Hinzu kommt nur noch eine Software, um Internet fuer Fremduser erst nach Autorisation freigibt (chilispot).

Da dem so ist, gibts im Netz natuerlich eine Million Anleitungen, das Teil zu knacken um z.B. eigene Dienste darauf zu installieren. Mit der Zahl hab ich vermutlich nichtmal uebertrieben, weil jeder nur fuer eine bestimmte Firmware version instruiert. Fon bemueht sich natuerlich auf der anderen Seite, die Router dicht zu bekommen durch Updates. Diese werden uebrigens Automatisiert im Hintergrund eingespielt, ohne dass der Eigner viel davon mitbekommt. Bei jedem einschalten und spaetestens alle 24h telefoniert die Box naemlich nach Hause und fragt nach Updates oder Konfigurationsaenderungen. Man kann die Grundkonfiguration naemlich auch einfach auf der Zentralen Fon Seite vornehmen statt mit dem eigenen Router Webinterface.

Ok, lange Rede, aber warum schreib ich das hier ueberhaupt? Ich hab mich natuerlich ans hacken der Box gemacht… Das kam dabei raus:

Wie ich oben schon erwaehnte, es gibt tonnen von Anleitungen, nur wenige funktionieren, weil sie fuer eine spezielle Firmware Version gemacht sind.
Einer der ersten Hacks basierte auf code injection ueber das Webinterface des Routers. Diese Luecke wurde schnell geschlossen.
Auf Stefans Datenbruch Seite werden noch ein paar andere Moeglichkeiten besprochen, aber die Letzte ist wirklich Interessant. Fuer diese habe ich mich entschieden.

Was auch gut zu wissen ist: Niemals den Router selbt per Webinterface updaten! Die ausgelieferten Foneras haben bis heute meisstens Firmware versionen um 0.7.1-1 oder 0.7.1-2. Mit einer Reset Methode (Reset Taster 20 Sekunden halten und ohne Internet booten lassen.) kann man immer zu dieser Ausgelieferten Version zurueck. Auch wenn schon automatische Updates liefen, die z.b. unten besprochene Hacks verhindern. Man muss aber unbedingt drauf achten, dass die Fonera auf keinen Fall Zugang zum Internet bekommt, sonst sind die Updates wieder drauf

Jetzt kommen wir also zum Kolofonium Hack der Datenbruch Seite. Die Vorgehensweise hat mir hier sehr gut gefallen. Jede Fonera greift beim Systemstart auf einen Radius Server zu um sich die besagten Konfigurationsaenderungen und/oder neue User(Freunde, die umsonst surfen koennen) abzuholen. Das geschieht in Form eines Bashscripts. Tadaa Was Stefan nun macht, ist sich einen eigenen Radius zusammenzuhacken, der die Zeile “ipup /etc/init.d/dropbear” in diese Konfiguration einfuegt, das startet einen kleinen SSH Server. Man muss natuerlich irgendwie den DNS von radius01.fon.com und radius02.fon.com aendern. Nichts einfacheres als das, man traegt einfach (auch stefans) DNS Server ein. Nach einem Neustart hat man dann einen SSH Server am laufen, der allerdings nur auf dem Internen WLAN lauscht, fuer die andern Netze ist die Firewall (noch) zu.

Hier also eine Kurzanleitung die mindestens bis FW 0.7.1-3 funktioniert:

• La Fonera starten und warten, bis der Router komplett durchgebootet hat, so um 5 minuten.
• La Fonera per Webinterface Internetfaehig machen und folgenden DNS manuell eintragen: 88.198.165.155
• Reboot und wieder warten, bis die Box komplett durchgebootet hat.
• Jetzt muesste der SSH Server via Private Wlan erreichbar sein (Firewall verhindert noch Zugriff aus anderen Netzen)
• z.b. via ssh root@192.168.10.1 auf den Router connecten. Passwort ist das gesetzte Web Passwort, oder default “admin”

An dieser Stelle sollte man einige Vorkehrungen treffen, dass erstens der SSHD dauerhaft anbleibt und FON der Remotekonfigurationszugang genommen wird.
Das stellt man wie folgt an:

• mv /etc/init.d/dropbear /etc/init.d/S50dropbear
• vi /etc/firewall.user # und in den diese Zeilen entkommentieren:
  iptables -t nat -A prerouting_rule -i $WAN -p tcp—dport 22 -j ACCEPT
iptables -A input_rule -i $WAN -p tcp—dport 22 -j ACCEPT
• vi /bin/thinclient # Die letzten Zeilen z.B. so umschreiben (dann sieht man auch, was Fon so treibt auf den Kisten)
  #. /tmp/.thinclient.sh
cp /tmp/.thinclient.sh /tmp/thinclient-$(date '+%Y%m%d-%H%M')

Jetzt noch das offene FON_* Netz abklemmen:

• vi /sbin/ifup # ganz unten den case “hotspot” auskommentieren:
  hotspot)
# ifdown hotspot
# setup_hotspot_wifi
;;
  Bei der Gelegenheit kann man auch gleich den ganzen Hotspot Kram abschalten…

Nun hat man einen handlichen Reiserouter und/oder Wlanextender. Dank offenem System sind die Moeglichkeiten nahezu unbegrenzt

Wie kommt man da drauf? Minutenlanges googlen… Selbst in /usr/share/doc/uw-imapd/README.Debian steht nichts diesbezgl.

Dem ist leider nicht so, also setze ich da mal ausserhalb vom Apachen an. Wie waere es, einfach per cron alle x Minuten durch die Prozessliste zu gehen und zu schauen ob ein userscript laenger als x minuten laeuft? Nichts einfacheres als das. Soviel zur Theorie. Nach so einigem gecode kam ich dann zu diesem ersten script:


#!/bin/bash
# script zum ueberwachen von zu lange laufenden scripten
# killt alle scipte (ausser whitelist) nach $maxruntime minuten
#
hostname=$(hostname)
maxruntime=1
minuserid=10000
if [ "$1" != "" ] ; then debug=1 ; fi

for i in $(find /proc -maxdepth 1 -uid +$minuserid -type d -cmin +$maxruntime)
do
cmdline=$(cat $i/cmdline)
proftptest=$(fgrep proftpd $i/cmdline)
if [ "$proftptest" = "" ] ; then
uid=$(stat -c%U $i)
if [ "$debug" = "1" ] ; then
echo $cmdline von user $uid laeuft laenger als $maxruntime minute"(n)"
else
echo | mutt root -s "$cmdline von user $uid laeuft auf $h
ostname laenger als $maxruntime minute(n)"
fi
else
if [ "$debug" = "1" ] ; then
echo $proftptest laeuft
fi
fi
done


Klar, im ersten Versuch killt es noch nichts, sondern mailt erstmal die Verstoesse. Nach den ersten paar Minuten im cron fiel mir allerdings auf, dass viele Kunden cgi upload scripte haben und dergleichen. Hier muss ich also die “whitelist” noch ein wenig aufbohren, nach einem proftpd alleine zu checken reicht wohl nicht
Das endgueltige script werde ich wohl im Downloadbereich posten.

Hier gehts lang. Lang passt grad, die Liste wurde wirklich lang Ich hoffe es ist hilfreich fuer den ein oder anderen.