[Modfs] Sviluppo pacchetti e porting su altri router

[gnommo]

Ecco appunto, riportiamoli anche qui:

Sì, sono cose fattibili

Vedo ora che è stato aggiornato il firmware del vostro router. Purtroppo non ho quella versione estratta.

Purtroppo per decomprimere il root file system è un bel casino senza un kernel compatibile. Io lo estraggo dalla shell del router, sulla chiavetta USB. Lo monto e lo comprimo in un tar che mi porto sulla mia macchina. Guardo se ce la faccio.

Questo è lo script per ottenere i file immagine (kernel e rootfs) dal binario del firmware:

#!/bin/bash
echo "Extract root file system image from firmware image..."

image="DGN2200-V1.0.0.36_7.0.36.chk"
suffix="DGN2200_1.0.0.36"
rootfs_start=314
rootfs_length=4837376

dd bs=1 if=$image of=rootfs-$suffix.sqsh skip=$rootfs_start count=$rootfs_length
dd bs=1 if=$image of=vmlinux-$suffix.lz skip=`expr $rootfs_length + $rootfs_start`


echo "...done"

http://www.mediafire.com/?bcjvrugcj9oyxco

Quei due numeri sono la posizione di inizio del root file system nell'immagine (dove c'è la lettera q di "qshs" o la s di "sqsh") e la lunghezza del rootfs che ho evidenziato nello screen.

Lo script per il build dell'immagine (il file del kernel si deve chiamare vmlinuz.lz, il rootfs deve essere nella dir target) :

#!/bin/bash

BASE_DIR=`dirname $0`
TOOLS_DIR="$BASE_DIR/tools"
TARGET_DIR="$BASE_DIR/target"
DATA_DIR="$BASE_DIR/data"
IMAGES_DIR="$BASE_DIR/images"

ANNEX="A"
NAME="WW"

test ! -d $TOOLS_DIR && echo "Run setup.sh before running build.sh" && exit 1

