[Modfs] Sviluppo pacchetti e porting su altri router

[gnicK79]

Gnommo

Dove potrei scaricare il sorgente di quel mini httpd che hai compilato?
Hai usato la toolchain del tuo 3500?

Mi servirebbe dare un'occhiata al sorgente e ricompilarlo.

[gnommo]

Originariamente inviato da gnicK79

Gnommo

Dove potrei scaricare il sorgente di quel mini httpd che hai compilato?
Hai usato la toolchain del tuo 3500?

Mi servirebbe dare un'occhiata al sorgente e ricompilarlo.

Ho usato la mia vecchia toolchain (compilata anni ed anni fa )
basata su uclibc 0.9.28 a voi serve la 0.9.29, vabbè ma non c'entra questo.
Il sorgente lo devo cercare perchè ho fatto delle modifiche , aspè che lo vado a cercare...

[gnicK79]

Originariamente inviato da gnommo

Ho usato la mia vecchia toolchain (compilata anni ed anni fa )
basata su uclibc 0.9.28 a voi serve la 0.9.29, vabbè ma non c'entra questo.
Il sorgente lo devo cercare perchè ho fatto delle modifiche , aspè che lo vado a cercare...

Grazie.
Sì, la toolchain basata su uclibc 0.9.29 l'ho scaricata da un link di Cionci che ho trovato qui sul forum. Penso dovrebbe andare bene. Ho sistemato l'ambiente e sembra che compili... ho fatto un piccolo test, e va!
D'altro canto l'httpd compilato con la tua di toolchain girava senza problemi anche sui nostri DGN2200 e fra l'altro nel monitoraggio delle risorse era palesemente più leggero del nostro con prestazioni percepite indentiche.
Il motivo comunque per cui mi serivrebbe ricompilarlo è un altro.

[gnommo]

Originariamente inviato da gnicK79

Grazie.
Sì, la toolchain basata su uclibc 0.9.29 l'ho scaricata da un link di Cionci che ho trovato qui sul forum. Penso dovrebbe andare bene. Ho sistemato l'ambiente e sembra che compili... ho fatto un piccolo test, e va!
D'altro canto l'httpd compilato con la tua di toolchain girava senza problemi anche sui nostri DGN2200 e fra l'altro nel monitoraggio delle risorse era palesemente più leggero del nostro con prestazioni percepite indentiche.
Il motivo comunque per cui mi serivrebbe ricompilarlo è un altro.

vedi un pò se è questa, ne ho un casino compilate e non ricordo quale ho messo :
http://www.mediafire.com/?hepw63yn6bmph70

[gnicK79]

Originariamente inviato da gnommo

vedi un pò se è questa, ne ho un casino compilate e non ricordo quale ho messo :
http://www.mediafire.com/?hepw63yn6bmph70

Vabbè se è lui o non è proprio lui, e se il test ha successo, eventualmente sarà un discorso su cui ci ritorneremo dopo. Aprendo la directory e vedendo un httpd già compilato di dimensioni differenti sembrerebbe essere un'altra versione.
Comunque per adesso non è prioritaria questa cosa.
Se ce ne sarà bisogno in seguito ti romperò le balle per compilare e linkare un eseguibile come si deve e con le opzioni giuste che mi consiglierai tu....

Nel frattempo...chiedo.. per compilare un applet standalone, nel mio caso l'httpd, c'è un'opzione da menuconfig? Oppure devo spostarmi nella directory networking e sistemare il file di configurazione da lì?
Io per compilare la prima volta gli ho fatto generare il file di configurazione con menuconfig e poi con make non aveva funzionato perché dovevo sistemare la sysroot altrimenti non trovava le librerie.
Sistemato --sysroot dalle opzioni di compilazione di menuconfig e facendolo puntare alla directory principale della toolchain ha compilato e il linker è riuscito a generare gli eseguibili ma con l'opzione "all-inclusive", cioè tutte le applet built-in nella busybox.

Ahh! Fra l'altro il processo non è proprio andato tutto a buon fine, si era fermato nello script sh "busybox.mll" nella riga $HOSTCC -E -DMAKE_LINKS -include $CONFIG_H $APPLETS_H... dove la variabile $HOSTCC valeva "gcc", cioè il nome di un compilatore che palesemente non poteva trovare; io per sbrigarmi ho forzato quella variabile al valore "mips-linux-gcc"... l'errore è scomparso ma non sono sicuro se è stata la mossa giusta. A te è successo?

