[Modfs] Sviluppo pacchetti e porting su altri router

[Parnas72]

Originariamente inviato da gnicK79

Da dove batti il reboot da telnet? Non vale da lì.

No, il router reboota da solo quando modifico le impostazioni DSL da VC a LLC.

Senti qua. Che ti devo dire c'hai il DGN2200 che ti riesce a chiudere le connessioni.... è un modello SMART

Allora, ho appena fatto la seguente prova...
- messo il router in PPPoE/LLC
- rebootato
- atteso che agganciasse portante e prendesse IP
- disconnesso
- attesso che da interfaccia si vedesse indirizzo IP = 0.0.0.0
- riconnesso
- connesso in telnet e monitorato i processi, e di pppd.original ce ne era in esecuzione solo uno, non due.

Con questo non voglio dire che non ci sia il problema che tu dici, ma la cosa non è affatto sistematica... io mi sono riconnesso e navigo.

Io sono partito per dare la colpa alla DSLAM per assecondarvi.

Hai dato la colpa al dslam per assecondare me ?

Ricordatelo questo.... ed è facile tu abbia la stessa DSLAM mia

Non credo proprio, visto che tu hai DSLAM Broadcom mentre io Infineon.

[strassada]

c'è spazio per aggiungere un altro dsp broadcom? sarebbe la versione A2pB033g.

comunque nemmeno io mi spego perchè a lui crasha così tante volte e in brevissimo tempo, e a noi no (ora sono a 28 giorni filati sempre in pppoe e nessun problema, precedentemente ero arrivato ad oltre 50 giorni, sempre stesso ip e portante).

sarebbe da verificare anche la vulnerabilità WPS e magari pensare a come bypassarla, levando il wps o se basta killare alcuni processi da telnet/modf come molti di noi fanno.

[gnicK79]

Originariamente inviato da Parnas72

No, il router reboota da solo quando modifico le impostazioni DSL da VC a LLC.

Allora, ho appena fatto la seguente prova...
- messo il router in PPPoE/LLC
- rebootato
- atteso che agganciasse portante e prendesse IP
- disconnesso
- attesso che da interfaccia si vedesse indirizzo IP = 0.0.0.0
- riconnesso
- connesso in telnet e monitorato i processi, e di pppd.original ce ne era in esecuzione solo uno, non due.

Con questo non voglio dire che non ci sia il problema che tu dici, ma la cosa non è affatto sistematica... io mi sono riconnesso e navigo.

Hai dato la colpa al dslam per assecondare me ?

Non credo proprio, visto che tu hai DSLAM Broadcom mentre io Infineon.

Io so solo che qui il filrmware moddato in PPPoE non me l'ha mai fatta passare liscia. Non so perché ma è incapace di chiudere le connessioni aperte in PPPoE. In PPPoA è tutta un'altra storia.
Domanda:
Perché il firmware originale ce la fa SEMPRE, e quello moddato non ce la fa MAI?
Non ho nemmeno bisogno di fare statistiche perché gli esiti non hanno mai dato risultati differenti.
Perché ho dovuto riportare il nome del demone ppp come quello originale per riavere le cose nella norma?

Io posso dire che il riavvio da interfaccia ora funziona ogni volta che lo chiedi, compreso il reset di fabbrica, e anche se fai un wizard non crasha più.
Tutto perché adesso è capace di chiudere le connessioni PPPoE che prima non poteva. Provando a passare da un protocollo ad un altro (per inciso una cosa che prima potevo fare solo nei sogni e solo col fw originale senza incorrere in un crash), le connessioni vengono chiuse correttamente.... vado a controllare da telnet e infatti ne ho sempre solo 1 di connessione fra i processi.

Com'è possibile sta storia che cambia solo con una stupida rinomina?

Domanda? Siamo sicuri che i tuoi riavvi non siano dei crash?
Perché il crash sfocia sempre in un riavvio dell'apparechio poi.
Cioè se io non sapessi, ad esempio, che il wizard non prevede a priori un normale riavvio, non saprei distinguere un normale reboot da un crash. Cioè visibilmente non puoi capirlo... a meno che non c'è un log che ne tiene traccia... e a meno che tu non sappia da prima che quella procedura non deve crashare perché sai che è così.

