[ninux.org] Nuovo firmware di Ninux
Ciao a tutti, vi segnalo la pagina del wiki: http://wiki.ninux.org/FirmwareNG con elencate le caratteristiche che vorremmo avesse il nostro nuovo firmware. Ho creato una milestone sul trac (https://svn.ninux.org/ninuxdeveloping/roadmap) dove possiamo aprire i ticket e vedere lo stato dello sviluppo. E' gradita la partecipazione di tutti * per sviluppare, testare e discutere insieme le varie soluzioni in modo da fare un firmware usabile da sperimentare (speriamo presto) sui tetti di Roma :-) Ciao, Lorenzo * invece di flames vari
Re: [ninux.org] Nuovo firmware di Ninux
On Mon, 16 Feb 2009 03:00:08 +0100, "OrazioPirataDelloSpazio (Lorenzo)" wrote: > E' gradita la partecipazione di tutti * per sviluppare, testare e > discutere insieme le varie soluzioni in modo da fare un firmware usabile > da sperimentare (speriamo presto) sui tetti di Roma :-) Io posso solo testare, altro, le mie conoscenze, non permettono, ma soprattutto non sui tetti di Roma, perche' la distanza e' troppa :-)) Paride -- http://keyserver.linux.it/pks/lookup?op=get&search=0xCC6CA35C690431D3 Chi è pronto a rinunciare alle proprie libertà fondamentali per comprarsi briciole di temporanea sicurezza non merita né la libertà né la sicurezza.” (Benjamin Franklin - dalla Risposta al Governatore, Assemblea della Pennsylvania, 11 novembre 1755)
Re: [ninux.org] Nuovo firmware di Ninux
OrazioPirataDelloSpazio (Lorenzo) ha scritto:
> Ciao a tutti,
> vi segnalo la pagina del wiki:
>
> http://wiki.ninux.org/FirmwareNG
Bene.
> con elencate le caratteristiche che vorremmo avesse il nostro nuovo
> firmware.
- Autoconfigurazione IP: io a suo tempo componevo gli indirizzi usando i
numeri "Zona" (z), "Cella" (y) e "Nodo" (x) inseriti a mano durante la
prima accensione dell'apparato. ie: 10.z.y.x
Dopodiche' ogni cambiamento ulteriore implicava un meccanismo di
handshaking con i nodi adiacenti (posso diventare 123.11? {no,il nodo
esiste gia' | si, vai}).
Pros: semplice ed efficace; Cons: all'utente rimane il compito di
inserire 4 dati al primo avvio (nickname, location, cella, nodo), di cui
tre obbligatori (cella,nodo; ma zona e cella li avevo fissati tanto
eravamo pochi).
E poi su questo veniva costruito il numero SIP per l'asterisk a bordo.
Ora mi chiedo ... perche' parlate di IPv4? Con IPv6 Strong e Weak DAD
non e' gia' risolto? Qual'e' la necessita' che vi tiene ancorati ad IPv4
anche sull'interfaccia mesh?
- Autoconfigurazione canali: questo deve essere per forza cosi' come e'
descritto sulla wiki; a suo tempo avevo iniziato a testare degli script
per scansionare i neighborhood di ogni nodo e confrontando i risultati
due a due arrivare al canale ottimale per tutta la mesh (ie: quello meno
usato, -n_allocazioni*rssi, da radio terze), ma ho mollato subito dopo.
BTW, sono stati fatti studi con vari algoritmi competitivi (es:
Bayes-Nash) con risultati tremendi (la capacita' trasmissiva risultante
e' una misera frazione di quella possibile) ... l'uso dinamico dello
spettro radio deve essere per forza collaborativo.
> Ho creato una milestone sul trac
> (https://svn.ninux.org/ninuxdeveloping/roadmap) dove possiamo aprire i
> ticket e vedere lo stato dello sviluppo.
Vuole il login.
> E' gradita la partecipazione di tutti * per sviluppare, testare e
> discutere insieme le varie soluzioni in modo da fare un firmware usabile
> da sperimentare (speriamo presto) sui tetti di Roma :-)
Tutti tutti? Allora dovreste integrarvi con chi ha gia' realizzato un
firmware funzionante al 100% (gia' in uso, anche a Roma), free 100%.
Cioe': iniziare subito a concretizzare la mesh (proprio: mettere nodi
sui tetti; si potrebbe iniziare "ieri") e continuare lo sviluppo
partendo da li' (ie: senza reinventare l'acqua calda). Per lo meno
Saverio mi sembra battere sulla concretezza... e questo e' il modo di
essere piu' concreti. O forse c'e' "altro"? Tipo... che ne so...
qualcuno che sfrutta le community pensando di fare poi uno spin-off
commerciale... o una qualche altra attivita' business da far saltare
fuori al momento giusto...
ciao
Michele
Re: [ninux.org] Nuovo firmware di Ninux
>> Ho creato una milestone sul trac >> (https://svn.ninux.org/ninuxdeveloping/roadmap) dove possiamo aprire i >> ticket e vedere lo stato dello sviluppo. > > Vuole il login. risolto, ora non più per problemi di SPAM avevamo chiuso un po' il Trac ... Saverio
Re: [ninux.org] Nuovo firmware di Ninux
ZioPRoTo (Saverio Proto) ha scritto: >>> Ho creato una milestone sul trac >>> (https://svn.ninux.org/ninuxdeveloping/roadmap) dove possiamo aprire i >>> ticket e vedere lo stato dello sviluppo. >> Vuole il login. > > risolto, ora non più > > per problemi di SPAM avevamo chiuso un po' il Trac ... Se-se... dicono tutti cosi'... quando una lista e' moderata... "e' per lo spam" ;) Scherzi a parte, te l'ho segnalato perche' a suo tempo con il trac di Meganetwork un tedesco mi scrisse lamentandosi che la timeline non era visibile. E io (fesso) gli risposi la prima ipotesi che mi passava per la mente ... la verita' - che scoprii subito dopo andando a controllare dove stava il bug - era che mentre integravo wordpress con trac (per fare single-sign-on) avevo fatto un impiccio riguardante i permessi (il python per me era, ed e', un gran mistero della natura; indentazione funzionale... bah... eheh). Fatto sta che si indispetti' e mesi dopo, ad un incontro in verticale, venni a sapere che parte delle community tedesche avevano bollato il progetto come "proprietario". Sono leggerezze che la paranoia fa diventare bombe socionucleari. E' triste, ma e' cosi' ... non importa quanto ragioni in positivo ... basta una virgola e sei fottuto. Fino a che non identifichiamo e isoliamo chi gioca con (e tradisce) la fiducia altrui come metodo di vita (es: Martin Varsavsky, fondatore di FON), bisogna fare attenzione anche a questi piccoli dettagli. ciao Michele
Re: [ninux.org] Nuovo firmware di Ninux
Michele Favara Pedarsi ha scritto:
- Autoconfigurazione IP: io a suo tempo componevo gli indirizzi usando i
numeri "Zona" (z), "Cella" (y) e "Nodo" (x) inseriti a mano durante la
prima accensione dell'apparato. ie: 10.z.y.x
Dopodiche' ogni cambiamento ulteriore implicava un meccanismo di
handshaking con i nodi adiacenti (posso diventare 123.11? {no,il nodo
esiste gia' | si, vai}).
Pros: semplice ed efficace; Cons: all'utente rimane il compito di
inserire 4 dati al primo avvio (nickname, location, cella, nodo), di cui
tre obbligatori (cella,nodo; ma zona e cella li avevo fissati tanto
eravamo pochi).
E poi su questo veniva costruito il numero SIP per l'asterisk a bordo.
Ora mi chiedo ... perche' parlate di IPv4? Con IPv6 Strong e Weak DAD
non e' gia' risolto? Qual'e' la necessita' che vi tiene ancorati ad IPv4
anche sull'interfaccia mesh?
L'idea è di fare una rete fully routable usabile da tutti.
Volenti o nolenti la maggior parte dei sistemi operativi che usa la
gente non è ancora pronta per IPv6 nativamente (sto pensando ad esempio
a WinXP senza l'upgrade IPV6, e alle versioni precedenti).
Per quanto riguarda l'autoconfigurazione degli IP direi che un buon
punto di partenza e' leggersi quello gia' fatto da altro. Ho provato a
sintetizzare qualcosa di NOA-OLSR sulla pagina del wiki e dovrebbe forse
bastarci per il weak-DaD. Per lo strong, secondo me la soluzione che
usano quelli di Robin ci va piu' che bene.
E' gradita la partecipazione di tutti * per sviluppare, testare e
discutere insieme le varie soluzioni in modo da fare un firmware usabile
da sperimentare (speriamo presto) sui tetti di Roma :-)
Tutti tutti? Allora dovreste integrarvi con chi ha gia' realizzato un
firmware funzionante al 100% (gia' in uso, anche a Roma), free 100%.
Infatti partiamo da Openwrt a cui stiamo mandando le patch dei lavori
svolti:
https://dev.openwrt.org/log/packages/?mode=follow_copy
Cioe': iniziare subito a concretizzare la mesh (proprio: mettere nodi
sui tetti; si potrebbe iniziare "ieri") e continuare lo sviluppo
partendo da li' (ie: senza reinventare l'acqua calda). Per lo meno
Saverio mi sembra battere sulla concretezza... e questo e' il modo di
essere piu' concreti.
Prima di salire sui tetti e montare i nodi, vorremmo preparare il
firmware. In particolare è importante anche la capacita' di auto
aggiornarsi.
Altrimenti , una volta installato il fw e' poi difficile ri-flasharlo e
mantenerlo. Sembra che anche avere versioni diverse di OLSR puo' portare
a dei problemi perchè hanno dei problemi di interoperabilita'.
O forse c'e' "altro"? Tipo... che ne so...
qualcuno che sfrutta le community pensando di fare poi uno spin-off
commerciale... o una qualche altra attivita' business da far saltare
fuori al momento giusto...
no
Lorenzo
Re: [ninux.org] Nuovo firmware di Ninux
OrazioPirataDelloSpazio (Lorenzo) ha scritto: > Michele Favara Pedarsi ha scritto: >> - Autoconfigurazione IP: io a suo tempo componevo gli indirizzi usando i >> numeri "Zona" (z), "Cella" (y) e "Nodo" (x) inseriti a mano durante la >> prima accensione dell'apparato. ie: 10.z.y.x .zip.. >> Ora mi chiedo ... perche' parlate di IPv4? Con IPv6 Strong e Weak DAD >> non e' gia' risolto? Qual'e' la necessita' che vi tiene ancorati ad IPv4 >> anche sull'interfaccia mesh? >> > L'idea è di fare una rete fully routable usabile da tutti. E allora IPv6 mi sembra d'obbligo gia' solo per lo spazio di indirizzamento. Sia se prevedi una struttura mesh+ap, sia che prevedi una struttura mesh*(numero_radio) per scalare in dimensione. E' vero, i meccanismi di autoconf dell'IP sono stati pensati per reti fisse; pero' anche le interfacce wireless hanno un mac address (o comunque un ID layer2; e anche venisse a mancare in futuro, glielo si puo' creare con un qualche algoritmo tipo quello di cui parlava Saverio quest'estate... paradosso del compleanno... ma perche' preoccuparsene ora?). Io non ho trafficato con i metodi di transizione previsti nelle rfc; l'ultimo mio esperimento in quel senso risale a piu' di 7 anni fa. Pero' non credo siano componenti software onerose ... voglio dire ... devono solo spacchettare per cambiare un header! Credo che pure il MIPS piu' fetecchia possa sostenere questo onere concorrentemente al demone di ruting e il resto delle componenti imprescindibili. > Volenti o nolenti la maggior parte dei sistemi operativi che usa la > gente non è ancora pronta per IPv6 nativamente (sto pensando ad esempio > a WinXP senza l'upgrade IPV6, e alle versioni precedenti). WinXP non mi sembra un problema enorme. Puoi realizzare una procedura di update triggherabile direttamente dall'interfaccia web (ie: lo script sull'apparato, triggherato via web, scarica l'update su una memoria usb temporanea, o sul terminale stesso, e poi la pulla dentro WinXP); anche teleassistita volendo. Mi preoccupano di piu' i router adsl caghette distribuiti in questi anni dagli operatori ... i terminali mobili con Symbian e Windows Mobile ... ma quelli: (a) andrebbero sul lato AP (e/o ethernet), oppure SE e' previsto l'uso di terminali sul lato mesh (b) basta una componente software aggiuntiva (IPv6, anche solo parziale + demone di routing) per abilitarli; che tra l'altro si puo' sviluppare in un secondo momento, e anchesso pullabile direttamente dall'apparato strutturale (ie: se usi linux stai usando un OS dual stack concorrente; quindi puoi sempre fargli fare una subnet IPv4 da usare proprio SOLO per l'update iniziale del terminale). > Per quanto riguarda l'autoconfigurazione degli IP direi che un buon > punto di partenza e' leggersi quello gia' fatto da altro. Ho provato a > sintetizzare qualcosa di NOA-OLSR sulla pagina del wiki e dovrebbe forse > bastarci per il weak-DaD. Per lo strong, secondo me la soluzione che > usano quelli di Robin ci va piu' che bene. Non le conosco. Ma continuo ad avere la sensazione che o mi sta sfuggendo qualcosa (e chiedo venia se non mi presento alle riunioni in cui certamente ne avete gia' discusso), o voi non avete le idee chiare sull'obiettivo che vi siete dati ... esempio: vuoi collegare in mesh anche i terminali o i soli apparati strutturali (e i terminali sull'AP)? >>> E' gradita la partecipazione di tutti * per sviluppare, testare e >>> discutere insieme le varie soluzioni in modo da fare un firmware usabile >>> da sperimentare (speriamo presto) sui tetti di Roma :-) >>> >> >> Tutti tutti? Allora dovreste integrarvi con chi ha gia' realizzato un >> firmware funzionante al 100% (gia' in uso, anche a Roma), free 100%. >> > Infatti partiamo da Openwrt a cui stiamo mandando le patch dei lavori > svolti: > https://dev.openwrt.org/log/packages/?mode=follow_copy Ottimo. OpenWrt e' certamente La base comune di codice tecnicamente migliore e socialmente piu' onesta. >> Cioe': iniziare subito a concretizzare la mesh (proprio: mettere nodi >> sui tetti; si potrebbe iniziare "ieri") e continuare lo sviluppo >> partendo da li' (ie: senza reinventare l'acqua calda). Per lo meno >> Saverio mi sembra battere sulla concretezza... e questo e' il modo di >> essere piu' concreti. > Prima di salire sui tetti e montare i nodi, vorremmo preparare il > firmware. In particolare è importante anche la capacita' di auto > aggiornarsi. > Altrimenti , una volta installato il fw e' poi difficile ri-flasharlo e > mantenerlo. Sembra che anche avere versioni diverse di OLSR puo' portare > a dei problemi perchè hanno dei problemi di interoperabilita'. Chiaro ... ma ti sto dicendo che il firmware (openwrt+olsr+batman) c'e' gia' e il lead developer e' un romano che 30 anni fa lavorava con Postel (ie: (a) e' tecnicamente piu' preparato di me, te, Saverio, Clauz, Nino e tutto il cucuzzaro messo insieme; (b) e' trusted perche' ha gia' dato al public domain strumenti d'eccezione ... e a livello algoritmico, non di inter
