[Ipotesi] Aggiungere funzionalità a tutti i router Netgear con porta USB

[cionci]

In questi giorni mi è nata una pazza idea. Sul mercato ormai ci sono molti router Netgear dotati di porta USB.
I router più o meno offrono le stesse funzionalità di base e a chi più e chi meno servirebbero varie feature che potrebbero essere aggiunte tramite firmware custom.
Il problema dei firmware custom è che ogni persona potrebbe lavorare solo sul proprio modello di router ed in ogni caso il rischio nel testare firmware con svariati flash è assolutamente alto e poco pratico.
L'idea era quella di fare delle modifiche base ai firmware originali, modifiche facilmente eseguibili e che non necessitano di test approfonditi (si tratterebbe di modificare solo pochissimi file di testo).
Successivamente le funzionalità aggiuntive potrebbero essere proposte come pacchetti installabili semplicemente inserendole in una chiavetta/disco usb collegata al router o tramite una interfaccia web.
Tutte le funzionalità aggiuntive rimarrebbero nella memoria di massa collegata al router, quindi con il router avviato senza memoria di massa il firmware sarebbe quello base.

Le funzionalità facilmente inseribili sarebbero varie:
- interprete PHP (per poter scrivere in modo più agevole le pagine web)
- modifica del Target SNR Margin
- port forwarding (redirigere una porta di IP pubblico su una porta diversa di un ip privato)
- controllo avanzato del QoS (tramite l'utility tc già inclusa nel firmware)
- wake on lan
- pianificazione wifi
- nfs server (http://unfs3.sourceforge.net/)
- telnet attivo all'avvio
- supporto per la condivisione delle stampanti
- server ssh (http://matt.ucc.asn.au/dropbear/dropbear.html)
- supporto per ext2/3 (fuse già attivo nel kernel, http://sourceforge.net/projects/fuse-ext2/)
- supporto per scrittura su ntfs (tramite ntfs-3g, per chi non ce l'ha)
- condivisione file personalizzata, con vari livelli di privilegio
- UPnP DLNA per lo streaming audio/video tramite rete (http://sourceforge.net/projects/minidlna/)
- client torrent (assolutamente da verificare se le prestazioni sono sufficienti)
- probabilmente anche supporto a chiavi UMTS (ma qui ci sarebbe da lavorare molto)

Parlo solo dei router netgear perché sono quelli che hanno la possibilità di costruire un firmware custom in pochissimi passaggi. Qualsiasi altro router potrebbe essere utilizzabile con la stessa metodologia, purché sia possibile costruire un firmware custom e sia disponibile una toolchain funzionante.

Su come fare la creazione dei pacchetti e la relativa installazione ho già diverse idee in mente.
La cosa principale è la disponibilità di un buon programmatore web, che abbia voglia di dare un'impostazione dal punto di vista grafico e di CSS all'interfaccia web.
Per la parte PHP ci posso essere anche io.
Per organizzarci per la parte tecnica useremo un thread in programmazione.
Intanto mi sarebbe piaciuto saggiare la disponibilità di qualche utente a dare una mano e come questa cosa potrebbe essere accolta dai possessori dei router in questione.

Router Netgear che sono attualmente supportati:
- DGN2200
- DGN3500

Router Netgear che potrebbero essere supportati:
- DGND3300
- WNDR3300
- WNDR3400
- WNR3500
- WNR3500L
- WNDR3700

[nuovoUtente86]

Idea sicuramente interessante : aggiungerei al tuo elenco il supporto al QoS e Traffic Shaping dove non presente e alla semplificazione (per favorire utenti inesperti) del setup dove già presente. Interessante anche il supporto per apparecchi voip USB.
Non posso darti la disponibilità per lo sviluppo della parte front-end per la quale non avrei nè la pazienza nè il tempo, ma per lo sviluppo delle funzionalità sicuramente.

[cionci]

Originariamente inviato da nuovoUtente86

Idea sicuramente interessante : aggiungerei al tuo elenco il supporto al QoS e Traffic Shaping dove non presente e alla semplificazione (per favorire utenti inesperti) del setup dove già presente.

Questo è già più complicato credo, no ? A meno di supporto già presente, ma non abilitato nel firmware.

[Alfonso78]

interessante...

mi iscrivo per curiosità...!!!

[nuovoUtente86]

Originariamente inviato da cionci

Questo è già più complicato credo, no ? A meno di supporto già presente, ma non abilitato nel firmware.

Dipende da quanto si può/voglia andare a scrivere a basso livello. Non conosco esattamente il set di funzionalità messo a disposizione dal tool di sviluppo (come ad esempio eventuali API già esposte), ma nel caso specifico si tratta di andare ad interfacciarsi con le code dell' interfaccia (scusate il gioco di parole) wan/ATM.
Per il voip il discorso è un po analogo all' umts

[cionci]

Originariamente inviato da nuovoUtente86

Dipende da quanto si può/voglia andare a scrivere a basso livello. Non conosco esattamente il set di funzionalità messo a disposizione dal tool di sviluppo (come ad esempio eventuali API già esposte), ma nel caso specifico si tratta di andare ad interfacciarsi con le code dell' interfaccia (scusate il gioco di parole) wan/ATM.

Fai conto che sono tutti basati su Linux.
Non ho mai indagato fino in fondo, ma mi sa che senza ricompilare il kernel sia impossibile. L'algoritmo di scheduling del QoS è una funzione messa a disposizione dal kernel.
Certo non è impossibile nemmeno questo, ma diciamo che in tal caso andrebbe oltre al target previsto (nessuna modifica importante al firmware ufficiale).

Originariamente inviato da nuovoUtente86

Per il voip il discorso è un po analogo all' umts

Per le chiavette UMTS si tratterebbe di compilare moduli per il kernel e poi fare delle modifiche alla tabella di routing, senza quindi ricompilare il kernel o fare alcuna modifica al firmware. Per il supporto a telefoni VoIP ci sarebbero più problemi, visto che bisognerebbe includere anche un supporto alle periferiche audio.

[nuovoUtente86]

Originariamente inviato da cionci

Fai conto che sono tutti basati su Linux.
Non ho mai indagato fino in fondo, ma mi sa che senza ricompilare il kernel sia impossibile. L'algoritmo di scheduling del QoS è una funzione messa a disposizione dal kernel.
Certo non è impossibile nemmeno questo, ma diciamo che in tal caso andrebbe oltre al target previsto (nessuna modifica importante al firmware ufficiale).

Si, sicuramente è un lavoro di più basso livello, ma credo come cosa sia molto intrigante, soprattutto a livello di studio e valutazione dello politiche di scheluling più che la mera implementazione.

Per le chiavette UMTS si tratterebbe di compilare moduli per il kernel e poi fare delle modifiche alla tabella di routing, senza quindi ricompilare il kernel o fare alcuna modifica al firmware. Per il supporto a telefoni VoIP ci sarebbero più problemi, visto che bisognerebbe includere anche un supporto alle periferiche audio.

Be per l' umts, in definitifa si tratta di utilizzare come model la chiavetta piuttosto che ATM o rj45. Però in ogni caso, seppur vero che bisognerebbe pilotare i dispositivi di I/o audio (ma comunque si riduce ad interfacciarsi con una periferica sia essa un modem o un phoneUsb), la parte interessante è l' implementazione dei protocollo di segnalazione e codifica (che in generale, una volta studiati non comportano un grosso sforzo).

[cionci]

Non c'è assolutamente da implementare niente. Basta compilare e installare il modulo del kernel e inviare all'emulatore di porta seriale i giusti comandi AT per la connessione. A quel punto ci si trova un'interfaccia di rete, ci si lancia il client DHCP e si impostano default route e DNS nel sistema.

Comunque cerchiamo di rimanere sul generico, sulle questioni tecniche ne discuteremo più avanti.

[gnommo]

Mi iscrivo, pronto a sviluppare e testare sul dgn3500

[nuovoUtente86]

Originariamente inviato da cionci

Non c'è assolutamente da implementare niente. Basta compilare e installare il modulo del kernel e inviare all'emulatore di porta seriale i giusti comandi AT per la connessione. A quel punto ci si trova un'interfaccia di rete, ci si lancia il client DHCP e si impostano default route e DNS nel sistema.

Comunque cerchiamo di rimanere sul generico, sulle questioni tecniche ne discuteremo più avanti.

Mi riferivo alla parte voip , non al modulo UMTS.
Si in ogni caso la parte tecnica verrà dopo.

[gnommo]

Ho testato il php, funziona.
Meno male che esiste openwrt da cui si possono scaricare molti programmi per mips già compilati
Certo ha qualche problemino di integrazione con mini_httpd ma adesso vedo se ricompilando il php riesco a risolvere, mentre con il httpd che si può cacciare dalla busybox funziona.

[cionci]

Che io sappia per minihttpd bisogna fare qualche modifica: http://www.hochstrasser.org/wiki/pmw...inux/MiniHttpd (dubito che ci sia quel modulo del kernel già pronto, potremmo optare per l'inserimento del percorso dell'interprete)
In ogni caso potremmo tranquillamente killare il minihttpd lanciato di default e metterne uno compilato ad hoc

[gnommo]

Originariamente inviato da cionci

Che io sappia per minihttpd bisogna fare qualche modifica: http://www.hochstrasser.org/wiki/pmw...inux/MiniHttpd (dubito che ci sia quel modulo del kernel già pronto, potremmo optare per l'inserimento del percorso dell'interprete)
In ogni caso potremmo tranquillamente killare il minihttpd lanciato di default e metterne uno compilato ad hoc

Non è quello il problema, per quello basta inserire nei file php all'inizio
#!/percorso/php

Il problema invece è che il php vuole settata la variabile SCRIPT_FILENAME che mini_httpd non setta, ho fatto un wrapper per settare a mano ma ancora non sono riuscito a farlo andare mi da sempre a browser
No input file specified.
Devo vedere se ricompilando il php e modificando quella parte di codice riesce ad aprire correttamente il file.

[cionci]

Originariamente inviato da gnommo

Il problema invece è che il php vuole settata la variabile SCRIPT_FILENAME che mini_httpd non setta, ho fatto un wrapper per settare a mano ma ancora non sono riuscito a farlo andare mi da sempre a browser
No input file
Devo vedere se ricompilando il php e modificando quella parte di codice riesce ad aprire correttamente il file.

La patch per mini_httpd linkata sopra riguarda proprio questo problema

[cionci]

Cerco di spiegare brevemente le modifiche da fare al sorgente del firmware dei vari router, sono davvero basilari:
- creare un soft-link "mod" (o qualsiasi altro nome scelto) nel punto in cui si trovano i file HTML alla dir /mnt/main/http
- creare un soft-link /mnt che punta /tmp/mnt
- modificare la pagina html del frame superiore (quella che resta sempre visibile) per contenere il link all'interfaccia web delle modifiche del firmware
- modificare lo script di avvio (solitamente /etc/init.d/rcS o /usr/etc/rcS)

Quest'ultima modifica dovrà:
- creare /tmp/mnt/main
- per ogni partizione trovata:
--- montare la partizione su /mnt/main
--- fare il check sull'esistenza di /mnt/main/bin/boot.sh
--- se viene trovato deve eseguirlo e terminare
--- se non viene trovato deve andare alla prossima partizione

Sulla periferica usb la struttura dei file sarà così composta (ovviamente tutto in via provvisoria):

|- http: pagine html, php etc etc
|- db: db sqlite da usare per salvare dati (ogni pacchetto avrà un db diverso)
|- bin: file eseguibili (da mettere in path)
|- etc: file di configurazione
|- packs: i vari pacchetti verranno estratti qui
---|- nomepacchetto
------|- bin: eseguibili dal soft-linkare nella bin principale
------|- etc: configurazioni da soft-linkare nella etc principale
------|- data: file dati, pagine html etc etc
------|- scripts
---------|- boot.sh: script da eseguire al boot
---------|- install.sh: script da eseguire al momento dell'installazione
---------|- remove.sh: script da eseguire al momento della rimozione

Ovviamente il boot.sh principale eseguirà i boot.sh di ogni pacchetto.

[gnommo]

Originariamente inviato da cionci

Sulla periferica usb la struttura dei file sarà così composta (ovviamente tutto in via provvisoria):

|- http: pagine html, php etc etc
|- db: db sqlite da usare per salvare dati (ogni pacchetto avrà un db diverso)
|- bin: file eseguibili (da mettere in path)
|- etc: file di configurazione
|- packs: i vari pacchetti verranno estratti qui
---|- nomepacchetto
------|- bin: eseguibili dal soft-linkare nella bin principale
------|- etc: configurazioni da soft-linkare nella etc principale
------|- data: file dati, pagine html etc etc
------|- scripts
---------|- boot.sh: script da eseguire al boot
---------|- install.sh: script da eseguire al momento dell'installazione
---------|- remove.sh: script da eseguire al momento della rimozione

Ma è possibile fare tutto questo su partizione fat32 ?

Per quanto riguarda il php facendo uno script cgi

#!/bin/sh
export LD_LIBRARY_PATH=/mnt/shares/U
export SCRIPT_FILENAME=prova.php
/mnt/shares/U/php-fcgi -f $SCRIPT_FILENAME

dovrebbe funzionare ed invece dice no dice No input file specified. Quindi credo che sia un problema nel php precompilato che ho preso su openwrt (sia in versione 4 che 5), provo a ricompilarlo modificandolo. Penso che se funziona così sarebbe anche la cosa migliore, così non si tocca mini_httpd

[cionci]

Originariamente inviato da gnommo

Ma è possibile fare tutto questo su partizione fat32 ?

Per i permessi dici ? O per quale altro motivo ?

[cionci]

Altri servizi che potrebbero essere inseriti:
- controllo avanzato del QoS (tramite l'utility tc già inclusa nel firmware)
- UPnP DLNA per lo streaming audio/video tramite rete (http://sourceforge.net/projects/minidlna/)

Io per ora non posso lavorarci. Verso inizio/metà ottobre mi procurerò un DGN2200 e avrò qualche giorno per lavorarci a pieno.

[cionci]

Originariamente inviato da gnommo

Ma è possibile fare tutto questo su partizione fat32 ?

Ah, ora forse ho capito a cosa ti riferisci. In effetti credo che sia impossibile usare ln su fat32. Basta copiare i file al posto di linkarli

[cionci]

Gnommo...intanto che mi arriva il router... Non è che mi puoi inserire un

cat /proc/partitions

con collegato al router un hub usb e due dischi o un solo disco con due partizioni ?
Il DGN3500 ci scrive su NTFS ?