Ve lo farei vedere volentieri di persona che qui in PPPoE com'era prima era una piaga se intendevi cambiare qualcosa. Io che posso dirvi!!
Potete anche non credermi.
Sarò sfigato vabbè e con me qualche altro povero cristo, che altro posso dire!!!

Originariamente inviato da strassada

c'è spazio per aggiungere un altro dsp broadcom? sarebbe la versione A2pB033g.

comunque nemmeno io mi spego perchè a lui crasha così tante volte e in brevissimo tempo, e a noi no (ora sono a 28 giorni filati sempre in pppoe e nessun problema, precedentemente ero arrivato ad oltre 50 giorni, sempre stesso ip e portante).

sarebbe da verificare anche la vulnerabilità WPS e magari pensare a come bypassarla, levando il wps o se basta killare alcuni processi da telnet/modf come molti di noi fanno.

ssstrada se il router non lo tocco non crasha e non freeza manco a me.
I problemi nascono se devo configurare qualcosa.
Anche a me in PPPoE è durato tipo 4 giorni di operatività e tutto era in ottimo stato. il problema non è questo.
Il problema era che se andavi e modificare cose e parametri per il quale il router richiedeva in maniera legittima di buttare giù la connessione ppp0 preesistente e reinizializzarne una aggiornata con in nuovi parametri, ebbene non ce la faceva... perché non riusciva a chiuderla a meno che non andavi tu da telnet a killarla brutalmente. A questo punto anche se l'avevi killata ti ritrovavi l'interfaccia grafica che si era ormai bloccata... per cui non potevi fare altro che battere un bel reboot da telnet e arrivederci. E dipende cosa facevi, ti puniva direttamente co un bel crash e buonanotte....

Cioè, ma sto coso così deve funzionare? Ad minchiam?
Abbiate pazienza!!! Ma col fw originale la situazione è sensibilmente differente per chi lo conosce.
Poi sarà che Modfs con me non vuole avere niente a che fare.
Vedrai!!!

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

Con la squash adesso siamo a:

rootfs offset : 0xbfc10100 -- Length: 5480448

[EDIT]
Se la trovi, la inseriamo e si prova.
Si vede come va e se soprattutto migliorano ancora le capacità di aggancio delle portante... Comunque per quanto ne ho potuto capire per la DSLAM è importante anche il modulo adsldd.ko e non solo il driver.
[/EDIT]

[gnicK79]

A proposito di driver ADSL.

Se qualcuno fosse interessato alla cosa, potrebbe inserire un riquadro, un box, in modfs per permettere la selezione da interfaccia e con effetto immediato, e senza il reboot, del driver adsl.
Penso non dovrebbe essere per niente difficile realizzarlo.
Serivirebbe tipo una combobox, oppure 'n' radio buttons (che forse è meglio) quanti sono i driver disponibili.... e poi eventualmente richiamare tramite ajax il web server in php per delegare la faccenda ad uno script bash abbastanza elementare, per la rigenerazione di soli due link simbolici, l'impostazione di una variabile globale per mantenere le impostazioni ed infine un retrain con 'adslctl start' per riqualificare la linea a dovere con il nuovo driver.

Magari qualcuno che ha già confidenza con l'SVN.

[strassada]

stando a quelli di bitswitcher, il firmware col driver aggiornato è di uno Zhone 1511-A1. avevano messo online sia il file .bin adsl estratto, che il firmware .img, ma i link ad Hotfile sono spariti. http://sourceforge.net/projects/bits...7/index/page/4

prova a prendere il firmware (3 MByte) da qui:
http://www.mediafire.com/?2tgy6759jzxq91h

[gnicK79]

Originariamente inviato da strassada

stando a quelli di bitswitcher, il firmware col driver aggiornato è di uno Zhone 1511-A1. avevano messo online sia il file .bin adsl estratto, che il firmware .img, ma i link ad Hotfile sono spariti. http://sourceforge.net/projects/bits...7/index/page/4

