[Modfs] Sviluppo pacchetti e porting su altri router

[pirus]

gnommo attendiamo i package per il wag320n, per ora io mi ritrovo solo adslinfo e basta come pacchetto aggiunto e non riesco a trovare quello per modificare i parametri dell'adsl! possibile?

[gnommo]

Originariamente inviato da pirus

gnommo attendiamo i package per il wag320n, per ora io mi ritrovo solo adslinfo e basta! possibile?

E mannaggia avessi il wag320n sarebbe questione di un attimo.

Mi servirebbero perlomeno dei tester, ma anche così però sarebbe abbastanza difficoltoso.

L'ideale sarebbe, tanto non mi serve fisicamente il wag320n, che qualcuno che magari non usa il wag320n come router primario, mi mettesse a disposizione il suo wag320n aprendomi le porte ssh e la 8081 e in modo da farmi finire tutti i pacchetti.

[gnicK79]

Originariamente inviato da gnommo

Perchè non usi un client svn?
Io uso il client a riga di comando nella mia slackware in VM

Perché non ho confidenza con svn senza gui, a riga di comando non ci ho mai lavorato; per quanto possano essere 2 min?iate spaziali (me ne rendo conto) devo/dovrò pur sempre documentami; avevo una certa urgenza e la cosa più veloce da fare in quel momento mi è parsa questa: buttare giù 2 righe di script.
Prima o poi installo subversion sulla mia debian e dedicherò un po' di tempo ai comandi principali e di base; adesso ci sono (ho) altre priorità.

--------------------------------------------------

Purtroppo () mi sono messo in testa di fare funzionare in rete una stampante a laser della Canon senza acquistare un print server; e ora nessuno è in grado di togliermi dalla testa questa cosa finché non arrivo ad una soluzione. Questo è male.
Poiché p910nd ha miseramente fallito, volevo provare con un servizio LPD/LPR dirottando lo spooler in USB.

E' una stampante Canon LBP basata su CAPT ed ero riuscito a condividerla in SAMBA da un MAC soltanto attraverso il protocollo lpd e installando il relativo servizio sul server (una macchina con Windows 7), per cui dovrei riuscire a riprodurre lo scenario sul router; busybox mi sembra abbia questi servizi.
Il file smb.conf è virtualmente sotto il mio controllo; la coincidenza ha voluto che quando eseguivo i lavori sul firmware del DGN2200 da rilasciare in Aprile, per fixare un bug scemo "ho scoperto" che potevo manipolare il file di configurazione di samba a mio piacimento qualora lo avessi desiderato e senza che il router me lo scombinasse.
Per cui, spooler permettendo, dovrei riuscirci.... e se Dio vuole.

Un tua considerazione, aiuto, suggerimento... LoL
Sono pazzo?

[gnommo]

Cioè fammi capire, da dmesg vedi
che il driver usblp aggancia correttamente la stampante?

Altrimenti devi partire dai driver, vedi un pò qui se ti può essere utile
http://www.boichat.ch/nicolas/lbp660/

quale è il modello preciso della stampante?

[gnicK79]

Canon LBP 3010

~ # dmesg | grep usblp0
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x04A9 pid 0x26DA
drivers/usb/class/usblp.c: usblp0: removed
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 5 if 0 alt 0 proto 2 vid 0x04A9 pid 0x26DA
drivers/usb/class/usblp.c: usblp0: nonzero read/write bulk status received: -71
drivers/usb/class/usblp.c: usblp0: error -71 reading from printer
drivers/usb/class/usblp.c: usblp0: nonzero read/write bulk status received: -71

Non stampa né in windows nè in mac, chiaramente con i drivers CAPT della stampante installati.

[gnommo]

Originariamente inviato da gnicK79

Canon LBP 3010

~ # dmesg | grep usblp0
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 4 if 0 alt 0 proto 2 vid 0x04A9 pid 0x26DA
drivers/usb/class/usblp.c: usblp0: removed
drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 5 if 0 alt 0 proto 2 vid 0x04A9 pid 0x26DA
drivers/usb/class/usblp.c: usblp0: nonzero read/write bulk status received: -71
drivers/usb/class/usblp.c: usblp0: error -71 reading from printer
drivers/usb/class/usblp.c: usblp0: nonzero read/write bulk status received: -71

