|
Dimensione: 895
Commento:
|
Dimensione: 3739
Commento:
|
| Le cancellazioni sono segnalate in questo modo. | Le aggiunte sono segnalate in questo modo. |
| Linea 4: | Linea 4: |
| 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]]. |
|
| Linea 5: | Linea 7: |
| * 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]]. | * [[#autoconf_ip|Autoconfigurazione IP]]: Ogni apparato accendendosi deve autoconfigurare il proprio indirizzo IP in modo da non andare in conflitto con gli altri presenti nella rete |
| Linea 7: | Linea 9: |
| * 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. | * [[#autoconf_chan|Autoconfigurazione canali]]: Ogni apparato deve autoconfigurare il canale radio in modo da comunicare con gli altri apparati della mesh |
| Linea 9: | Linea 11: |
| * [[#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". |
* [[#splash| 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. * [[#fw_update| Aggiornamento automatico del Firmware]]: Pensare ad un meccanismo per aggiornare in maniera automatica i firmware dei vari apparati. <<Anchor(autoconf_ip)>> === 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]]. 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. <<BR>> '''NOA OLSR''' [[http://hipercom.inria.fr/noa-olsr/draft-mase-manet-autoconf-noaolsr-00.txt|Noa olsr]] si basa su un sistema di DaD che possiamo riassumere cosi', facendo una distinzione per tre casi base: * NODI IN VISIBILITA' RADIO: Se un nodo riceve un pacchetto di HELLO da un vicino che ha il suo stesso IP, allora c'è un conflitto. * NODI A 2 HOP: Se un nodo riceve due HELLO da due vicini diversi ma con lo stesso IP, rileva un conflitto. * NODI A PIU' DI DUE HOP: In questo caso distinguiamo più sottocasi. * Entrambi i nodi sono TC originator: Se un nodo riceve un TC originato da un altro nodo col suo stesso IP, allora c'e' stato un conflitto. I nodi intermedi posso verificare se ci sono discrepanze con i numeri di sequenza dei TC che devono rimanere gli stessi nel tempo. * Entrambi i nodi non sono TC originato: Entrambi i nodi invieranno i TC attraverso i loro MPR che risulteranno come TC originator. Se un nodo riceve un TC con il suo IP ma con originator un MPR che non è il suo, viene rilevato un conflitto. Oppure un nodo che vede gli hello dell'MPR del nodo A vicino di B, se non vede che nel tc di B c'e' il nodo A, rileva un conflitto. <<BR>> ... (da continuare) ... <<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! Aggiungete pure le caratteristiche che vorreste veder sviluppate nel nuovo firmware, dopo averne parlato a riunione o in mailing list.
Lo stato di sviluppo delle varie features puo' essere monitorato dal nostro track.
Autoconfigurazione IP: Ogni apparato accendendosi deve autoconfigurare il proprio indirizzo IP in modo da non andare in conflitto con gli altri presenti nella 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
Prendere spunto da Robin per l'autoconfigurazione degli indirizzi IPv4, ed implementare un meccanismo di Strong e Weak Duplicate Address Detection. Un punto di partenza potrebbe essere anche consultare documenti su olsr ,vedere NOA OLSR e altri articoli presenti in letteratura.
NOA OLSR Noa olsr si basa su un sistema di DaD che possiamo riassumere cosi', facendo una distinzione per tre casi base:
- NODI IN VISIBILITA' RADIO: Se un nodo riceve un pacchetto di HELLO da un vicino che ha il suo stesso IP, allora c'è un conflitto.
- NODI A 2 HOP: Se un nodo riceve due HELLO da due vicini diversi ma con lo stesso IP, rileva un conflitto.
- NODI A PIU' DI DUE HOP: In questo caso distinguiamo più sottocasi.
- Entrambi i nodi sono TC originator: Se un nodo riceve un TC originato da un altro nodo col suo stesso IP, allora c'e' stato un conflitto. I nodi intermedi posso verificare se ci sono discrepanze con i numeri di sequenza dei TC che devono rimanere gli stessi nel tempo.
- Entrambi i nodi non sono TC originato: Entrambi i nodi invieranno i TC attraverso i loro MPR che risulteranno come TC originator. Se un nodo riceve un TC con il suo IP ma con originator un MPR che non è il suo, viene rilevato un conflitto. Oppure un nodo che vede gli hello dell'MPR del nodo A vicino di B, se non vede che nel tc di B c'e' il nodo A, rileva un conflitto.
... (da continuare) ...
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".