prova a prendere il firmware (3 MByte) da qui:
http://www.mediafire.com/?2tgy6759jzxq91h

http://www.mediafire.com/?z3pp8qmgncpcml5 (link non più disponibile - file rimosso dall'autore)

Il driver si allinea, il punto è che io ho una 7 mega per cui no ho nulla da chiedere al modem già con il drv di default, poiché aggancio sempre il massimo possibile.
Testatene voi la solidità e le capacità se avete un abbonamento a 20 mega.
Io non posso essere attendibile per questo genere di test.

Per cambiare i fw adsl:
da telnet battere /usr/sbin/adsldrv.sh 025c1|026|030s|033g (a seconda della scelta)
poi digitare reboot ( temporaneo ...... devo sistemare lo script e se qualcuno mi aiuta facciamo prima

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


.........) a tal proposito.... Domandaa!!!???

Nel caso avessi bisogno di reinizializzare il driver adsl senza riavviare, la semplice riqualificazione della linea non è sufficiente.
E' necessario stoppare prima il driver:

adslctl stop
e poi reinizializzarlo e tirare su la connessione
adslctl start --up

E fin qui ci siamo.... il driver si allinea correttamente e si collega senza problemi. Il punto è che ora bisogna smuovere la porta Internet poiché il router non acquisisce un IP... una volta fatto adsl stop... cioè manca qualcosa da digitare...
Qualcuno lo sa?
Forse qualcosa in pppd? Ma cosa.
La connessione pppd vedo è ancora fra i processi attivi però non c'è IP e la spia del web è rossa mentre la portante è agganciata correttamente.

[gnommo]

quindi basta solo chiamare
/usr/sbin/adsldrv.sh 025c1|026|030s|033g
per cambiare il driver?
Posso aggiungere al pacchetto adsl io la modifica, visto che l'ho aggiornato per aggiungere il supporto per il wag320n, poi se parnas vuole procedere lui

Per quanto riguarda il comando sul 3500 c'è un comando per stoppare o lanciare la connessione
rc wan start|stop
questo si incarica di installare/disinstallare la periferica ethernet nas1 (in caso di pppoe),di killare/avviare pppd, settare le regole iptables etc...
Il vostro corrispondente di rc non è wl ?

[gnicK79]

Originariamente inviato da gnommo

Per quanto riguarda il comando sul 3500 c'è un comando per stoppare o lanciare la connessione
rc wan start|stop
questo si incarica di installare/disinstallare la periferica ethernet nas1 (in caso di pppoe),di killare/avviare pppd, settare le regole iptables etc...
Il vostro corrispondente di rc non è wl ?

wl è per la periferica wireless. Quello non ci serve, è a posto.
lo stop del driver adsl qui provoca un down del servizio legato alla porta WAN.
Tirarlo su per me non è semplice. Ci vuole troppo tempo a cercare di capire come si fa dal sorgente. Non so se ne valga la pena. O lo si sa oppure è un casino.
In /usr/sbin esiste un eseguibile chiamato "wandetect" che avvia una procedura che killa tutti i processi relativi alla WAN.
Per riattivare la WAN basta che vai nella pagina del protocollo e fai applica e ripristina la WAN.
Al limte potevo adottare una soluzione di ripiego attraverso l'uso delle curl, anche se mi fanno schifo. Invece neanche quello.
Il punto è che "adsl stop" proprio mette ko un qualcosa che nemmeno da interfaccia c'è modo di ripristinare (tipo se vai in wan setup o nella pagina del protocollo). Persino wandetect va in tilt, cioè entra in loop infinito perché non trova più il servizio associato.
Ifconfig mi dice che il device ppp0 è up ed ha addirittura un IP verso l'esterno, ma questo è assolutamente falso..
Per cui nello script che sto rifacendo eseguirò un reboot...
Peccato perché il driver adsl veniva reiniziallizzato correttamente e riagganciava senza problemi... ma senza connettività internet ce ne facciamo poco.
Comuque tipo per modificare 2 parametri (vci vpi o mux) dell'adsl nemmeno dall'interfaccia tentano di tirare su la nuova connessione e tutto quello che c'è dopo senza eseguire un reboot... modificano le variabili reboot e ciao