[EDIT]
opzione -E Preprocess only; do not compile, assemble or link

c'entra niente questo?
[/EDIT]

[EDIT2]
Hai semplicemente fatto compilare la busybox con solo l'httpd a bordo e poi lo hai rinominato da busybox in httpd?
[/EDIT2]

[EDIT3]
LOOL! Come non detto...
Hard-Link & make install...
[/EDIT3]

[gnicK79]

Dunque!

Il test ha avuto esito positivo!
Spiego un attimino di che sto parlando.
L'httpd sul DGN220 per tutte quelle volte che aveva smesso di rispondere, in realtà non aveva mai crashato; il punto è che il nome del processo in memoria è in conflitto col nome del demone originale.

Mettendosi a configurare dall'interfaccia generale ci sono molteplici casi in cui il router chiama uno script che scatena il restart di taluni servizi.
Durante questa pocedura fra kill killall e compagnia bella il nostro di demone viene fatto fuori di proposito per un "matching pattern". Non mi metto neanche a guardare il sorgente, perché tanto è così.
Anche se con un refreshing non proprio immediato mi so messo con "top" a monitorare la situazione mentre eseguivo una di queste procedure e i sospetti sono divenuti quasi certezze.
L'httpd essendo un applet di una collezione di utilità non è rinominabile semplicemente cambiandogli il nome all'eseguibile, bisogna cambiare due minchiate nel sorgente e ricompilare altrimenti il check interno se ne accorge e per un errore interno non avvia l'applet con il categorico "applet not found".

Questo è quello che in pratica ho fatto con il sorgente che mi ha passato Gnommo. Mi sembrava strano che il demone andasse in crash così senza che ci fossero richieste in corso o per uno spazio troppo esiguo in RAM.

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

Gnommo, se mi potresti aiutare un attimino a compilare ben bene l'httpd con le opzioni giuste da menuconfig te ne sarei grato.

Io a parte che settare il sysroot per le librerie, la variabile $HOSTCC e l'opzione hard-link non ho toccato nient'altro.

L'httpd che il linker mi genera gira sul router e funziona, ma non totalmente e non con tutte le pagine del nostro HOME, tipo non carica le pagine con i grafici e altre cose ed errori nell'intepretazione PHP... manca qualche estensione?

queste le opzioni attive di default per l'httpd da menuconfig:
[*] httpd
│ │ [ ] Support using httpd only from inetd
│ │[*] Enable Basic http Authentication
│ │[*] Support MD5 crypted passwords for http Authentication
│ │[*] Support reloading the global config file using hup signal
│ │[*] Enable support -u <user> option
│ │[*] Support loading additional MIME types at run-time
│ │[*] Support Common Gateway Interface (CGI)
│ │[*] Enable support for running scripts through an interpreter
│ │[*] Support the REMOTE_PORT environment variable for CGI
│ │[*] Enable the -e option for shell script CGI simplification.

come l'hai compilato Gnommo?

[gnommo]

Originariamente inviato da gnicK79

Dunque!

Il test ha avuto esito positivo!
Spiego un attimino di che sto parlando.
L'httpd sul DGN220 per tutte quelle volte che aveva smesso di rispondere, in realtà non aveva mai crashato; il punto è che il nome del processo in memoria è in conflitto col nome del demone originale.

Mettendosi a configurare dall'interfaccia generale ci sono molteplici casi in cui il router chiama uno script che scatena il restart di taluni servizi.
Durante questa pocedura fra kill killall e compagnia bella il nostro di demone viene fatto fuori di proposito per un "matching pattern". Non mi metto neanche a guardare il sorgente, perché tanto è così.
Anche se con un refreshing non proprio immediato mi so messo con "top" a monitorare la situazione mentre eseguivo una di queste procedure e i sospetti sono divenuti quasi certezze.
L'httpd essendo un applet di una collezione di utilità non è rinominabile semplicemente cambiandogli il nome all'eseguibile, bisogna cambiare due minchiate nel sorgente e ricompilare altrimenti il check interno se ne accorge e per un errore interno non avvia l'applet con il categorico "applet not found".