if [ $# -ne 0 ]; then
  if [ "$1" != "NA" ] && [ "$1" != "B" ]; then
    echo "Usage: build.sh [NA|B]"
    echo "  No parameters: build World Wide Annex A firmware"
    echo "  NA: build North America Annex A firmware"
    echo "  B: build World Wide Annex B firmware"
    exit 1
  fi
  if [ "$1" = "NA" ]; then
    NAME="NA"
  else
    ANNEX="B"
  fi
fi

FULL_PATH=`readlink -f $DATA_DIR/acos`

ln -fs $FULL_PATH/ambitCfg_"$NAME"_"$ANNEX".h $FULL_PATH/ambitCfg.h


$TOOLS_DIR/mksquashfs $TARGET_DIR $DATA_DIR/rootfs.img -be -noappend -all-root -b 65536 && \
$TOOLS_DIR/bcmImageBuilder --output $DATA_DIR/bcm96358GW_fs_kernel --chip 6358 --board "96358VW" --blocksize 64 --cfefile $DATA_DIR/cfe6358.bin --rootfsfile $DATA_DIR/rootfs.img --kernelfile $DATA_DIR/vmlinux.lz && \
$TOOLS_DIR/bcmImageBuilder --output $DATA_DIR/bcm96358GW_cfe_fs_kernel --chip 6358 --board "96358VW" --blocksize 64 --cfefile $DATA_DIR/cfe6358.bin --rootfsfile $DATA_DIR/rootfs.img --kernelfile $DATA_DIR/vmlinux.lz --include-cfe && \
$TOOLS_DIR/createimg --boardid="96358VW" --numbermac=11 --macaddr="02:10:18:01:00:01" --tp=0 --psisize=24 --gponsn= --gponpw= --inputfile=$DATA_DIR/bcm96358GW_cfe_fs_kernel --outputfile=$DATA_DIR/bcm96358GW_flash_image_96358VW && \
$TOOLS_DIR/addvtoken $DATA_DIR/bcm96358GW_flash_image_96358VW $DATA_DIR/bcm96358GW_flash_image_96358VW.w

RES=$?
if [ $RES -ne 0 ]; then
  echo 
  echo "Error: build failed !!!"
  exit $RES
fi

FILENAME=$IMAGES_DIR/DGN2200_`date +%m%d%H%M`_"$NAME"_$ANNEX.chk

touch $DATA_DIR/rootfs && \
$TOOLS_DIR/packet -k $DATA_DIR/bcm96358GW_fs_kernel -f $DATA_DIR/rootfs -b $DATA_DIR/compatible_$ANNEX.txt -oall $DATA_DIR/kernel_rootfs_image -i $DATA_DIR/acos/ambitCfg.h && \
rm -f $DATA_DIR/rootfs _*.chk && \
cp $DATA_DIR/kernel_rootfs_image.chk $FILENAME

RES=$?
if [ $RES -ne 0 ]; then
  echo 
  echo "Error: build failed !!!"
  exit $RES
fi

echo
echo
echo "Done! Firmware image $FILENAME has been built successfully."
echo

In pratica così è simile ai vecchi metodi di build dei DG834...

[gnicK79]

Scusate, sono stato un po' impegnato.

Nel tempo libero ho fatto alcune prove di assemblamento fra linux kernel e partizioni squash... provando anche interessanti incroci.

Comunque, ho beccato il problema.
Non centra un fico secco l'adsl.
Il problema risiede in 2 file di script bash nella partizione squash che fanno da appoggio ai sostituti originali.
A quanto pare il modo con cui viene "passata la shell" agli eseguibili originali non è corretto.... o perlomeno non in tutti i casi.

Spiego meglio....

Directory bin:
- pppd chiama con "exec file args" il file pppd.original (originariamente pppd)
- xdslctl chiama alla stessa maniera l'eseguibile xdslctl.original (originariamente xdslctl)

Il giro è chiaramente stato fatto per necessità agli scopi: nei file nuovi c'è roba che serve a modfs.
Però così non va bene... c'è da capire se gli eseguibili originali ritornano parametri e possano essere chiamati come identificatori.
La soluzione più semplice e veloce sarebbe rinominare i file nuovi bash in altro e riportare i nomi degli originali al loro posto (e in cascata risolvere i collegamenti simbolici che puntano ai bash).
Altrimenti capire se gli orginali possano essere chiamati in altro modo $().
Tipo se a Parnas72 o Gnommo andrebbe di intervenire sulla questione e dare qualche suggerimento per il miglior fix, risolviamo un bel po' di freeze qui e ci lasciamo alle spalle una volta e per tutte il problema.
Magari vi convincete una buona volta che la diceria della nvram fallata o mal gestita del DGN2200 è pura leggenda.
E sia chiaro il problema è di tutti i possessori del DGN2200.
Non ci sono cavoli. Come disse Cionci il riavvio dell'interfaccia grafica funziona male (anzi non funziona proprio). Questo è vero solo in PPPoE.
Da telnet è un'altra storia, poiché le situazioni no sono riconducibili e da http vengono eseguiti sequenze di comandi.
Aveva torto però per il fatto che il problema risiedesse anche nel fw originale. Questo non è vero infatti.

[gnommo]

Mancano due premesse per poter approntare una soluzione:
-chi chiama pppd e xdslctl
-perchè cionci ha usato exec

[Parnas72]

Uhm... non ho capito perchè la exec non va bene.
Onestamente anche io avrei fatto nello stesso modo: la exec carica nel processo corrente il binario originale, che è quanto si voleva fare per rendere la cosa trasparente ai processi del firmware Netgear.
Per altro, il modfs basato su 1.0.0.20 è fatto nello stesso modo e ti funziona, o sbaglio ?

[gnicK79]

Originariamente inviato da gnommo

Mancano due premesse per poter approntare una soluzione:
-chi chiama pppd e xdslctl
-perchè cionci ha usato exec

Non saprei se è davvero utile tentare di capire chi e quante volte vengono chiamati questi eseguibili. Si rischia di perdersi se sono ridondanti.
Per quanto riguarda gli algoritmi negli bash, c'è roba tipo Adsl retrain e pppoe relay.....
In pratica Cionci ogni volta che interecetta queste chiamate, esegue questi procedure di modfs e poi ripassa il controllo agli eseguibili originali. E' una deviazione e un giro necessario per assicurarsi di applicare ogni volta le impostazioni di modfs... cioè è una cosa logicamente che si riesce a capire.
Quello che importa, a mio modesto parere, è che la chiamata, chiunque la faccia, avvenga nella maniera corretta. E' possibile ci sia un problema col passaggio degli argomenti. Poi segnalo che i nuovi file bash di appoggio sono degli .sh, mentre quelli originali sono degli eseguibili. Exec però non dovrebbe avere problemi a chiamare sia gli uni e gli altri.
Ho smadonnato abbastanza prima di capire fosse qui il problema. Piano piano andavo ripristinando roba originale nello squash, fino a trovare la causa nella cosa più insospettabile.

Originariamente inviato da Parnas72

Uhm... non ho capito perchè la exec non va bene.
Onestamente anche io avrei fatto nello stesso modo: la exec carica nel processo corrente il binario originale, che è quanto si voleva fare per rendere la cosa trasparente ai processi del firmware Netgear.
Per altro, il modfs basato su 1.0.0.20 è fatto nello stesso modo e ti funziona, o sbaglio ?

Ehhh hmm. Quando ho visto che avevo catturato il problema, la prima cosa su cui mi sono scagliato sono stati gli algoritmi di modfs dentro questi file.
Chi avrebbe pensato che ci fosse un problema nell'exec e al momento di passare la shell?
E invece, per tagliare la testa al toro, ho tolto tutto!!!
Ho lasciato solo la chiamata exec file $*, trasformando il file in un vero redirecting secco.
Niente da fare, 2 di picche. Freeza.
Appena ripristino i nomi dei file originali, e tolgo di mezzo i bash (o li rinomino in altra roba per metterli fuori gioco) funziona tutto benone.
Cos'è si incarta nel passaggio degli argomenti?

Con la 0.20 in realtà si trattavano di crash camuffati da un reboot. Me ne sono accorto poi perché perdevo tutte le modifiche applicate.
L'exec fa cilecca per qualche motivo e provoca instabilità con effetti più disparati. PPPoA per forza.
Il PPPoE in Modfs non ha MAI funzionato, per quello che mi riguarda.
Qui c'è gente che ha problemi con la chiavetta inserita.
Ma quale chiavetta!!! LoL

[gnommo]

Originariamente inviato da Parnas72

la exec carica nel processo corrente il binario originale

Originariamente inviato da gnicK79

Non saprei se è davvero utile tentare di capire chi e quante volte vengono chiamati questi eseguibili.
...
Ho lasciato solo la chiamata exec file $*, trasformando il file in un vero redirecting secco.

E' utile sapere chi chiama pppd per cercare di capire come lo chiama e cosa si aspetta dopo averlo chiamato e cosa fa dopo la chiamata.
Senza capire queste cose non si può pensare ad una soluzione, almeno che non si cambi proprio approccio e si faccia tutto in maniera diversa
Appunto provate a fargli creare un nuovo processo sostituendo
exec ad una chiamata pura
pppd.original $* &

La sostituzione di pppd con una shell serve solo per implementare il pppoe relay e la configurazione del router in modalità solo modem.
Sono cose facilmente implementabili in maniera diversa facendo almeno del redirect.

[gnommo]

Provate anche a salvare in un file $*
per vedere la riga di comando come è e confrontarla con quella originale.

[Parnas72]

Originariamente inviato da gnommo

Provate anche a salvare in un file $*
per vedere la riga di comando come è e confrontarla con quella originale.

Formalmente la sintassi "exec file $*" in effetti è sbagliata, perchè il modo corretto di passare i parametri senza modificarli è:
exec file "$@"

Ma la differenza nei due casi è significativa solo se ci sono dei parametri che contengono uno spazio (in quel caso la prima chiamata spezzerebbe il parametro in due, mentre la seconda lo manterrebbe integro).

[gnicK79]

Penso non c'entrano i parametri, il problema sembra essere proprio il nome del demone ppp.
Non lo puoi cambiare, a meno che non vai a scovare le librerie dove in maniera esplicita chiudono il demone dai processi attivi chiamandolo per nome e quindi ricompilarli appositamente.

In pratica prima di eseguire un riavvio, in PPPoE, viene eseguita la chiusura della connessione ppp0. Il punto è che invece di chiuderla come si dovrebbe, cioè andandola a scovare tramite l'ID del processo, a quanto pare da qualche parte viene controllato proprio il nome del file.
Va cercando invano il processo pppd fra quelli attivi.. e non lo troverà mai.

Se tipo ti metti a cambiare protocollo di incapsulamento, non riesce nemmeno a killare la connessioni precedenti....
.... giacché se provi a cambiare diverse volte ti ritrovi nei processi attivi 'n' pppd.original quanti sono i cambiamenti che hai fatto. LoL
Dovrai killare a manina... o devi riavviare (da telnet obbligatoriamente).

Al riavvio ovvio, viene fatta pulizia e ti reinizializza correttamente con 1 connessione... però poi al momento di chiudere le connessioni sei ex-novo punto e a capo. L'interfaccia originale diventa un campo di mine in cui devi stare a attento a cosa cambi e a prevedere le chiusure automatiche delle connessioni, altrimenti ti si freeza. Ergo il fw moddato in PPPoE è inusabile.

Tutto sto macello per un pppoe relay che manco funziona.

#!/bin/sh

DOD=0

if [ "$2" = "ppp0" ]; then
  DOD=`param get pppoe_dod`
  /usr/sbin/enable_pppoe_relay.sh
fi

if [ $DOD -eq 2 ] && [ "`param get modfs_pppoe_modem`" = "1" ]; then
  exit 0
fi

exec pppd-original $*

[Parnas72]

Originariamente inviato da gnicK79

Penso non c'entrano i parametri, il problema sembra essere proprio il nome del demone ppp.
Non lo puoi cambiare, a meno che non vai a scovare le librerie dove in maniera esplicita chiudono il demone dai processi attivi chiamandolo per nome e quindi ricompilarli appositamente.

Se è solo quello il problema basta che invece di pppd-original lo chiami pppd e lo tieni in una directory separata. Però non mi torna, io il pppoe-relay a suo tempo l'ho testato e funzionava (sia con il fw vecchio che con quello attuale).
Poi se ci fosse un problema così macroscopico il PPPoE non dovrebbe funzionare a nessuno.

[gnicK79]

Originariamente inviato da Parnas72

Se è solo quello il problema basta che invece di pppd-original lo chiami pppd e lo tieni in una directory separata. Però non mi torna, io il pppoe-relay a suo tempo l'ho testato e funzionava (sia con il fw vecchio che con quello attuale).
Poi se ci fosse un problema così macroscopico il PPPoE non dovrebbe funzionare a nessuno.

Quindi tu dici di spostare il demone in un'altra cartella?
Come faccio a informare il router del riferimento cambiato?
Si puo' fare? Lo facciamo subito se è possibile.

Il PPPoE relay di per sè funziona ma a questo punto io non so più che significa il concetto per il quale si puo' affermare "che una cosa funziona oppure no".
Se per fare funzionare una cosa dobbiamo sputtanarne altre allora non ci siamo proprio.
Il problema ce l'hanno tutti i DGN2200 indistintamente.
Ce l'ha tipo ssstrada, quando confessò che inspiegabilmente si trovava tipo 3 connessioni PPPoE attive in memoria, poi ce l'ho io, dunque dunque.... ah sì.... e poi ce l'hai pure tu nonostante tu possa ignorarlo.

Come non avete notato il malfunzionamento, queste sono domande a cui solo voi potete rispondere.
In un progetto come questo si puo' affermare di aver dato vita a sessioni di collaudo serie?

In PPPoE, il router con il fw moddato non è in grado di chiudere autonomamente le connessioni se non killarle da telnet in maniera esplicita.
Quando cambi alcune impostazioni, il router va per chiuderle e riaprirle con i parametri aggiornati.
Se fallisce la procedura o freeza o crasha.
Tu commuta in PPPoE e smanetta un pochetto e poi vedi

Io per accorgemene che in PPPoE Modfs non era cosa, ci ho messo tipo 1 minuto e non ho fatto nemmeno test specifici o sforzi particolari.
Ho fatto tipo queste semplici cose:
Flashing fw moddato, impostazione PPPoE, reboot.
Freeze.

Pensi sia una procedura normale quella o una cosa piuttosto elaborata?
Cionci stesso disse che da interfaccia grafica se si esige il riavvio sono azzi amari!
Cosa vuoi che ti dica di più, se te lo dice lui?
In PPPoA evientemente ci sono trattamenti differenti, l'interfaccia se ne fotte di chiudere le connessioni e spiaccica un bel reboot da busybox.
Questo è!!!

[gnicK79]

Va bene!
Appurato che bisogna assolutamente ripristinare il nome originale del demone, perché è evidente che così non puo' andare....
... come rimaneggiamo di conseguenza lo script della connessione manuale a mò di modem in PPPoE?

Allora nel DGN2200 la situazione è questa ed è nota; abbiamo un baco per il quale il "manually connect" è un pacco .... cioè a dire, il router continua comunque ad eseguire connessioni automatiche nonostante è attiva quell'impostazione della connessione manuale.

Per cui se adesso non possiamo più interecettare e stoppare il demone, per i motivi conosciuti, con questa condizione qui:

if (pppoe_dod == 2) && (ppoe_mofs == 1) { // 2 = manually connect
exit // esci dal demone per evitare di instaturare la connessione
}

come si fa a simulare il relay a dovere?

L'unica idea che mi viene, su due piedi, è fargliela aprire una volta (al riavvio del router), visto che non la si puo' evitare, e fargliela chiudere dopo attraverso sostanzialmente uno script tempistico del tutto simile a quello preesistente.

Sarebbe favoloso trovare una sorta di listener da applicare al demone.

Tipo se è possibile applicare la soluzione di Parnas72 con estrema semplicità ci possiamo risparmiare tutta sta roba.... altrimenti o quello o boh (niente).

[Parnas72]

Originariamente inviato da gnicK79

Quindi tu dici di spostare il demone in un'altra cartella?
Come faccio a informare il router del riferimento cambiato?
Si puo' fare? Lo facciamo subito se è possibile.

Non devi informare il router: il router chiamo lo script pppd, questo fa la exec del demone originale. Quindi lo script invece di chiamare pppd-original dovrà chiamare original/pppd, dove "original" è un subdir creata ad hoc.

Il PPPoE relay di per sè funziona ma a questo punto io non so più che significa il concetto per il quale si puo' affermare "che una cosa funziona oppure no".

Ho provato ad aprire e chiudere più volte la connessione PPPoE da PC senza riscontare alcun problema, questo intendo per "funziona".

Ce l'ha tipo ssstrada, quando confessò che inspiegabilmente si trovava tipo 3 connessioni PPPoE attive in memoria

Sì, lui ha detto che una volta gli è capitato... però io mi aspetterei che succedesse in maniera sistematica, non una volta ogni tanto.

Io per accorgemene che in PPPoE Modfs non era cosa, ci ho messo tipo 1 minuto e non ho fatto nemmeno test specifici o sforzi particolari.
Ho fatto tipo queste semplici cose:
Flashing fw moddato, impostazione PPPoE, reboot.
Freeze.

Ecco, ti assicuro che a me invece facendo le stesse cose non freeza. Ho provato.

[gnommo]

Trovate una soluzione che tale script l'ho
passato anche a quelli del wag320n , voglio vedere a loro come si comporta e se lamentano gli stessi malfunzionamenti.

[gnicK79]

Originariamente inviato da Parnas72

Non devi informare il router: il router chiamo lo script pppd, questo fa la exec del demone originale. Quindi lo script invece di chiamare pppd-original dovrà chiamare original/pppd, dove "original" è un subdir creata ad hoc.

Proviamo! Faccio un tentativo.

Originariamente inviato da Parnas72

Sì, lui ha detto che una volta gli è capitato... però io mi aspetterei che succedesse in maniera sistematica, non una volta ogni tanto.

Avviene in maniera sitematica. Sempre!!!
Ma anche se non avvenisse in maniera sistematica, si soprassiede al fatto che avviene casualmente?
Abbiamo appurato invece se nel fw originale accade mai?
Facendo le stesse cose e identiche col fw originale cosa succede?

Originariamente inviato da Parnas72

Ecco, ti assicuro che a me invece facendo le stesse cose non freeza. Ho provato.

Da dove batti il reboot da telnet? Non vale da lì.
Senti qua. Che ti devo dire c'hai il DGN2200 che ti riesce a chiudere le connessioni.... è un modello SMART
In ogni caso se vuoi gli utenti che si sono lamentati del reboot che fallisce e dei freeze i post esistono. Basta che ti fai una ricerca nel thread di modfs.
Quanti sono? uno solo? 2?
Ma scusa ma con il seguito che ha modfs, cosa si pretendeva?
Manco alla netgear hanno notifiche sui alcuni problemi noti che si sa che esistono da anni.
Ringrazia dio che quell'anima l'abbia fatto presente.
Ignorarlo o non curarsene a dovere è stato il problema.
Non che io abbia più bisogno di ulteriori conferme al punto in cui sono arrivato.... ma questo per dire che non sono l'unico.
Sono l'unico che ne ha parlato, questo sì.... ma che vuol dire??
Perché se io devo passar per la mosca bianca mi secca tanto.
Io sono partito per dare la colpa alla DSLAM per assecondarvi.
Ricordatelo questo.... ed è facile tu abbia la stessa DSLAM mia per no parlare forse del profilo caricato in cabina.
Allora c'è da mettersi a ridere. Ecco.

[gnommo]

Ma guarda che se si tratta solo del pppoe relay potete tagliare la testa al toro eliminando del tutto lo script pppd e ripristinando l'eseguibile originale.
Per il pppoe relay si può usare, come nel dgn3500, un demone a parte dedicato a quella funzione.

[gnicK79]

Originariamente inviato da gnommo

Ma guarda che se si tratta solo del pppoe relay potete tagliare la testa al toro eliminando del tutto lo script pppd e ripristinando l'eseguibile originale.
Per il pppoe relay si può usare, come nel dgn3500, un demone a parte dedicato a quella funzione.

Vabbè ormai ne sto assemblando uno come ha suggerito Parnas72.
Eventualmente possiamo fare ciò che ci piace. L'ambiente di lavoro qui è sempre pronto. Non c'è problema.
Sono a disposizione.

Anche nel DGN3500 c'è il bug del manually connect?
Perché la soluzione adottata da Cionci ha il suo perché. Aveva bisogno di stoppare il demone altrimenti questo faceva di testa sua e si connetteva da solo ogni volta.

[gnommo]

Originariamente inviato da gnicK79

Anche nel DGN3500 c'è il bug del manually connect?

no sul 3500 è tutto diverso, non ho avuto bisogno di fare niente di tutto ciò.

[gnicK79]

Allora!

Sembra che la soluzione suggerita da Parnas72 sia buona.
Anche se il percorso è cambiato non gli frega una cippa, importante che non gli tocchi il nome del file, lui (il demone) è felice ovunque si trovi.
Bene! Un applauso al demone ppp che ha rotto il caxxo per 1 mese
Una voglia matta di eliminare il demone con "rm pppd" .

Il router in PPPoE è tornato solido come nel fw originale.
Niente crash al cambio di protocollo, niente freeze quando si eseguono riavvii da ui, i wizard vanno tutti a buon fine, niente connessioni doppioni.
Al cambio del tipo di incapsulamento riesce finalmente a chiudere le connessioni precedenti non più necessarie.... la causa di tutti i problemi.

Ora fatemi scialare.
Stasera risistemo la squash per benino e assemblo un fw come si deve.
Adesso la directory è "mutilata" nelle sue parti poiché non è stato semplice andare a capire il problema e poco per volta eliminavo gli script aggiuntivi.
Importante che abbiamo trovato il bandolo della matassa.

Io comunque assemblo l'ultima versione quella passata sottobanco con i 3 driver adsl.
Avete preferenze?

[Parnas72]

Originariamente inviato da gnommo

Ma guarda che se si tratta solo del pppoe relay potete tagliare la testa al toro eliminando del tutto lo script pppd e ripristinando l'eseguibile originale.
Per il pppoe relay si può usare, come nel dgn3500, un demone a parte dedicato a quella funzione.

Lo script penso servisse più che altro per sopperire al "bug" del manually connect che non funziona in ADSL 1 (così almeno mi pare di ricordare). Se si vuole usare il PPPoE da PC in aggiunta al PPPoE sul router, in effetti sostituire il pppd non serve.