Italiano English
Modifica History Actions

Differenze per "FirmwareNG"

Differenze tra le versioni 1 e 12 (in 11 versioni)
Versione 1 del 2009-02-16 01:36:31
Dimensione: 895
Commento:
Versione 12 del 2009-03-20 21:50:53
Dimensione: 5012
Commento:
Le cancellazioni sono segnalate in questo modo. Le aggiunte sono segnalate in questo modo.
Linea 3: Linea 3:


Linea 4: Linea 7:
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 5: Linea 10:
  * Autoconfigurazione IP: 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]]. ||obiettivo || stato ||descrizione||
||[[#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 7: Linea 16:
  * 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, meccanismo più simpatici per la scelta del canale migliore potrebbero essere definiti.
Linea 9: Linea 17:
  * [[#captive|Captive-Portal]] e Agreement: provare il captive portal utilizzato dagli amici di Unimos. Vedere se è possibile integrare un meccanismo di chat (ad esempio sfruttando il server Prosody).
  * Meccanismi per la gestione degli apparati: flashing di un firmware da remoto "fonera style".
<<Anchor(autoconf_ip)>>
=== 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).<<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

<<BR>>
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:172.17.2.56;ath2:172.17.6.98"
}}}

==== 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>>


<<Anchor(autoconf_chan)>>
=== 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.

<<Anchor(splash)>>
=== Splash Page ===
Realizzare una splash page in Luci/Lua ed integrarla con un sistema di chat.<<BR>>
Al momento è gia' stato portato il server jabber [[http://prosody.im/|Prosody]] su OpenWRT, mentre siamo a buon punto con lo sviluppo del pacchetto della splash page che si chiama "[[https://svn.ninux.org/ninuxdeveloping/browser/packages/nowolfsplash|nowolfsplash]]".


<<Anchor(fw_update)>>
=== Aggiornamento automatico del Firmware ===
Meccanismi per la gestione degli apparati: flashing di un firmware da remoto "fonera style".

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

Autoconfigurazione IP

Ogni apparato deve autoconfigurarsi i settaggi relativi alla configurazione di rete

Autoconfigurazione canali

Ogni apparato deve autoconfigurare il canale radio in modo da comunicare con gli altri apparati della mesh

Splash Page

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.

Aggiornamento automatico del Firmware

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:172.17.2.56;ath2:172.17.6.98"

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

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".