Originariamente inviato da gnommo

quindi basta solo chiamare
/usr/sbin/adsldrv.sh 025c1|026|030s|033g
per cambiare il driver?
Posso aggiungere al pacchetto adsl io la modifica, visto che l'ho aggiornato per aggiungere il supporto per il wag320n, poi se parnas vuole procedere lui

In /etc/adsl esiste un file di testo chiamato "adsldrv" che contiene la lista dei driver disponibili e la riga di comando opportuna da passare qualora qualcuno volesse costruirne il componente in modfs.

Il pattern di codesto file è questo:

driver_label=param1 param2 param(n)

file che tra l'altro utilizzo io nella generazione dinamica della lista dell'help nello script adsldrv.sh.

Per cui in PHP lato server dovreste accedere a questo file e costruire, con un loop, il numero di radio buttons o selezioni se si opta per una combobox con le key associate.
Se il file è inesistente o vuoto potreste ritornare una cosa tipo "componnte o plug-in non disponibile bla bla", diversamente costruire l'interfaccia con i controlli e un bottone applica.

Vi avverto però quando si fa click su applica e il server web cede il controllo allo script a fine procedura parte il reboot automatico .
Non chiedo all'utente di riavviare.

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

DGN2200

La gestione delle risorse condivise in samba con modfs funziona male.

Se inserisco un'altra chiavetta usb nell'hub salta sitematicamente l'interfaccia web di modfs e viene creata una seconda unità duplicata della partizione di modfs tra le risorse condivise.
In nvram vengono create col tempo troppe unità incrementali.

Forse sarebbe il caso di avvertire il router di ignorare la partizione di modfs e non tentare di condividerla e possibilmente evitare di montarla una seconda volta:

/dev/sda1 on /tmp/mnt/usb0/part1 type vfat (rw,fmask=0000,dmask=0000,codepage=cp437,iocharset=iso8859-1)
/dev/sda2 on /tmp/mnt/usb0/part2 type vfat (rw,fmask=0000,dmask=0000,codepage=cp437,iocharset=iso8859-1)
/dev/sda2 on /tmp/mod/dev type vfat (rw,fmask=0000,dmask=0000,codepage=cp437,iocharset=iso8859-1)
/dev/loop0 on /tmp/mod/modfs type ext3 (rw,data=ordered)

[EDIT]
[/EDIT]

Qualcuno ha già indagato sulla faccenda?

[gnommo]

si cionci indagò a suo tempo, non so le conclusioni, ma l'ultima volta che si è sentito stava lavorando ad una rinnovata gestione dei dispositivi usb.
Certo che questo 2200 vi costringe ad un lavoraccio, che quasi quasi verrebbe voglia fare tutto daccapo,
io invece con il 3500 non solo ho la vita facile... ma di più

[gnicK79]

Originariamente inviato da gnommo

si cionci indagò a suo tempo, non so le conclusioni, ma l'ultima volta che si è sentito stava lavorando ad una rinnovata gestione dei dispositivi usb.
Certo che questo 2200 vi costringe ad un lavoraccio, che quasi quasi verrebbe voglia fare tutto daccapo,
io invece con il 3500 non solo ho la vita facile... ma di più

nono, è completamente fuori discussione che io metta mano al sorgente per
ridisegnare il modo in cui il router gestisce le periferiche usb.
Io posso indagare sulla questione e vedere di correggere al massimo tramite un demone che tira su una shell asincrona che con un impatto ragionevole sull'uso della CPU va ed eseguire il fix necessario e in background e quasi in tempo reale.
Una pezza, e nemmeno la migliore, più che una soluzione vera e propria... proprio perché per quella ho paura si debba ricompilare qualche libreria ed io sono in un periodo che mi scoccio un casino andare sul C/C++.
Mettici pure che non saprei dove andare a guardare, opto per il demone.
Non conosco queste architetture hw.