appunto devi ripartire dai driver, sperando che ce ne siano di opensource funzionanti.

[gnicK79]

Originariamente inviato da gnommo

appunto devi ripartire dai driver, sperando che ce ne siano di opensource funzionanti.

Ho paura non sia una cosa semplice trovarne uno funzionante con questa soluzione; ne ho provati diversi, tra cui qualcuno gutenprint, ma nulla da fare e poi con Windows come si farebbe? Non funziona neanche da lì.
Boh!

[franjek]

Ciao a tutti,
ho da poco acquistato un dgn2000v3 per poi scoprire ahimè che non è supportato da modfs.
mi piacerebbe poter aggiungere almeno la wol e magari anche il server ssh.
non so se siano cose alla mia portata, ma se qualcuno ha voglia di aiutarmi un tentativo lo farei volentieri..

grazie in anticipo

[gnommo]

Originariamente inviato da franjek

Ciao a tutti,
ho da poco acquistato un dgn2000v3 per poi scoprire ahimè che non è supportato da modfs.
mi piacerebbe poter aggiungere almeno la wol e magari anche il server ssh.
non so se siano cose alla mia portata, ma se qualcuno ha voglia di aiutarmi un tentativo lo farei volentieri..

grazie in anticipo

punto primo , devi riuscire a loggarti come root in telnet
punto secondo devi rimontare il root filesystem in rw
da questo momento puoi copiare e modificare quello che vuoi all'interno del firmware
alla successivo reboot il firmware ritornerà readonly

[franjek]

Originariamente inviato da gnommo

punto primo , devi riuscire a loggarti come root in telnet
punto secondo devi rimontare il root filesystem in rw
da questo momento puoi copiare e modificare quello che vuoi all'interno del firmware
alla successivo reboot il firmware ritornerà readonly

ho abilitato il debug mode e sono entrato con telnet loggandomi come admin

ci sono le seguenti cartelle

lrwxrwxrwx 1 root root 9 Nov 5 09:19 bin -> usr/sbin/
drwxrwxrwx 6 root root 0 Nov 5 09:21 config
drwxr-xr-x 3 root root 0 Jan 1 1970 dev
lrwxrwxrwx 1 root root 8 Nov 5 09:19 etc -> /tmp/etc
drwxr-xr-x 2 root root 0 Jan 1 1970 home
--ws--S--t 1 root root 4 Nov 5 09:21 kernel_cksum
drwxr-xr-x 4 root root 0 Oct 28 2008 lib
drwxr-xr-x 3 root root 0 Jan 1 1970 mnt
dr-xr-xr-x 73 root root 0 Jan 1 1970 proc
lrwxrwxrwx 1 root root 9 Nov 5 09:19 sbin -> usr/sbin/
drwxr-xr-x 11 root root 0 Jan 1 1970 sys
drwxr-xr-x 8 root root 0 Apr 4 14:45 tmp
drwxr-xr-x 8 root root 0 Feb 2 2004 usr
lrwxrwxrwx 1 root root 8 Nov 5 09:19 var -> /tmp/var
-rw-r--r-- 1 root root 1314497 Nov 5 09:21 vmlinux.lz
lrwxrwxrwx 1 root root 8 Nov 5 09:19 www -> /tmp/www
drwxr-xr-x 8 root root 0 Sep 30 2011 www.eng


