|
Dimensione: 3178
Commento:
|
Dimensione: 5011
Commento:
|
| Le cancellazioni sono segnalate in questo modo. | Le aggiunte sono segnalate in questo modo. |
| Linea 7: | Linea 7: |
| Ecco cosa vorremmo dal nuovo firmware di Ninux! Aggiungete pure le caratteristiche che vorreste veder sviluppate nel nuovo firmware, dopo averne parlato a riunione o in mailing list. <<BR>> Lo stato di sviluppo delle varie features puo' essere [[https://svn.ninux.org/ninuxdeveloping/roadmap|monitorato dal nostro track]]. |
Ecco cosa vorremmo dal nuovo firmware di Ninux! Se avete delle richieste per alcune caratteristiche che vorreste veder sviluppate nel nuovo firmware, parlatene a riunione o in mailing list. <<BR>> I ticket aperti per i progetti attuali sono visibili sul [[https://svn.ninux.org/ninuxdeveloping/roadmap|nostro track]]. |
| Linea 11: | Linea 11: |
| ||[[#autoconf_ip|Autoconfigurazione IP]] || <<ProgressBar(<bgcolor="orange"><bgcolor="lightgrey"> 20%)>> ||Ogni apparato accendendosi deve autoconfigurare il proprio indirizzo IP in modo da non andare in conflitto con gli altri presenti nella rete|| || [[#autoconf_chan|Autoconfigurazione canali]] || <<ProgressBar(<bgcolor="orange"><bgcolor="lightgrey"> 10%)>> ||Ogni apparato deve autoconfigurare il canale radio in modo da comunicare con gli altri apparati della mesh|| || [[#splash| Splash Page]] || <<ProgressBar(<bgcolor="orange"><bgcolor="lightgrey"> 75%)>> ||Gli utenti collegati alla rete ninux devono visualizzare una pagina iniziale (splash page) che li informi su chi siamo e perchè facciamo una cosa del genere.|| || [[#fw_update| Aggiornamento automatico del Firmware]] || <<ProgressBar(<bgcolor="orange"><bgcolor="lightgrey"> 10%)>> ||Pensare ad un meccanismo per aggiornare in maniera automatica i firmware dei vari apparati.|| |
||[[#autoconf_ip|Autoconfigurazione IP]] || <<ProgressBar(<bgcolor="orange"><bgcolor="lightgrey"> 50%)>> ||Ogni apparato deve autoconfigurarsi i settaggi relativi alla configurazione di rete|| || [[#autoconf_chan|Autoconfigurazione canali]] || <<ProgressBar(<bgcolor="red"><bgcolor="lightgrey"> 10%)>> ||Ogni apparato deve autoconfigurare il canale radio in modo da comunicare con gli altri apparati della mesh|| || [[#splash| Splash Page]] || <<ProgressBar(<bgcolor="green"><bgcolor="lightgrey"> 75%)>> ||Gli utenti collegati alla rete ninux devono visualizzare una pagina iniziale (splash page) che li informi su chi siamo e perchè facciamo una cosa del genere.|| || [[#fw_update| Aggiornamento automatico del Firmware]] || <<ProgressBar(<bgcolor="red"><bgcolor="lightgrey"> 10%)>> ||Pensare ad un meccanismo per aggiornare in maniera automatica i firmware dei vari apparati.|| |
| Linea 19: | Linea 19: |
| Prendere spunto da Robin per l'autoconfigurazione degli indirizzi IPv4, ed implementare un meccanismo di Strong e Weak [[http://www.olsr.org/docs/report_html/node178.html|Duplicate Address Detection]]. Un punto di partenza potrebbe essere anche consultare [[http://www.olsr.org/docs/report.pdf|documenti su olsr]] ,vedere [[http://hipercom.inria.fr/noa-olsr/| NOA OLSR]] e [[http://www.emmanuelbaccelli.org/publications/wpmc_2005.pdf|altri articoli]] presenti in letteratura. In [[http://tools.ietf.org/html/draft-laouiti-manet-olsr-address-autoconf-01#section-3.2| draft-laouiti-manet-olsr-address-autoconf-01]] è presentato un sistema di DaD semplice ma attivo. Un DaD passivo invece è descritto in [[http://manetautoconf.online.fr/Blog/wp-content/draft-weniger-autoconf-pdad-olsr-01.txt| draft-weniger-autoconf-pdad-olsr-01]] |
Creare un plugin per OLSR che si occupi di autoconfigurare gli indirizzi IPv4 dei nodi attraverso meccanismi di Duplicate Address Detection (vedi sotto).<<BR>> La filosofia progettuale prevede la coesistenza tra nodi e interfacce configurate automaticamente e altre configurate manualmente. * All'avvio configura in modalità ''ad-hoc''tutte le interfacce su cui è stato lanciato OLSR ad eccezione di quelle elencate nel parametro exclude-if * Assegna ad ogni interfaccia da autoconfigurare, un indirizzo IP del tipo 172.17.X.Y, dove X.Y sono gli ultimi 2 byte del MAC. I primi 256 valori pero' sono riservati a configurazioni manuali. Nel caso dovessero coincidere con i valori dell'ultimo byte del mac, si utilizza un IP casuale * Configura il conf di dnsmasq per per rilasciare indirizzi IP nella classe 1.X.Y.0/24 con ''lease-time'' = ''interval'', dove X e Y sono presi dagli ultimi due byte dell'indirizzo primario del nodo. * Annuncia le HNA scritte in olsrd.conf e le HNA autogenerate, e tutte le interfacce di rete su cui è attivo OLSR * In caso riceva un MAD con unique address maggiore che collide con una delle sue interfacce, il plugin deve cambiare l'ip dell interfaccia * ogni volta che il plugin effettua un cambio di indirizzo IP di un interfaccia, lo scrive nel parametro ''saved-conf'', in modo da ricordarslo al prossimo reboot |
| Linea 22: | Linea 29: |
| Parametri del Plugin {{{ PlParam "interval" "3.4" PlParam "unique_addr" "" PlParam "mode" "auto" PlParam "exclude-if" "ath1" PlParam "dnsmasq-autoconf" "ath1" PlParam "saved-conf" "ath1" }}} ==== Duplicate Address Detection ==== In [[http://tools.ietf.org/html/draft-laouiti-manet-olsr-address-autoconf-01#section-3.2| draft-laouiti-manet-olsr-address-autoconf-01]] è presentato un sistema di DaD semplice ma attivo che utilizza dei nuovi messaggi OLSR (MAD). Un DaD passivo invece è descritto in <<BR>> Per quale motivo utilizzare i MAD e non guardare semplicamente gli HELLO/TC/MID: * I tempi sono diversi. I MAD verranno emessi con meno frequenza dei topology change * I nodi non sono costretti a parsare tutti i TC/HELLO/MID che vedono * I nodi non sanno distiguere un '''proprio''' TC inviato in flooding da quello generato da un nodo diverso ma con stesso indirizzo IP Per ulteriori argomentazioni, consultare [[http://www.olsr.org/docs/report.pdf|documenti su olsr]] ,vedere [[http://hipercom.inria.fr/noa-olsr/| NOA OLSR]] [[http://tools.ietf.org/html/draft-laouiti-manet-olsr-address-autoconf-01#section-3.2| draft-laouiti-manet-olsr-address-autoconf-01]] e [[http://manetautoconf.online.fr/Blog/wp-content/draft-weniger-autoconf-pdad-olsr-01.txt| draft-weniger-autoconf-pdad-olsr-01]] <<BR>> Filosofia del plugin "Zero |
New generation Ninux Firmware
Wishlist
Ecco cosa vorremmo dal nuovo firmware di Ninux! Se avete delle richieste per alcune caratteristiche che vorreste veder sviluppate nel nuovo firmware, parlatene a riunione o in mailing list.
I ticket aperti per i progetti attuali sono visibili sul nostro track.
obiettivo |
stato |
descrizione |
||
|
Ogni apparato deve autoconfigurarsi i settaggi relativi alla configurazione di rete |
|||
|
Ogni apparato deve autoconfigurare il canale radio in modo da comunicare con gli altri apparati della mesh |
|||
|
Gli utenti collegati alla rete ninux devono visualizzare una pagina iniziale (splash page) che li informi su chi siamo e perchè facciamo una cosa del genere. |
|||
|
Pensare ad un meccanismo per aggiornare in maniera automatica i firmware dei vari apparati. |
Autoconfigurazione IP
Creare un plugin per OLSR che si occupi di autoconfigurare gli indirizzi IPv4 dei nodi attraverso meccanismi di Duplicate Address Detection (vedi sotto).
La filosofia progettuale prevede la coesistenza tra nodi e interfacce configurate automaticamente e altre configurate manualmente.
All'avvio configura in modalità ad-hoctutte le interfacce su cui è stato lanciato OLSR ad eccezione di quelle elencate nel parametro exclude-if
- Assegna ad ogni interfaccia da autoconfigurare, un indirizzo IP del tipo 172.17.X.Y, dove X.Y sono gli ultimi 2 byte del MAC. I primi 256 valori pero' sono riservati a configurazioni manuali. Nel caso dovessero coincidere con i valori dell'ultimo byte del mac, si utilizza un IP casuale
Configura il conf di dnsmasq per per rilasciare indirizzi IP nella classe 1.X.Y.0/24 con lease-time = interval, dove X e Y sono presi dagli ultimi due byte dell'indirizzo primario del nodo.
- Annuncia le HNA scritte in olsrd.conf e le HNA autogenerate, e tutte le interfacce di rete su cui è attivo OLSR
- In caso riceva un MAD con unique address maggiore che collide con una delle sue interfacce, il plugin deve cambiare l'ip dell interfaccia
ogni volta che il plugin effettua un cambio di indirizzo IP di un interfaccia, lo scrive nel parametro saved-conf, in modo da ricordarslo al prossimo reboot
Parametri del Plugin
PlParam "interval" "3.4" PlParam "unique_addr" "" PlParam "mode" "auto" PlParam "exclude-if" "ath1" PlParam "dnsmasq-autoconf" "ath1" PlParam "saved-conf" "ath1"
Duplicate Address Detection
In draft-laouiti-manet-olsr-address-autoconf-01 è presentato un sistema di DaD semplice ma attivo che utilizza dei nuovi messaggi OLSR (MAD). Un DaD passivo invece è descritto in
Per quale motivo utilizzare i MAD e non guardare semplicamente gli HELLO/TC/MID:
- I tempi sono diversi. I MAD verranno emessi con meno frequenza dei topology change
- I nodi non sono costretti a parsare tutti i TC/HELLO/MID che vedono
I nodi non sanno distiguere un proprio TC inviato in flooding da quello generato da un nodo diverso ma con stesso indirizzo IP
Per ulteriori argomentazioni, consultare documenti su olsr ,vedere NOA OLSR draft-laouiti-manet-olsr-address-autoconf-01 e draft-weniger-autoconf-pdad-olsr-01
Filosofia del plugin "Zero
Autoconfigurazione canali
L'idea più semplice è di fare una scansione alla ricerca di una rete con un dato essid. Se non è presente, allora l'AP va su un canale predefinito (ad es. il 6). Tempo permettendo, potremmo pensare a dei meccanismi più simpatici per la scelta del canale migliore.
Splash Page
Realizzare una splash page in Luci/Lua ed integrarla con un sistema di chat.
Al momento è gia' stato portato il server jabber Prosody su OpenWRT, mentre siamo a buon punto con lo sviluppo del pacchetto della splash page che si chiama "nowolfsplash".
Aggiornamento automatico del Firmware
Meccanismi per la gestione degli apparati: flashing di un firmware da remoto "fonera style".