Per il discorso dell'interfaccia che si rende non disponibile sembra che sia stato fatto fuori soltanto il demone http di modfs, tutto il resto è up e la stessa immagine di modfs rimane montata correttamente.
Per cui basterà risollevare il pacco.. ehm il pachake httpd ghghgh.

Ho notato che l'httpd è molto soggetto a questi crash.
Era Parnas72, se non sbaglio, che si era adoperato a buttare giù 2 righe di codice e metterlo nello scheduler.
Più che un pezzo di codice opzionale, a questo punto sarebbe meglio che divenisse parte integrante di modfs. Tanto l'httpd crasha (o forse viene ucciso)... se ti metti a configurare il router... non c'è via di scampo.
Eventualmente se trovo il modo di correggere l'odioso problema delle periferiche usb con samba, potrei pensare di inserirlo nel demone stesso... che forse sarebbe la cosa migliore.
Boh!

[gnicK79]

Stavo pensando se si potesse far qualcosa con fstab!!!

[EDIT]
Dentro c'è questo:

proc /proc proc defaults 0 0
/dev/sda1 /mnt vfat noauto 0 0
tmpfs /mnt tmpfs size=16k 0 0

Sinceramente non son sicuro se con l'hotplug sta roba venga considerata
[/EDIT]

[gnicK79]

DGN2200

Il problema delle unità usb duplicate non è direttamente riconducibile a modfs, ma alla gestione del mounter da parte del router nelle partizioni.
Non possiamo parlare nemmeno di bug, poiché non è prevista la possibilità o la funzionalità di montare 2 volte la medesima partizione.
Questa è una nostra esigenza, cioè di modfs.

Però esiste un workaround al problema.
Il router gestisce male le unità solo quando si montano più di una volta le partizioni successive alla prima.

Per cui il trucco sta di mettere modfs SEMPRE nella prima partizione, e lasciare i dati personali nelle altre... per le quali non abbiamo bisogno di montarle una seconda volta, basterà lasciarle montare al router.

Qualora si mettesse modfs in un'altra partizione della stessa periferica, che non sia la prima, il router farà un po' di macelli in nvram e nell'assegnazione delle lettere di unità con la conseguente perdità e reset delle impostazioni di condivisione per le unità condivise.

[EDIT]
Confermo il comportamento e aggiungo che modfs non solo deve risiedere nella prima partizione disponibile della chiavetta, ma anche nella prima chiavetta rilevata dal router cioè /dev/sda1 in sostanza.
[/EDIT]

[gnommo]

Ancora una volta il dgn3500 usa una sistema diverso, che semplifica la vita.
Non usa automount, ma un hotplug custom, nel senso che il driver scsi
all'inserimento o disinserimento di un drive chiama direttamente lo script:
/etc/usb/usb_m.sh

#!/bin/sh

echo ">> $0 $1 $2 $3" > /dev/console

while [ -f "/tmp/keep_usb_m" ]; do
        echo "Wait USB $1" > /tmp/wait_usb_m_$1
        /usr/sbin/sleep 1
done

if [ -f /tmp/wait_usb_m_$1 ]; then
        rm /tmp/wait_usb_m_$1
fi

echo "keep" > /tmp/keep_usb_m

if [ ! -d /tmp/sd ]; then
mkdir /tmp/sd
fi

echo $2 > /tmp/sd/$1
echo $3 >> /tmp/sd/$1


/usr/sbin/mknod_sd $1

/usr/sbin/rc sd mount $1

rm /tmp/keep_usb_m

ed /etc/usb/usb_u.sh al disinserimento:

#!/bin/sh

echo ">> $0 $1" > /dev/console

while [ -f "/tmp/keep_usb_u" ]; do
	echo "Wait USB $1" > /tmp/wait_usb_u_$1
	/usr/sbin/sleep 1
done

if [ -f /tmp/wait_usb_u_$1 ]; then
	rm /tmp/wait_usb_u_$1
fi

echo "keep" > /tmp/keep_usb_u
rm /tmp/sd/$1
/usr/sbin/rc sd umount $1
rm /tmp/keep_usb_u