Questo è quello che in pratica ho fatto con il sorgente che mi ha passato Gnommo. Mi sembrava strano che il demone andasse in crash così senza che ci fossero richieste in corso o per uno spazio troppo esiguo in RAM.

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

Gnommo, se mi potresti aiutare un attimino a compilare ben bene l'httpd con le opzioni giuste da menuconfig te ne sarei grato.

Io a parte che settare il sysroot per le librerie, la variabile $HOSTCC e l'opzione hard-link non ho toccato nient'altro.

L'httpd che il linker mi genera gira sul router e funziona, ma non totalmente e non con tutte le pagine del nostro HOME, tipo non carica le pagine con i grafici e altre cose ed errori nell'intepretazione PHP... manca qualche estensione?

queste le opzioni attive di default per l'httpd da menuconfig:
[*] httpd
│ │ [ ] Support using httpd only from inetd
│ │[*] Enable Basic http Authentication
│ │[*] Support MD5 crypted passwords for http Authentication
│ │[*] Support reloading the global config file using hup signal
│ │[*] Enable support -u <user> option
│ │[*] Support loading additional MIME types at run-time
│ │[*] Support Common Gateway Interface (CGI)
│ │[*] Enable support for running scripts through an interpreter
│ │[*] Support the REMOTE_PORT environment variable for CGI
│ │[*] Enable the -e option for shell script CGI simplification.

come l'hai compilato Gnommo?

Il fatto è che il dgn3500 usa uclibc 0.9.28 ed il 2200 0.9.29.
Già avevamo sperimentato queste diversità di comportamento, così che io avevo compilato httpd con le mie patch e cionci con le sue.
Mi sa che ti conviene compilare quello di cionci.
Sicuramente le sue patch sono contenute qui:
http://modfs.svn.sourceforge.net/vie...ar.gz?view=log

[gnicK79]

Originariamente inviato da gnommo

Il fatto è che il dgn3500 usa uclibc 0.9.28 ed il 2200 0.9.29.
Già avevamo sperimentato queste diversità di comportamento, così che io avevo compilato httpd con le mie patch e cionci con le sue.
Mi sa che ti conviene compilare quello di cionci.
Sicuramente le sue patch sono contenute qui:
http://modfs.svn.sourceforge.net/vie...ar.gz?view=log

Eh ma il tuo di httpd, quello che tuttora utilizzano gli utenti DGN3500 e che hai compilato con la tua di toolchain basata su uclibc 0.9.28 funziona alla perfezione sui nostri DGN2200. Te lo assicuro!
Se dunque quel demone tu l'hai compilato con il sorgente che mi hai passato, mi sorge qualche dubbio sulla bontà di compilazione della mia toolchain.
Mi potresti passare la tua di toolchain?
Sempre se non è troppo disturbo!! (dice Gnommo... è 2 gg che rompi le @@ ) Ti chiedo scusa!


Ahh dimeticavo!! Hai messo particolari opzioni per l'ottimizzazione del codice? Io ho lasciato -Os

[EDIT]
Ho riscaricato il sorgente della Busybox 1.1.3, e inserito lì le modifiche del sorgente del demone httpd.
Il compilatore multipiattaforma da qui è riuscito a costruire un eseguibile funzionante e dannatamente striminzito .
Probabile ci fossero strascichi di compilazione dovuti al compilatore gcc di sistema della tua distribuzione o forse della toolchain stessa.
Si doveva fare un rebuild totale...
Comunque va bene, faccio un po' di test e poi si mette nel repository con le opportune modifiche agli scripts.
Grazie.
[/EDIT]

[dmann9999]

Originariamente inviato da 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.

bellissimo lavoro, complimenti l'ho provato solo adesso, secondo me dovresti metterlo in vista nel thread di modfs

[gnicK79]

Originariamente inviato da dmann9999

bellissimo lavoro, complimenti l'ho provato solo adesso, secondo me dovresti metterlo in vista nel thread di modfs

A dire la verità sarebbe da mettere di corsa nel post battistrada del thread principale come firmware di riferimento e come aggiornamento importante e consigliato.... da eseguire alla svelta.
Giusto appunto per questo fix:

Corretto un problema di stabilità generale che provocava blocchi e crash all'interfaccia principale quando il router operava in PPPoE

e non per altro.

