= New generation Ninux Firmware =
<<TableOfContents>>

== 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. <<BR>> I ticket aperti per i progetti attuali sono visibili sul [[https://svn.ninux.org/ninuxdeveloping/roadmap|nostro track]].
||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"> 90%)>> ||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. ||




<<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 ricordarselo 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>> E' 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]]".  <<BR>> Ecco come installare il tutto, ovvero i comandi da dare sull'access point. <<BR>> '''Installare Prosody (il server jabber)'''

{{{
cd /tmp
wget http://test.ninux.org/~orazio/bin/packages/mips/prosody_0.4.0-1_mips.ipk
wget http://test.ninux.org/~orazio/bin/packages/mips/libidn_1.12-1_mips.ipk
wget http://test.ninux.org/~orazio/bin/packages/mips/luaexpat_1.1-1_mips.ipk
wget http://test.ninux.org/~orazio/bin/packages/mips/luasocket_2.0.2-2_mips.ipk
wget http://test.ninux.org/~orazio/bin/packages/mips/luasec_0.3-1_mips.ipk
wget http://test.ninux.org/~orazio/bin/packages/mips/libexpat_1.95.8-1_mips.ipk
wget http://test.ninux.org/~orazio/bin/packages/mips/libopenssl_0.9.8i-3_mips.ipk
wget http://test.ninux.org/~orazio/bin/packages/mips/zlib_1.2.3-5_mips.ipk
wget http://test.ninux.org/~orazio/bin/packages/mips/liblua_5.1.4-2_mips.ipk
ipkg install zlib_1.2.3-5_mips.ipk liblua_5.1.4-2_mips.ipk libidn_1.12-1_mips.ipk libopenssl_0.9.8i-3_mips.ipk libexpat_1.95.8-1_mips.ipk luaexpat_1.1-1_mips.ipk luasocket_2.0.2-2_mips.ipk luasec_0.3-1_mips.ipk prosody_0.4.0-1_mips.ipk
}}}
<<BR>> '''Installare NoWolfSplash (il captive portal)'''

{{{
cd /tmp
wget http://test.ninux.org/~orazio/bin/packages/mips/nowolfsplash_0.1-1_mips.ipk
wget http://test.ninux.org/~orazio/bin/packages/mips/at_3.1.10ubuntu4-2_mips.ipk
wget http://test.ninux.org/~orazio/bin/packages/mips/libelf_0.8.10-1_mips.ipk
opkg install libelf_0.8.10-1_mips.ipk at_3.1.10ubuntu4-2_mips.ipk nowolfsplash_0.1-1_mips.ipk
}}}
<<BR>> '''Configurare NoWolfSplash'''

 * Cambiare la porta di default del server http di busybox, modificando il file /etc/config/httpd nel seguente modo

{{{
config 'httpd'
        option 'port' '8080'
        option 'home' '/www'
}}}
 * in /usr/lib/prosody/modules/mod_httpserver.lua modificare l'http_base e la porta su cui gira il server http di prosody:
 {{{
local http_base = "/www";
}}}

e

{{{
httpserver.new{ port = 80, base = "files", handler = handle_request, ssl = false}
}}}
 * il file di configurazione di prosody (/etc/prosody/prosody.cfg.lua) deve assomigliare a una cosa del genere: http://test.ninux.org/~orazio/prosody.cfg.lua

http://IP_ROUTER/files/luci-static/muckl/index.html

Altre configurazioni "standard" del router:

 * NON mettere l'access point in modalità bridge, farlo lavorare da router. Basta andare ad editare i file /etc/config/network e /etc/config/wireless sulla falsa riga di questi due esempi: [[https://svn.ninux.org/ninuxdeveloping/browser/packages/zzz-ninux-ipkg-atheros/files/etc/config/network|network]] e [[https://svn.ninux.org/ninuxdeveloping/browser/packages/zzz-ninux-ipkg-atheros/files/etc/config/wireless|wireless]]
 * impostate se volete il dhcp server per dare indirizzi IP ai client che si connettono (altrimenti, per provarlo potete assegnarvi manualmente un IP coerente con la sottorete che avete settato)
 * fermate il firewall di openwrt (/etc/init.d/firewall stop) e date una regola di masquerading (iptables -t nat -A POSTROUTING -j MASQUERADE)
 * modificate il file /etc/init.d/nowolfsplash per inserire l'IP del vostro AP al posto di GATEWAY_IP
 * avviate lo script con /etc/init.d/nowolfsplash start

'''Installare Muckl (la chat javascript)'''

 * copiare il file http://test.ninux.org/~orazio/muckl_ninux.tar in temp e scompattarlo in /www/luci-static/muckl
 * aggiungere il seguente account su prosody creando il file /etc/prosody/data/localhost/accounts/muckl.dat fatto cosi':

{{{
return {
        ["password"] = "muckl",
}
}}}
<<BR>> '''Spiegazione''' Dopo tutti questi passaggi :-) ciò che otteniamo è questo:

 * Una client si associa al nostro access point ed effettua la richiesta di una pagina web
 * iptablel redirige la richiesta sulla porta 8082 dell'access point
 * su questa porta c'e' lo script "nowolfsplash" che effettua un HTTP redirect sulla porta 8080 sempre dell'access point, dove il visitatore trova la splash page
 * una volta che avra' accettato, uno script in LUCI prende il MAC address del visitatore e lo abilita alla navigazione redirigendolo su google e aprendo una chat in un frame. La chat è disponibile sulla porta 80 del router

<<Anchor(fw_update)>>

=== Aggiornamento automatico del Firmware ===
Meccanismi per la gestione degli apparati: flashing di un firmware da remoto "fonera style".