potete immaginare che mi è bastato modificare questi script per ottenere un comportamento impeccabile di modfs, incluso il caricamento automatico di modfs all'inserimento di un drive
Anche sul dgn2200v3 è stato adottato questo metodo
In realtà quindi si potrebbe patchare il file drivers/scsi/sd.c per ottenere lo stesso sistema eliminando automount

[gnicK79]

Originariamente inviato da gnommo

Ancora una volta il dgn3500 usa una sistema diverso, che semplifica la vita.
Non usa automount, ma un hotplug custom, nel senso che il driver scsi
all'inserimento o disinserimento di un drive chiama direttamente lo script:
/etc/usb/usb_m.sh

-

ed /etc/usb/usb_u.sh al disinserimento:

-

potete immaginare che mi è bastato modificare questi script per ottenere un comportamento impeccabile di modfs, incluso il caricamento automatico di modfs all'inserimento di un drive
Anche sul dgn2200v3 è stato adottato questo metodo
In realtà quindi si potrebbe patchare il file drivers/scsi/sd.c per ottenere lo stesso sistema eliminando automount

Accidenti!
Con quegli script è come avere un listener aperto e a portata di mano ogni volta lo si desidera. -.-

Comunque, ieri, per sfizio ho fatto un altro tipo di test:
Ho tolto di mezzo l'hub e ho collegato la chiavetta partizionata in due direttamente al connettore usb dietro al router.
Il router montava, come l'hub, le due partizioni in sda1 ed sda2.
Poi però quando ho rimontato la prima (sda1), invece di avere la situazione, 2x sda1 e 1x sda2 come per l'hub, ha rimappato in questa maniera 1x sda1 1x sdb1 1x sdb2 ... con le conseguenze di avere il noto problema delle condivisioni duplicate.
Il mounting multiplo funziona bene solo nel device sda1... c'è poco da fare.
Quindi il risultato è addirittura peggiore che con l'hub.
Penso che con tutti sti casini del DGN2200, abbiamo avuto una botta di fortuna che almeno un device non dia problemi.
Mamma mia!
Effettivamente verrebbe voglia di metterlo a posto... il driver, in modo che si possano inserire le periferiche come cavolo capita e non fare attenzione a tutti sti accorgimenti.

Il punto è che patchare quel driver vorrebbe dire ricompilare il kernel e io qui ho una Debian 6 con gcc allineato. La versione del kernel è bella che superata da un bel pezzo...
Dovrei mettere in piedi una vm con Fedora 6 e situare l'ambiente di sviluppo.
Uffa! -_-

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

Avrei da chiederti una cosa riguardo a modfs:
Sarebbe possibile mettere rapidamente sul DGN2200 una busybox con il demone httpd scorporato e non built-in, tipo come per il DGN3500?
Sospetto che il processo, dipende cosa configuri, venga killato di proposito... e no si tratti di crash.
Il punto è che per rinominarlo bisognerebbe che sia indipendente!

[gnommo]

Originariamente inviato da gnicK79

Avrei da chiederti una cosa riguardo a modfs:
Sarebbe possibile mettere rapidamente sul DGN2200 una busybox con il demone httpd scorporato e non built-in, tipo come per il DGN3500?
Sospetto che il processo, dipende cosa configuri, venga killato di proposito... e no si tratti di crash.
Il punto è che per rinominarlo bisognerebbe che sia indipendente!

Certo, io l'ho compilato a parte perchè l'ho preso da un'altra versione di busybox, non ricordo più per quale problema, ma mi sa proprio che io ho apportato delle modifiche a httpd in un modo e cionci in un altro
Quindi i due httpd probabilmente non sono uguali.

[gnicK79]

Originariamente inviato da gnommo

Certo, io l'ho compilato a parte perchè l'ho preso da un'altra versione di busybox, non ricordo più per quale problema, ma mi sa proprio che io ho apportato delle modifiche a httpd in un modo e cionci in un altro
Quindi i due httpd probabilmente non sono uguali.