Se Gnommo vuole lo può fare, io l'ho rilasciato... il link c'è... posso ripostarlo un'altra volta di là... lol, ma poi non è che posso.... boh.. forse è uscito in sordina principalmente a causa mia

[gnommo]

Originariamente inviato da gnicK79

A dire la verità sarebbe da mettere di corsa nel post battistrada del thread principale come firmware di riferimento e come aggiornamento importante e consigliato.... da eseguire alla svelta.
Giusto appunto per questo fix:


e non per altro.

Se Gnommo vuole lo può fare, io l'ho rilasciato... il link c'è... posso ripostarlo un'altra volta di là... lol, ma poi non è che posso.... boh.. forse è uscito in sordina principalmente a causa mia

si provvedo.

[gnicK79]

Gnommo, si dovrebbe procedere a fare un commit sul repository.
Ti delego la faccenda.

- Nella directory dei binari del DGN2200 dovresti inserire questa nuova versione ricompilata del webserver http://www.mediafire.com/download.php?pir2r4r03c4tvd6 basata sul sorgente che mi hai passato.
- Poi togli di mezzo pure il collegamento simbolico httpd che punta al demone embedded. E' inutile rendere disponibile l'httpd built-in della busybox, perché tanto i processi del router lo killano sistematicamente. Da adesso il webserver da utilizzare è quello standalone.

Anche se il resto delle funzionalità della busybox rimane alla versione 1.13.2, ho voluto compilare quello che mi hai passato tu perché è esiguo, è mini , e per l'esigua RAM che ci ritroviamo nel nostro router mi sembra sia la scelta migliore.
(RAM 1% - VSZ 300k) vs (RAM 6% - VSZ circa 1.3 M) con stesse prestazioni.
Chissenefrega se la versione è più vecchia e risulta non allineata; essendo un eseguibile indipendente non è un problema da prendere in considerazione, anzi a momenti gli metto pure il crond dimagrito di alcuni kili se questo è l'andazzo della RAM.

Io non saprei per quali motivi Cionci abbia voluto caricare una busybox più recente di un bel po' di revisioni e di conseguenza più pesante con un router come il nostro che con la RAM è sempre con l'acqua alla gola, però io rimango scettico su questa decisione.

Poi bisogna apportare 2 piccole modifiche agli script di avvio e stop del servizio:

Essendo degli script common nella struttura del repository dovrebbe andarci una cosa del genere
start.sh

#!/tmp/soft_links/sh

port=8081
httpd="httpd"

if [ "$device" = "DGN2200" ]; then
        httpd="httpws"
fi

ln -s $modfs_bin/php /tmp/soft_links/php
$httpd -p $port -h  $modfs/www -c $modfs/etc/httpd.conf

stop.sh

#!/tmp/soft_links/sh    

httpd="httpd"

if [ "$device" = "DGN2200" ]; then
        httpd="httpws"
fi

for pid in `pidof $httpd`; do
  res=`cat /proc/$pid/cmdline | grep "$modfs"`
  if [ "$res" != "" ]; then
    kill -9 $pid
  fi
done
rm /tmp/soft_links/php

[gnommo]

Originariamente inviato da gnicK79

Gnommo, si dovrebbe procedere a fare un commit sul repository.

Ok sarà fatto.
Solo non capisco perchè cambiare gli script. Cancellando il softlink httpd e sostituendolo con il nuovo eseguibile httpd, quali problemi comporta?
Devo dare a te e parnas72 l'accesso in scrittura all'svn

[Parnas72]

