DNS-323

[MsZ]

Premessa

Recentemente ho acquistato un D-Link DNS-323. E' un NAS con delle funzionalità interessanti, tra cui la creazione e la cura di alcuni tipi di array RAID (RAID0, RAID1 o JBOD). Ma la caratteristica più interessante è che il DNS è un computer vero e proprio, un sistema embedded che gestisce delle unità di immagazzinamento dati via LAN. E' un computer particolare, con delle specifiche descritte qui, che ospita un sistema Linux (o meglio, un sistema U-Boot + Linux + uClibc), altamente modificabile.

Ed è qui che arriva il bello. Ma prima, alcune spiegazioni.

Caratteristiche principali
Hardware:

• Processore: ARM Feroceon 500MHz
• RAM: 64MB
• EEPROM: 8MB
• USB: 1 porta 2.0 (Full-Speed)
• Supporto: 2x SATAI
• Chipset: Marvell

Software:

• Linux 2.6.12.6
• uClibc 0.9.28
• U-Boot 1.7.3
• BusyBox 1.0.0pre1
• Samba 3.0.24

(tutti modificati da D-Link)

Ci sono poi molti altri eseguibili qua e là, scritti e compilati da D-Link, di cui non esistono sorgenti. Questi sono i più ambigui e difficili da analizzare, ma ci tornerò più avanti.

fun_plug

Il DNS-323, visto da fuori, non è che sia 'sto granchè modificabile. Però fin dall'inizio c'è uno spiraglio di possibilità.
Per default, il sistema cerca, all'avvio, in uno dei dischi montati al suo interno, uno script per /bin/sh chiamato fun_plug, che abbia flag 0755, e lo esegue. La cosa più interessante è che in fun_plug si può mettere teoricamente qualunque cosa che passi per la testa.

Ma questo può non bastare. Se uno vuole un qualche cosa direttamente all'interno del DNS-323 deve andarsi a modificare il firmware.

Il firmware

Se devo dire la verità, il firmware del DNS non è un granchè. E' ottimizzato per il DNS, ma mancano alcune cose fondamentali come il check dei filesystem all'avvio del sistema, che è una grave mancanza per un sistema Linux. Inoltre, non c'è un vero smontaggio pulito dei dischi all'arresto del sistema, che può causare delle corruzioni nei filesystem.
Queste sono le cose più rilevanti. Ci sono delle cose che non capisco, prima tra tutte l'insieme degli errori di sintassi, la sovrabbondanza di commenti e la presenza di righe echo che in un sistema embedded, che non ha monitor, non servono ad altro che aumentare lo spazio occupato. Forse per un eventuale debug, ma gli unici messaggi che contano per me sono quelli del kernel, e in ogni caso si può sempre redirigere l'output in un file.

Ma andiamo con ordine.

Il firmware del DNS è organizzato in tre parti principali, poi suddivise in cinque parti nella ROM. Nel sito della D-Link trovate dei firmware per l'aggiornamento del sistema. Splittando il firmware trovate tre file:

• uImage
  uImage è il kernel Linux, leggermente modificato da U-Boot.
• Ramdisk.gz
  Questo è il file gzippato che ospita il filesystem ext2, funge da ramdisk e da radice del sistema operativo del DNS-323.
  Esso contiene un filesystem cramfs con molte applicazioni di cui vengono creati dei symlink all'avvio.
• default.tar.gz
  Questo archivio contiene dei file di configurazione utilizzati nel ripristino del sistema ad impostazioni di fabbrica.

All'interno della ROM il firmware è diviso in cinque partizioni, qui espresse in offset di memoria:

• 0x00000000 -> 0x00010000 (65536 byte) : MTD1 (prima partizione di configurazione)
• 0x00010000 -> 0x00020000 (65536 byte) : MTD2 (partizione di configurazione di backup)
• 0x00020000 -> 0x001A0000 (1572864 byte) : Linux kernel
• 0x001A0000 -> 0x007D0000 (6488064 byte) : Ramdisk
• 0x007D0000 -> 0x00800000 (196608 byte) : U-Boot

Le dimensioni espresse in byte fanno riferimento alle dimensioni massime ospitabili dalle partizioni. Ad esempio, un kernel Linux (uImage) può avere una dimensione massima di 1572864 byte.

[MsZ]

Avvio del sistema