Niente da fare! Inutile compilarne una versione standalone.
In un modo piuttosto spartano ho preso la busybox e il demone http dal 3500 e li ho portati di là nel 2200, ho rinominato quest'ultimo, poi l'ho fatto puntare da un collegamento simbolico per ripristinare i collegamenti con i pacchetti.
Alcune cose chiaramente non funzionavano più per via della busybox, tuttavia il demone del 3500 l'ha tirato su e funzionava. L'interfaccia era navigabile.
Però al momento del test purtroppo è stato killato allo stesso modo di quello originale.
Per cui la soluzione migliore resta quella di affidarsi allo scheduler e fare il check a intervalli per riportarre up il demone.
Tra l'altro serve inserire un piccolo script per fare pulizia regolarmente fra la nvram per il problema delle periferiche usb e delle occorrenze non valide usb_info_dev* che pian piano crescono se si fanno operazioni di editing fra le risorse condivise etc etc.
In sda1 non riesce, per fortuna, a duplicare le risorse condivise di una partizione montata più volte. E questo mi sa che è un caso fortunato.
Infatti lui ci prova lo stesso ad assegnargli una seconda lettera di unità , ma fallisce lasciando variabili trash nella nvram.
Quindi serve uno scriptino che distingua queste var le elimini e poi un faccia un resorting. Quello lo avevo fatto... per cui amen.

Effettivamente sarebbe meglio ricompilare quel driver per evitarci tutti sti casini!
Vabbè.

Grazie comunque.

[gnicK79]

Per quanti avessero avuto problemi seri con l'attuale versione del firmware moddato del DGN2200, io metto a disposizione la versione che ho assemblato.

Changes & fixes:

• Corretto un problema di stabilità generale che provocava blocchi e crash all'interfaccia principale quando il router operava in PPPoE
• Possibilità di selezionare fra 4 driver ADSL (Accedere al router da Telnet e digitare "adsldrv" - help built-in)

Download

- p.s.: per il driver versione 026 evitare di settare la modalità 0(auto), altrimenti il modem non si allinea al riavvio; specificare il parametro della modulazione preferita.
- p.p.s: si ricorda... il settaggio esplicito della modalità ADSL da comando ha priorità inferiore rispetto alle impostazioni ADSL in Modfs qualora queste ultime risultassero abilitate.


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.

[puket]

Scusate l'ardire , ma il buon e caro Cionci che fine ha fatto? Si sa nulla?

[Parnas72]

ma il buon e caro Cionci che fine ha fatto?

http://www.hwupgrade.it/forum/showpo...postcount=3718

[gnicK79]

No no, non è proprio cosa...

Il DGN2200, almeno la prima versione, non è proprio fatto per gestire da readyshare più di una unità USB alla volta.
Forse era/è una feature da completare... inserita nella loro todo list.
Sta di fatto che allo stato attuale, ci sono errori di gestione delle unità multiple usb.
A parte il discorso modfs e di quello che necessita per essere sfruttato, il software di gestione è proprio incompleato/buggato di suo nella gestione di più dispositivi usb.

Giusto per curiosità avevo abilitato la funzione dei dispositivi autorizzati ed è stata una esperienza penosa e imbarazzante.
Cioè, fintanto si ha la solita e unica pennetta usb attaccata va bene; appena invece il router trova più di una periferica collegata, fa dei casini nell'indicizzazione.
Scambia le unità fra le periferiche autorizzate e non, perché la routine di gestione fa il check soltanto in /dev/sda1... e non prevede un ipotetico HUB.
Tipo non autorizzi la chiavetta alla posizione 1 e autorizzi invece la chiavetta nella posizione 2.... al restart di samba vai nell'interfaccia di editing e se provi ad effettuare qualche modifica scambia le lettere assegnate.... pensa di trovare la penna autorizzata in sda1 e invece lì c'è quella non autorizzata giacchè va in confusione e si congeda con un bel crash del demone http.
Cioè sono riuscito a trovare il modo per fare crashare il web server predefinito del router, e non quello di modfs
Ancora quello non lo avevo mai visto crashare!

Mamma mia tutta la gestione usb sarebbe da estirpare!