A quanto dice gnick, il processo non deve chiamarsi httpd altrimenti viene occasionalmente killato da qualche routine del firmware Netgear (magari basterebbe ignorare il segnale nel codice, ma penso anch'io che si faccia prima a rinominarlo).

[gnicK79]

Originariamente inviato da gnommo

Ok sarà fatto.
Solo non capisco perchè cambiare gli script. Cancellando il softlink httpd e sostituendolo con il nuovo eseguibile httpd, quali problemi comporta?

Come dice Parnas72, il processo non puo' chiamarsi come quello di base perché altrimenti cade sotto le grinfie del check. E' un po' come la vecchia storia del demone pppd, ma al contrario (cioè lì non riusciva a killarlo perché non matchava).

Originariamente inviato da Parnas72

magari basterebbe ignorare il segnale nel codice, ma penso anch'io che si faccia prima a rinominarlo).

Che intendi? Ti riferisci al discorso "kill per signal"? Dici di compilare il demone apportando un cambiamento per cui si ignorano i segnali di processo inviati da kill?

[gnommo]

Originariamente inviato da Parnas72

il processo non deve chiamarsi httpd

ops che rinco... avevo seguito la discussione quindi lo sapevo perfettamente il motivo

[gnicK79]

@Gnommo,

ma sta cosa qui è che mi è successa è normale, o effettivamente mi manca da fare qualcosa?

Ho scaricato il tar dal trunk sul repository; eseguo lo script build per creare l'immagine di modfs, la procedura va tutta a buon fine, unzippo l'immagine e la metto sulla chiavetta, al riavvio modfs non funziona. Tipo ho provato 2 volte e niente da fare, mentre se metto la 0.2 beta va.
Ti posto gli errori di due log:

mod_setup.log

Not found on /dev/sda1
Found on /dev/sda2
mkdir: '/tmp/mod/modfs/lib/DGN2200/libresolv.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libm.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
ln: '/tmp/mod/modfs/lib/DGN2200/libresolv.so.0' is not an ELF file
ln: '/tmp/mod/modfs/lib/DGN2200/libm.so.0' is not an ELF file
ln: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
ln: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
ln: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
ln: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
ln: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
ln: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
ln: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
/tmp/mod/modfs/boot.sh: 54: routerdb: Permission denied
rm: '/tmp/mod/modfs/lib/DGN2200/libresolv.so.0' is not an ELF file
rm: '/tmp/mod/modfs/lib/DGN2200/libm.so.0' is not an ELF file
rm: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
rm: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
rm: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
rm: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
rm: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
rm: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
rm: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libresolv.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libm.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file
mkdir: '/tmp/mod/modfs/lib/DGN2200/libc.so.0' is not an ELF file

startup.log

tmp/mod/modfs/boot.sh: 62: packages_start: Permission denied

Cosa diamine è? Problema di permessi o che altro? Ma mi sembra strano...

[EDIT]
ma che!!?? mancano i link simbolici!!??
[/EDIT]

[gnommo]

hai chiamato lo script build.sh da root?

[gnicK79]

Originariamente inviato da gnommo

hai chiamato lo script build.sh da root?

Beh sì, anche perché col normal user col cavolo che lo script ti costruisce l'immagine.., ci sono comandi che, almeno a default, il sistema non concede il lusso di esecuzione senza avere i massimi privilegi.

Comunque il problema, come avevo editato, erano/sono i link simbolici.
Gnommo tu procedi alla sincronizzazione con un client SVN? Lavori con un IDE? Che so tipo Eclipse e plug-ins con client SVN embedded.
Il repository, penso per ragioni di compatibilità, non permette la memorizzazione di symlink, che vengono invece sostituiti da file di testo fittizi che fanno da segnaposto.
Se scarichi il tarball di una directory, mica ti rigenera i symlink, scarichi i file di testo corrispondenti e devi ripristinarli a manina.
Io mica ci avevo fatto caso!
Me ne sono accorto solo dopo.
Certi client SVN quando fai una sincronizzazione col server procedono alla ri-conversione dei file di testo, evidentemente contrassegnati, in maniera del tutto trasparente all'utente.
Io mi sono arrangiato con uno script che ricorsivamente cerca questi files dentro la directory del trunk e li rimpiazza con il link simbolico corrispondente.
Tutto qui.

P.S.: Notevole, la nuova sezione Router Info, sia per la pulizia dell'impaginazione sia per la qualità/quantità di informazioni che offre. Bel lavoro!

[gnommo]

Originariamente inviato da gnicK79

Io mi sono arrangiato con uno script che ricorsivamente cerca questi files dentro la directory del trunk e li rimpiazza con il link simbolico corrispondente.
Tutto qui.

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


Mi testate un pò l'ultima build dall'svn?
Vorrei fare un pò di ordine, togliendo le versioni 0.2, 0.3 e 0.3 per wag320
con tutti i pacchetti da aggiornare sparsi qui e là,
e mettere nel thread un'unica versione, l'ultima build disponibile,
che ha già tutto aggiornato.

In modo che inizio a mettere man mano nell'svn i nuovi cambiamenti per la versione 0.5 , in primis il sistema di upgrade online dei package.