• U-Boot carica il kernel definito come uImage.
• Il kernel cerca /sbin/init, che è un symlink a BusyBox. init legge /etc/inittab.
• /etc/inittab ha un solo riferimento: /etc/rc.sh, che è lo script principale di avvio.
• /etc/rc.sh viene letto ed eseguito.
• Opzionalmente si possono mettere una serie di script che vengano invocati da rc.sh. Consiglio sempre di metterli alla fine, per sicurezza.

Lo script monta alcune partizioni, tra cui MTD1, da cui vengono copiati dei file di configurazione. C'è da dire che ogni volta che il DNS viene spento e/o riavviato i file di configurazione vengono presi dalle partizioni con le configurazioni di default, quindi se fate delle modifiche ai file nel DNS al prossimo avvio senza agire direttamente sul firmware, esse andranno perdute. A meno che non si usi un piccolo e semplice stratagemma per conservare le modifiche, che spiegherò più avanti.

Lo script rc.sh è lo script più importante, e per questo merita maggior attenzione e maggiore studio. Esso, tra le cose importanti, attiva la scheda di rete, carica i moduli nel kernel e avvia il webserver.
Però fa anche delle cose che non capisco.

• Attiva delle partizioni di swap che non dovrebbero esistere. Le crea nei dischi rigidi che ospita, e non dovrebbe farlo. Con una oculata gestione del sistema la swap non serve. E poi nei miei dischi non voglio partizioni di swap, ma solo i miei dati.
• Alcuni comandi, non so come mai, vengono eseguiti due volte. Ad esempio, all'inizio viene montato tutto, poi vengono subito smontati /proc e cramfs; poi viene rimontato tutto e viene smontato MTD1, per poi venire rimontato poco dopo.
• chmod 777 /dev/null, quando dovrebbe avere permessi 666; inoltre viene assegnato ad un utente che non è root.
• Una tabella di configurazione RAID viene scritta due volte, senza spiegazione apparente.

Ma la cosa più grave, come ho già accennato, è che lo script non fa cenno su possibili check dei dischi rigidi. Spulciando dmesg nel DNS si possono vedere diverse righe che recano la scritta Recovering journal nel caso di filesystem ext3, segno che non sono stati smontati correttamente all'arresto precedente.

Filesystem

Il DNS usa quattro filesystem principali.

• minix: è usato nelle partizioni MTD.
• ext2: il ramdisk lo usa, ed è il filesystem di default dei dischi.
• ext3: non è utilizzato per default sui dischi, sebbene il kernel lo supporti, e sia necessario connettersi tramite telnet e formattarli manualmente. La cosa è resa più difficile dal fatto che fun_plug è letto proprio dal primo disco, o dal RAID. Quindi bisogna abilitare il modulo USB ed utilizzare una chiavetta come unità temporanea per caricare utelnetd. Ma su questo torneremo più avanti.
• cifs: è il filesystem di rete, usato da Samba.

Cosa ho fatto fino adesso

Lo ho studiato. Ho fatto decine e decine di prove prima di flashare qualcosa, memore del fatto che se viene commesso un errore nel firmware la gravità dello stesso errore può andare da un malfunzionamento di utelnetd (rimediabile con un fun_plug) ad un brick bello e buono, che può essere causato da una miriade di fattori diversi. E' necessario pertanto porre estrema attenzione a quello che si fa.
Comunque esiste un metodo anche per rimediare in situazioni estreme, ma richiede una particolare predisposizione all'elettronica ed al modding hardware spinto, in quanto prevede l'aggiunta fisica di una porta seriale per delle modifiche dirette alla EEPROM.
Quindi il mio consiglio è: se non siete sicuri di quel che fate e volete usare il vostro DNS per altri scopi oltre a quello del mattone per fare case, non fatelo.

Ho studiato il cross-compiling. Cross-compiling è una tecnica che permette di generare codice oggetto per macchine di architettura differente da quella che ospita il compilatore. In altre parole, ora so (più o meno) creare su un i386 eseguibili che girano su un ARM.

Ho fatto due prove. La prima è stata una formalità: ho scomposto un firmware preesistente, l'ho ricomposto e l'ho flashato sul DNS per vedere se i tool di scomposizione/ricomposizione funzionavano, ed è stato un successo.
Poi ho preso il firmware, l'ho scomposto, ho aggiunto il supporto telnet, l'ho ricomposto e l'ho flashato. E ha funzionato anche questo.
Prima dovevo reggermi su una chiavetta USB che mi supportasse telnet, ora non più, e il procedimento di avvio è molto più snello e veloce, soprattutto per quanto riguarda la connessione via telnet.

