= 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 [[https://svn.ninux.org/ninuxdeveloping/roadmap|nostro track]]. ||obiettivo ||stato ||descrizione || ||[[#autoconf_ip|Autoconfigurazione IP]] ||< 50%)>> ||Ogni apparato deve autoconfigurarsi i settaggi relativi alla configurazione di rete || ||[[#autoconf_chan|Autoconfigurazione canali]] ||< 10%)>> ||Ogni apparato deve autoconfigurare il canale radio in modo da comunicare con gli altri apparati della mesh || ||[[#splash|Splash Page]] ||< 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]] ||< 10%)>> ||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-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 <
> 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 <
> 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]] <
> <> === 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.<
> 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]]". <
> Ecco come installare il tutto, ovvero i comandi da dare sull'access point. <
> '''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 }}} <
> '''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 }}} <
> '''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", } }}} <
> '''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 <> === Aggiornamento automatico del Firmware === Meccanismi per la gestione degli apparati: flashing di un firmware da remoto "fonera style".