# mount
rootfs on / type rootfs (rw)
mtd:rootfs on / type jffs2 (ro,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
ramfs on /home type ramfs (rw,relatime)
ramfs on /tmp type ramfs (rw,relatime)
ramfs on /mnt type ramfs (rw,relatime)
ramfs on /dev type ramfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
mtd:factory on /config/factory type jffs2 (rw,relatime)
mtd:scnvram on /config/nvram type jffs2 (rw,relatime)
mtd:language on /config/language type jffs2 (rw,relatime)
mtd:xxx on /config/xxx type jffs2 (rw,relatime)

che differenza c'è tra:
rootfs on / type rootfs (rw)
e
mtd:rootfs on / type jffs2 (ro,relatime) ?

ho accesso in scrittura alle directory tmp,etc,home,mnt
/www in realtà punta a /www.eng e lì non ho permesso di scrittura

ho creato dei file di prova e dopo il reboot non c'erano più. quindi se modifico dei file, dopo un reboot tornano com'erano? o rischio cmq di friggerlo?

[gnommo]

Originariamente inviato da franjek

che differenza c'è tra:
rootfs on / type rootfs (rw)
e
mtd:rootfs on / type jffs2 (ro,relatime) ?

appunto che in tutte le dir sono rw
tranne quelle che provengono da mtd:rootfs
che sono ro
ovvio che le dir scrivibili sono mantenute in ram, quindi al riavvio non ci sono più.
L'obiettivo è quello di abilitare temporanemente mtd:rootfs in rw ed eseguire le modifiche, in realtà file e quant'altro li puoi anche inserire nelle altre dir che nel mount vedi che hanno jffs2 rw,
ma se vuoi modificare script di avvio devi andare a metterli in mtd:rootfs
Sarebbe anche interessante sapere cosa contengono
/config/factory
/config/xxx
/config/nvram

[franjek]

Originariamente inviato da gnommo

Sarebbe anche interessante sapere cosa contengono
/config/factory
/config/xxx
/config/nvram

# ls -l -R /config/
/config/:
drwxr-xr-x 4 root root 0 Jan 1 1970 factory
drwxr-xr-x 4 root root 0 Jan 1 1970 language
drwxr-xr-x 4 root root 0 Jan 1 1970 nvram
drwxr-xr-x 4 root root 0 Apr 4 15:38 xxx

/config/factory:
-rw-r--r-- 1 root root 540 Mar 31 17:21 pot
-rw-r--r-- 1 root root 0 Sep 30 2011 ready

/config/language:
-rw-r--r-- 1 root root 79578 Nov 5 09:21 CHS
-rw-r--r-- 1 root root 81164 Nov 5 09:21 DEU
-rw-r--r-- 1 root root 64096 Nov 5 09:21 ENU
-rw-r--r-- 1 root root 78860 Nov 5 09:21 PTB
-rw-r--r-- 1 root root 95836 Nov 5 09:21 RUS
-rw-r--r-- 1 root root 0 Sep 30 2011 ready

/config/nvram:
-rws--s--- 1 root root 15042 Apr 4 15:04 nvram
-rw-r--r-- 1 root root 0 Sep 30 2011 ready

/config/xxx:
-rw-r--r-- 1 root root 0 Sep 30 2011 ready


l'unico file con dentro della roba è nvram, se vuoi lo metto qui ma sono una quarantina di righe...

[franjek]

Originariamente inviato da gnommo

punto primo , devi riuscire a loggarti come root in telnet
punto secondo devi rimontare il root filesystem in rw
da questo momento puoi copiare e modificare quello che vuoi all'interno del firmware
alla successivo reboot il firmware ritornerà readonly

ok oggi finalmente ho potuto metterci un po' le mani.
ho formattato una pennina ext3, poi ho fatto un factory reset e abilitato il debug mode, mi sono loggato con telnet e ho rimontato la root in rw. ho copiato tutto il contenuto della root in una cartella nella pennina. appena posso faccio un archivio targz e lo metto a disposizione di chi è interessato a curiosarci un po'

[done75]

edit

[gnicK79]

Originariamente inviato da done75

se provo ad usare il comando che mi hai indicato ottengo un errore (anzi,più precisamente l'errore esce quando cerco di consultare l'help built-in...):

Ah già!
Sì quel bug verrà risolto nella 12.04 prevista tra qualche giorno.
Accedendo alla shell attraverso la busybox più vecchia del router si verifica questo problema. La maggior parte degli utenti usa il firmware moddato con la chiavetta usb+hub e di conseguenza abilita una shell differente e basata su una busybox assai più recente ...e... e non hanno questo bug.

Comunque, eccetto l'help, il resto dei comandi, se non erro, dovrebbe funzionare; ti incollo io qui l'help:

*** adsldrv ***

Usage command: 

Syntax: adsldrv [DRIVER] [OPTIONAL[DSL-MODE]]

        - DRIVER=[UNIQUE-KEY-VALUE]
                ADSL driver list:
                ------------------------------
                  (1)  A2pB025c1 = 025c1
                  (2)  A2pB026 = 026
                  (3)  A2pB030s = 030s
                  (4)  A2pB033g = 033g
                ------------------------------

        - (OPTIONAL) DSL-MODE=[AUTO(DEFAULT)=0|ADSL=1|ADSL2=2|ADSL2+=3]

Example: 'adsldrv 025c1 3' sets the A2pB025c1 driver in ADSL2+ mode

Il comando esegue un riavvio in automatico.
Per vedere se il driver è effettivamente cambiato dopo il riavvio, controlla la finestra di status dall'interfaccia del router, compare lì.

[gnicK79]

Nel frattempo...
Questo è il changelog definitivo e confermato per il firmware 12.04 DGN2200v1

http://pastebin.com/raw.php?i=PVRgQ8iG

Il rilascio è previsto (ma non confermato) per la prima metà della prossima settimana; e sarà l'ultima release basata sulla 1.0.0.36.

[gnicK79]

Introduzione.

La gestione delle condivisioni di più periferiche USB da parte del DGN2200 attraverso l'utilizzo di un HUB è molto approssimativa a bacata.
Per evitare di perdere la pazienza, è purtroppo necessario assecondare le ridicole convenzioni dettate dal codice chiuso nei cgi dentro il web server http.

Si prenda in considerazione il seguente schema.

Modello di mappatura del montaggio USB con eventuali partizioni addizionali a seguito:

---SDA---SDB---SDC---SDD---SD(n)---
    |     |     |     |
    |     |     |     |__SDD1--SDD2--SDD(n)--
    |     |     |
    |     |     |__SDC1--SDC2--SDC(n)--
    |     |
    |     |__SDB1--SDB2--SDB(n)--
    |
    |__SDA1--SDA2--SDA(n)--

L'assegnazione dell'identificativo di una periferica/partizione avviene in maniera ordinata; all'inserimento di una chiavetta usb, al momento di essere montata, questa riceverà il primo identificativo disponibile rispetto allo schema illustrato.
Nel caso in cui i dispositivi venissero inseriti gradualmente nell'HUB, la mappatura della catena corrisponderà esattamente all'ordine in cui avrete inserito i dispositivi.
Nel caso in cui tutti, o alcuni, dispositivi fossero già inseriti, la catena verrà mappata secondo la velocità di rilevamento delle periferiche da parte dell'hardware.
In tutti i casi, la mappatura dei dispositivi è facilmente decifrabile e individuabile semplicemente dando un'occhiata all'elenco delle periferiche da ReadyShare o, meglio e alternativamente, da telnet osservando l'output del comando "cat /proc/partitions".

Ad ogni periferica montata verrà assegnata una lettera di unità alla stregua di uno schema sequenziale equivalente a quello degli identificativi delle periferiche montate: U: , T: , S: .. etc..
Tutte le personalizzazioni di una risorsa condivisa effettuate dall'interfaccia verranno memorizzate nella sezione delle variabili della nvram.
Da telnet filtrate con "param show usb_info_dev" per rendervi conto della situazione; ogni entry corrisponde a ciascuna delle partizioni montate e contiene, eventualmente, anche i settaggi di più cartelle condivise di una stessa partizione, nel caso ne aveste, di proposito, mappate più di una.

Quando inserite una chiavetta USB, il criterio di ricerca delle impostazioni salvate nella nvram avviene attraverso la decifrazione del nome del dispositivo e la dimensione dello stesso. Es: Generic USB Storage, 1024 MB.
Se al dispositivo collegato viene assegnata una lettera di unità differente da quella memorizzata nella entry corrispondente in nvram, in maniera del tutto trasparente verrà aggiornata la lettera di unità residente in nvram e senza che le impostazioni vadano perdute.


Il problema della rimozione dei dispositivi.

Premesso che fisicamente parlando sia una cosa ovviamente possibile e fattibile, non potete logicamente decidere di rimuovere le periferiche USB a casaccio a causa di una cattiva gestione da parte del web server.
E' possibile rimuovere correttamente uno o più dispositivi nell'ordine inverso in cui essi risultano mappati e cioè a mò di una struttura LIFO… come uno stack in pratica.
Prendendo come riferimento lo schema sopra illustrato, se avessi, ad esempio, l'intenzione di rimuovere, e quindi smontare, la periferica corrispondente a SDB non potrei farlo senza aver rimosso, o decidere di rimuovere, anche SDC, SDD e SD(n).
La rimozione di SDA implicherebbe, invece, la rimozione di tutti i dispositivi; insomma, tutto ciò che sta a valle della periferica prescelta da rimuovere deve essere anch'esso rimosso.
In altre parole, non potete rimuovere periferiche lasciando buchi o spezzando la catena di mappatura, pena la perdita (non proprio) delle personalizzazioni effettuate in precedenza dei dispositivi rimasti connessi.
Da telnet con "param show usb_info_dev" vi renderete conto dei casini; le vecchie impostazioni sono ancora lì ma come potete constatare non vengono più considerate a causa della creazione di nuove entries.
Potreste, a manina, ripristinare i settaggi resettando le variabili con i valori giusti, ma vi assicuro è un lavoraccio frustrante; prima di tutto dovreste rimuovere tutti i dispositivi dall'HUB (se avete Modfs attivo dovrete per forza eseguire un riavvio per fare ciò a causa di ragioni che conoscete) per consentire di resettare la mappatura dei dispositivi e solo dopo, poi apportare le modifiche, poiché se ripulite le variabili prima e con la pila ancora corrotta, le modifiche non avranno l'effetto sperato e al primo recheck dell'HUB vi ritroverete di nuovo con le impostazioni sballate in nvram. Molto meglio, invece, prendere atto di questo contesto sciagurato e cercare di rispettarlo, altrimenti fate un po' come vi pare… e amen.

A fronte di questo ragionamento e visto che non è possibile la rimozione, è assolutamente consigliato inserire Modfs nel dispositivo più veloce a disposizione in modo che vada a finire sempre in fondo alla pila dei dispositivi mappati… cioè in SDA; non importa in quale partizione qualora ce ne fossero più di una. Nel caso in cui decidiate, per qualche ragione, di attivare Modfs in un secondo momento manualmente da telnet, o, sempre automaticamente attraverso un post-inserimento della chiavetta entro il tempo utile al detecting a seguito di un reboot del router, assicuratevi che non ci siano altre periferiche di memorizzazione collegate… proprio per consentire il mapping di assegnare alla periferica l'id SDA.

Stessa sorte tocca alla gestione dei dispositivi autorizzati che risponde alla medesima e rigida logica già appresa.
Non potete autorizzare un dispositivo senza che tutti gli altri a monte non lo siano di già, o, se preferite, non potete escluderne uno senza aver escluso anche tutti gli altri al seguito e a valle di codesto.

Vige e persiste ancora la presente convenzione dei dispositivi anche nel caso abbiate forzato il mounting da shell di partizioni non supportate ufficialmente da ReadyShare, come ad esempio Ext3; infatti, anche se ReadyShare non monta e né condivide la periferica, al dispositivo viene comunque assegnato un identificativo all'interno della catena di mappatura. Questo costringe l'utente a considerare il dispositivo qualora si debba procedere alla rimozione delle periferiche.

Una raccomandazione quando si forza, manualmente, il mounting delle periferiche…
Allo scopo di evitare conflitti ancora con il servizio ReadyShare è strettamente indicato appoggiarsi ai nodi virtuali (loop) quando si procede al mounting. Non è consigliato montare direttamente una periferica non supportata da ReadyShare, poiché in questo caso l'identificativo della partizione andrebbe a finire nell'elenco("mount") delle partizioni montate. Con "loop" si aggira questo inconveniente. Come esempio, la partizione di Modfs stessa, fra l'altro e a partire dalla versione 12.04 del firmware, è montata in conformità di questa indicazione proprio per realizzare l'occultamento da ReadyShare di una partizione montata 2 volte.

Se il problema risiederebbe nei cgi (come io immagino e sospetto) built-in col demone http, nemmeno la ricompilazione del sorgente del firmware risolverebbe la cosa, poiché il codice sorgente degli cgi non è disponibile, è closed; per cui non sarebbe possibile procedere nella rivisitazione dell'algoritmo.

E' da ricordare, infine, che questo comportamento difettoso non è imputabile al fatto che Modfs sia in esecuzione, né alla ragione che abbiate a bordo del vostro router il firmware moddato.

---------------------------------------------
con rif.: DGN2200v1 fw 1.0.0.36_7.0.36

[gnicK79]

Changelog:

DGN2200v1 12.04

-- Fixes --

• Usabilità Interfaccia generale
  - Diverse correzioni in ReadyShare fra cui:
  • Risolto un problema nella finestra di rimozione multipla dei dispositivi (All browsers).
  • Risolto un problema nell'esploratore delle cartelle che portava al crash del servizio httpd predefinito del router (Chrome, Firefox, Opera, Safari, …).
  • Corretto un bug alla selezione di una cartella dall'esploratore (Chrome, Firefox, Opera, Safari, …).
  • Corretto un bug critico che provocava il crash del servizio httpd durante la fase di editing di una risorsa condivisa (All browsers).
    ... etc. ...
  - Corretto un problema di persistenza delle impostazioni temporanee fra le opzioni di sicurezza e di crittografia nella sezione wireless.
  - Rimossi diversi refresh di pagina inutili e fastidiosi del menu di selezione.
• passwd, adesso, riflette istantaneamente le modifiche apportate alla password di amministrazione

-- Changed & Improved --

• Meccanismo di occultamento e isolamento in ReadyShare
  - Non accadrà più di vedere accidentalmente fra le risorse condivise duplicati della partizione/periferica ove risiede Modfs.
  • Eliminati tutti gli spiacevoli imprevisti derivati da questo comportamento, quali perdita impostazioni ReadyShare, dirty & enlarged NVRAM.
• adsldrv v1.5 (selezione driver ADSL)
  - Mantenimento modulazione ADSL preesistente.
  • Rimosso il comportamento per il quale, se non veniva specificato nessun parametro per la modulazione ADSL, a default veniva impostata la modalità auto.
  - Riavvio router opzionale e a richiesta.
  - Cambiamenti e correzioni minori.

-- New --

• Aggiunta la funzionalità "Assisted mode" nella finestra di rimozione multipla dei dispositivi (per maggiori info fare riferimento alla "Guida di sopravvivenza alla condivisione in ReadyShare")
• modversion command (mostra la versione corrente del firmware moddato)

Download

(versione precedente)


IMPORTANTE: Attenzione! Non è consigliato, e nemmeno supportato, l'utilizzo di Modfs in USB senza l'utilizzo di un hub. Ciò vale anche a fronte del fatto che non si abbia la necessità di usare simultaneamente più periferiche usb, la condivisione della stampante e funzionalità come miniDLNA. Il motivo risiede nel fatto che il DGN2200, nel momento in cui si effettuano alcune ed opportune modifiche dall'interfaccia proprietaria, resetta il bus USB con la spiacevole conseguenza di ritrovarsi interrotti i riferimenti all'immagine montata di Modfs e con ripercussioni in negativo tra i processi correntemente in memoria, le condivisioni ReadyShare e la stabilità del router stesso; a seguito di un'indagine si è osservato che il reset del bus, fortunatamente, non avviene se alla porta USB viene collegato un hub e i dispositivi a quest'ultimo. Sono esentati da questa limitazione, tutte quelle funzionalità di Modfs che, per avere effetto, non necessitano l'accesso alla memoria USB.

[strassada]

gnicK79: se non ci fossi, bisognerebbe invertarti (o cambiare router)
grazie del tempo e impegno che ci metti su questo router.

[Herbert]

Originariamente inviato da strassada

gnicK79: se non ci fossi, bisognerebbe invertarti (o cambiare router)
grazie del tempo e impegno che ci metti su questo router.

condivido in pieno e non posso far altro che ringraziarti!