I prossimi passi sono numerosi. Uno dei primi è ricompilare BusyBox, per almeno due motivi.
Il primo, ottimizzare il sistema e togliere symlink inutili a cui non corrisponde nessun tipo di applet in BusyBox.
Il secondo, togliere un codice fastidioso che BusyBox chiede in fase di accesso al DNS. L'ho identificato nei sorgenti e so come si toglie, ma BusyBox è l'applicazione principale e ricompilarlo significa un po' camminare alla cieca, quindi devo fare altri controlli e andare con i piedi di piombo.

Obiettivo

Il mio obiettivo non è solo quello di rendere il firmware stabile ed affidabile il più possibile (i signori della D-Link non hanno fatto un bel lavoro, c'è da dirlo), ma anche quello di renderlo appetibile sia dai casalinghi che dagli smanettoni, sia da coloro a cui basta loggarsi tramite webserver sia per coloro che vogliono connettersi tramite telnet e lavorare con la tastiera.
La prima volta che avevo messo le mani sul firmware ero rimasto decisamente deluso, per cui proverò a modificarlo in modo da renderlo almeno un po' più decente.

Poi c'è l'Obiettivo Supremo, che consiste nel dare al DNS un firmware 100% Free Software che dia tutte o quasi le funzionalità del firmware originale, ma sinceramente non so se riuscirò mai a farlo. Mi sfuggono alcune cose fondamentali, come l'update del firmware. So solo come si fa da webserver, probabilmente con un programma proprietario.

Link utili

Qui di seguito posto dei link utili da andare a leggere se volete approfondire le cose.
La guida non è finita qui, pubblicherò diverse cose, trucchi, stratagemmi, procedure utili per rendere il DNS un luogo più accogliente, e cercherò di documentare i miei progressi.

DNS323Wiki - wiki sul DNS, la mia fonte primaria di informazioni
Guida alla creazione della toolchain ARM per il DNS - il cross-compiling sull'ARM comincia da qui
Come costruire un firmware per il DNS - vengono usati due tool: mkimage (in U-Boot) e makeFirmware
Dovrebbe anche essere possibile installare una Debian su DNS-323, ma non l'ho mai provato

Link ai sorgenti della versione 1.05 del software GPL del DNS-323
Link alla GNU General Public License versione 2

Dimenticavo: tutto ciò che dirò e scriverò sarà riferito alla versione 1.05 del firmware, testata su hardware B1.

Per ottenere queste due informazioni (versione firmware e versione hardware) basta che rovesciate il vostro DNS-323 e ci guardate sotto: in basso a sinistra, come nell'esempio preso dalla wiki del DNS, vedete "H/W Ver.:" (Hardware versione) e "F/W Ver.:" (Firmware version).

[franz1789]

Mi stupisci sempre di più, sei il mio dio personale...

[MsZ]

Di seguito i primi tre firmware che ho costruito. Nell'archivio ZIP trovate il firmware ed un changelog. Per i sorgenti fate riferimento ai link in fondo al secondo post.

Per aggiornare il firmware non dovete fare altro che upparlo dal webserver del DNS.

1.05-custom-0.1

--- Version 0.1 : Start
(ADD) Added telnet support

[MsZ]

1.05-custom-0.2

--- Version 0.2 : Warmin' Up
(FIX) Removed several comments and echo lines from rc.sh
(REM) Removed non-existent symlink applets:
   -- cut
   -- mesg
   -- stty
   -- tty
   -- md5sum
   -- usleep

[MsZ]

1.05-custom-0.3

--- Version 0.3 : Let Us Hack BusyBox
(FIX) Direct login into sh: no more '5784468' required
(REM) Removed useless '/busybox' app
(REM) Removed 'modprobe' support from BusyBox
(REM) Removed redundant '/sbin/dumpleases' symlink
(REM) Removed non-existent symlink applet: getty
(REM) Removed 'tinylogin' app
(ADD) Added 'awk' support in BusyBox
(ADD) Added 'halt' support in BusyBox
(ADD) Added 'dd' support in BusyBox
(ADD) Added 'du' support in BusyBox
(ADD) Added 'adduser' support in BusyBox
(ADD) Added 'deluser' support in BusyBox
(ADD) Added 'addgroup' support in BusyBox
(ADD) Added 'delgroup' support in BusyBox
(ADD) Added 'passwd' support in BusyBox
(ADD) Added 'login' support in BusyBox
(CHG) BusyBox is now statically linked

[MsZ]

--- Nota tecnica 1 ---

Forse qualcuno smaliziato si chiederà "perchè aggiungere awk ad un sistema embedded?"
La risposta è in alcuni (molti) script di sistema e nel seguente costrutto ash/bash/sh:

Code: [Select]

expr substr <stringa> <partenza> <offset>
Ne ho visti diversi, ed ogni volta che ne ho visto uno, puntualmente mi è venuto il latte alle ginocchia. Essenzialmente è l'estrazione di un token in una stringa tramite il comando bash expr substr. La shell prende la stringa <stringa>, viaggia fino alla <partenza> (numero intero) ed estrae tutti i caratteri dalla <partenza> all' <offset>. Le cose che mi stanno antipatiche sono due.

• Vengono usate variabili supplementari all'interno degli script.
• Usando awk invece di expr substr si possono risparmiare da 3 righe in su in uno script.

Tre righe qua, tre righe là, gli script sono più piccoli, compatti e leggibili, e ovviamente debuggabili. awk si usa con un semplice pipe. L'unico contro è la struttura.

Sostituisco

Code: [Select]

START=9
OFFSET=5
STRING="stringa molto lunga e con spazi"

EXAMPLE=$(expr substr "$STRING" $START $OFFSET)

# in EXAMPLE c'è la parola "molto"
con

Code: [Select]

STRING="stringa molto lunga e con spazi"
EXAMPLE=$(echo $STRING | awk '{ print $2 }')
# il risultato è lo stesso, anche più semplice

come esempio generale. Ma molto spesso gli script del DNS fanno riferimento a output di programmi come ifconfig, e allora se uno deve andarsi a cercare il MAC Address di una periferica capite bene che un salto da così

Code: [Select]

MACAddrStart=28
MACAddrLength=17

MACAddrLine=$(ifconfig | grep egiga0)
MACAddr=$(expr substr "$MACAddrLine" $MACAddrStart $MACAddrLength)

a così

Code: [Select]

MACAddr=$(ifconfig | grep egiga0 | awk '{ print $5 }')

è un bel salto di qualità.

Ovviamente poi bisogna modificare gli script in modo che utilizzino awk, sennò è come soffiare controvento.

[MsZ]

--- Modifiche ---


Oltre al firmware sto lavorando ad uno script che riesca a manutenere un firmware per DNS.
Dovrebbe essere relativamente semplice, si parte dal firmware binario e alcuni tool esterni.

• makeFirmware

Per scaricarlo basta che facciate clic sul "bz2" minuscolo in alto:

makeFirmware / summary
summary | shortlog | changelog | tags | files | bz2

Questo per l'estrazione dei file principali dal firmware. Nell'archivio trovate un file che si chiama parseFirmware.py, scritto in Python (quindi dovrete avere Python installato), che tirerà fuori i file descritti sopra:

• uImage
• Ramdisk.gz
• default.tar.gz

Lo script che sto scrivendo dovrà rendere disponibile l'albero del firmware per l'utente, così strutturato:

Code: [Select]

<versione>
    |
    - root
    - image.cfs
    - default
    - firmware


• root è la radice del ramdisk, pre-estratta e resa disponibile
• image.cfs è il contenuto del filesystem cramfs: normalmente è di sola lettura, quindi bisogna montarlo, copiarne i contenuti in una directory separata e smontarlo; quindi fare le modifiche e creare un nuovo filesystem cram.
• default è la directory che contiene i file di configurazione di default del DNS-323, che vanno a sovrascrivere la configurazione all'avvio.
• firmware è la directory che ospita i componenti che poi andranno a creare il firmware modificato

Poi metto il file CHANGELOG che riporta tutti i cambiamenti fatti, dalla 0.1 in poi. In pratica, riporta tutte le differenze dal firmware originale, ordinate per versione.

• mkimage (U-Boot)

firmware, quando è completa, contiene i seguenti file:

• uImage: il kernel
• uRamdisk: la ramdisk con l'header di U-Boot
• default.tar.gz: l'archivio dei default da integrare
• custom.h: è un header reperibile dai sorgenti del firmware, nell'archivio goahead.tgz

L'archivio goahead.tgz è reso disponibile da D-Link tra i sorgenti del firmware. Tra le varie directory di goahead trovate custom.h nella directory LINUX (goahead/LINUX/custom.h), come spiegato qui.

mkimage è un tool di U-Boot. Il problema è che, per compilarlo servono:

• i sorgenti di U-Boot modificati da D-Link
• la toolchain per ARM

I sorgenti si trovano sempre sul sito della D-Link. La toolchain va costruita. E per costruire al toolchain servono i tool di compilazione. Per una spiegazione abbastanza esaustiva (seguendola ho realizzato la toolchain al primo tentativo) andate qui e seguite la costruzione della toolchain fino alla creazione di crosstools-env.sh, compreso. Se la compilazione non ha avuto errori la toolchain dovrebbe essere corretta. Per far leggere lo script di configurazione dell'ambiente cross basta questo:

Code: [Select]

source ccrosstools-env.sho

Code: [Select]

. crosstools-env.shLa variabile $CWD nello script deve corrispondere al percorso assoluto in cui avete messo la toolchain. Oppure potete modificare lo script in questo modo:

invece di

Code: [Select]

#CWD=$(pwd)
#CWD=/opt/dns323/fw103-0.3
CWD=/home/dns323_GPL/dns323_GPL/uclibc-toolchain-src-20040609/gcc-3.3.x
potete mettere

Code: [Select]

CWD=$1
e poi inserire il percorso in fase di lettura dell'ambiente:

Code: [Select]

./crosstools-env.sh /percorso/assoluto/per/toolchain

Poi potete provare con un programma dummy.

Ricordate due cose:

• Consiglio sempre di compilare qualsiasi cosa come utente normale (scegliete voi quale) e non come root. Poi, se necessario, installate i binari come root
• Se uscite dalla shell (con un exit o un logout) le variabili di ambiente lette da crosstools-env.sh andranno perdute, e dovrete rileggere lo script

Per compilare in fretta i sorgenti di U-Boot potete fare come ho fatto io.
Prendere l'archivio u-boot_1_7_3_5182.tgz, scompattatelo, entrate nella radice dei sorgenti e comandate queste due cose:

Code: [Select]

find . -name ".depend" -exec rm -rf {} \;
make
ovviamente dopo aver fatto leggere la configurazione della toolchain.

Alla fine della compilazione il binario mkimage sarà disponibile nella directory tools dalla radice dei sorgenti di U-Boot, compilato per i386, o per architettura locale.

mkimage è un programmino simpatico che aggiunge un header U-Boot a cose tipo kernel o ramdisk. La riga di comando usata per creare uRamdisk è la seguente:

Code: [Select]

mkimage -a 0x800000 -e 0x800000 -n 'boot ramdisk' -A arm -O linux -T ramdisk -C gzip -d <gzipped_ramdisk> uRamdiskcome descritto qui.
Il ramdisk però deve essere con filesystem ext2. E deve essere un file e non un blocco. Quindi:

Code: [Select]

dd if=/dev/zero of=Ramdisk bs=1k count=8k
mke2fs -m0 -F Ramdisk(-m0 l'ho aggiunto io. Serve a non riservare alcuno spazio per il superuser. Così vengono risparmiati alcuni KB di filesystem per cose più importanti.)
Il ramdisk è creato; bisogna poi trasferire tutti i dati dalla root spiegata sopra al ramdisk. Compreso image.cfs.

Questo bel filesystem cram non è leggibile se non avete il supporto cramfs nel kernel. Se volete sapere se l'avete basta che facciate

Code: [Select]

cat /proc/filesystems | grep cramfsSe non salta fuori niente potete provare a vedere se ne avete il modulo:

Code: [Select]

find /lib/modules/$(uname -r)/kernel/ -name "cramfs.ko"Se anche adesso non salta fuori niente lo dovete integrare. Ma non disperate, perchè non è necessario ricompilare tutto il kernel per averlo. Spiegherò più avanti come si fa, nella sezione dedicata a image.cfs.

Per concludere, non fidatevi di quello che scrive D-Link.

Many of the remaining D-LINK sources have not been configured for being cross-compiled. In fact, the “Readme.txt” file they supply with the GPL sources has instruction that are just plain wrong.

[MsZ]

COME MANTENERE LE MODIFICHE AL SISTEMA DOPO IL RIAVVIO

Voi direte "Beh, che ci vuole, basta modificare da webserver e salvere le modifiche".

E io dico "Si, ma come dico io si hanno due pregi."

• Il primo, così si possono modificare i file di sistema direttamente da telnet.
• Il secondo, non tutti i file di configurazione possono essere modificati (o salvati) da webserver.

Il procedimento è molto semplice una volta che si conosce la struttura della EEPROM del DNS, si sa che MTD1 e MTD2 sono caratterizzate rispettivamente da /dev/mtdblock0 e /dev/mtdblock1 e il filesystem di mtdblock0 e mtdblock1 è minix. E per finire sappiamo che i due filesystem minix vengono montati in /sys/mtd1 e /sys/mtd2.

A tutt'oggi non so se /dev/mtdblock1 (MTD2) venga usato per il reset di fabbrica. Per cui consiglio fortemente di testare direttamente in /etc le vostre modifiche prima di salvarle.

Per cui basta loggare tramite telnet e fare:

Code: [Select]

mount -t minix /dev/mtdblock0 /sys/mtd1
mount -t minix /dev/mtdblock1 /sys/mtd2
Fate le vostre modifiche in /etc e copiate (sostituendo) i file che vi interessano in /sys/mtd1 e /sys/mtd2, e al prossimo riavvio avrete la configurazione precedente attiva.

Se non siete sicuri di quel che fate, non fatelo. Usate il DNS responsabilmente.

Se volete ritornare ad una configurazione precedente potete sempre riflashare una versione precedente del firmware.

Se però volete modificare file come smb.default, mi dispiace, ma non potete. Purtroppo il firmware del DNS ha un'applicazione che si chiama smbcom. Viene chiamata da rc.sh e modifica proprio /etc/smb.default: è una specie di controllo del file, e internamente l'applicazione ha un'impostazione predefinita di smb.default che sovrascrive qualsiasi altra. Devo fare delle prove per vedere se smbcom è davvero necessario. Se non lo è, se ne va una volta per tutte.

Come tante altre che non mi vanno giù.

[MsZ]

Supporto telnet con autenticazione

Ora l'autenticazione telnet è disponibile. Potete loggare direttamente come root. La password di default è vuota.

Potete cambiare password quando volete con

Code: [Select]

passwd root
Immettete la password e confermate. Ma, come ho detto più su, se lasciate così e riavviate perderete la password. Quindi per salvare i cambiamenti dovete far riferimento al post precedente, Come mantenere le modifiche al sistema dopo il riavvio.

I file soggetti al cambiamento sono:

• /etc/shadow (se cambiate solo la password di un utente esistente);
• /etc/passwd (se aggiungete/togliete/modificate un utente);
• /etc/samba/smbpasswd (se cambiate una password di Samba).

Per cambiare la password di un utente esistente:

Code: [Select]

passwd <utente>
Per aggiungere un utente a /etc/passwd:

Code: [Select]

adduser <utente>
Per aggiungere/cambiare la password di un utente per Samba:

Code: [Select]

smbpasswd [-a] <utente>[-a] è tra quadre perchè è l'opzione di aggiunta di un utente al database di Samba. Se l'utente non esiste deve essere aggiunto con -a, e ne stabilite la password.

Valgono le regole che ho scritto sopra: /etc/passwd, /etc/shadow e /etc/samba/smbpasswd vanno in /sys/mtd1 e /sys/mtd2.

Da notare che la semplice struttura di /etc/passwd permette una modifica manuale, così come per /etc/group.

Allego il firmware custom 0.4.

Dimenticavo il changelog.

--- Version 0.4 : Let's Add Some Security
(ADD) Added authentication support (utelnetd + login + shadow)
(ADD) Added user 'root' in /etc/shadow: default password is null
(FIX) /etc/shadow now is 0666
(FIX) /etc/resolv.conf now is 0644
(FIX) /etc/fstab now is 0644
(FIX) /etc/hosts now is 0644
(FIX) /etc/raidtab now is 0644
(FIX) /etc/raidtab2web now is 0644
(FIX) /etc/pure-ftpd.conf now is 0644
(FIX) /etc/save_udhcpd_config now is 0644
(FIX) /etc/udhcpd.conf now is 0644
(FIX) /etc/udhcpd.conf.def now is 0644
(FIX) /dev/[pt]typ0 now are built-in
(CHG) user 'root' now has its home in /root
(REM) directory '/home/root' has been removed
(REM) directory '/lib/modules/2.6.6-arm1' has been removed
(FIX) now default smbpasswd is null

Al prossimo firmware aggiungo il supporto unità esterne USB. So già come fare, questione di poco.