Re: [Ninux-Wireless] Testing firmware eigennet con batman-adv = 2013.0.0
Mi son messo a fare debug, ho provato tutte e 4 le combinazioni con eth_mesh e eth_clients attivi o meno. imho, ordex può aiutarci :D La configurazione con eth_mesh=true ed eth_clients= true non funziona. Tutte le altre hanno il comportamento desiderato. Tale configurazione produce il risultato di seguito sulle interfaccie: root@cairo:~# batctl if wlan0: active root@cairo:~# brctl show bridge name bridge id STP enabled interfaces br-clients 8000.dc9fdb0bafb9 no eth0 bat0 root@cairo:~# ip a s 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast master br-clients state UP qlen 1000 link/ether dc:9f:db:0b:af:b9 brd ff:ff:ff:ff:ff:ff 4: br-clients: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue state UP link/ether dc:9f:db:0b:af:b9 brd ff:ff:ff:ff:ff:ff inet 192.168.1.21/24 brd 192.168.1.255 scope global br-clients inet6 2001:470:6ae4:1000:0:dc9f:db0b:afb9/64 scope global valid_lft forever preferred_lft forever inet6 fe80::de9f:dbff:fe0b:afb9/64 scope link valid_lft forever preferred_lft forever 5: wlan0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1528 qdisc mq state UP qlen 1000 link/ether dc:9f:db:0a:af:b9 brd ff:ff:ff:ff:ff:ff inet6 fe80::de9f:dbff:fe0a:afb9/64 scope link valid_lft forever preferred_lft forever 6: bat0: BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP mtu 1500 qdisc noqueue master br-clients state UNKNOWN link/ether 12:5d:16:19:49:56 brd ff:ff:ff:ff:ff:ff root@cairo:~# grep eth_ /etc/config/eigennet option eth_mesh 'true' option eth_clients 'true' per me è bug. 2013/5/15 Gioacchino Mazzurco g...@eigenlab.org On Tuesday 14 May 2013 23:33:05 Luca Postregna wrote: scusa se insisto, ma con il tuo firmware attivando o meno in /etc/config/eigennet la variabile eth_mesh, mettendo il bootmode a 1, al riavvio il file /etc/config/network non cambia di una cippa. è normale? si ora e' normale ( BLA II ) perche' c'e' eth_client attivato, se disattivi eth_client e cambi eth mesh dovresti vedere /etc/config/network cambiare ;) Anche a me non tornava per un bel po' sta storia me lo hanno dovuto spiegare di persona come funziona per capirlo :P -- luca.postregna.name twitter.com/lucapost ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Testing firmware eigennet con batman-adv = 2013.0.0
Con la vecchia conf, il bridge in bat0, su eth0 avevo sia meschina che client insieme. Se questo non è più possibile, allora due opzioni nel firmware ritennero sono superflue e creano confusione. On May 15, 2013 2:43 PM, Antonio Quartulli or...@autistici.org wrote: On Wed, May 15, 2013 at 02:24:03PM +0200, Luca Postregna wrote: Mi son messo a fare debug, ho provato tutte e 4 le combinazioni con eth_mesh e eth_clients attivi o meno. imho, ordex puA^2 aiutarci :D La configurazione con eth_mesh=true ed eth_clients= true non funziona. Tutte le altre hanno il comportamento desiderato. Tale configurazione produce il risultato di seguito sulle interfaccie: Credo che il tassello mancante sia che Luca non ha detto che lui vuole usare la eth sia per i client che per fare mesh. Da quello che ho capito fino ad ora non credo che il firmware supporti questa opzione in questo momento, per quello non produce il risultato che Luca si aspetta. Ciao -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto Che Guevara ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Testing firmware eigennet con batman-adv = 2013.0.0
On Wednesday 15 May 2013 16:42:43 Antonio Quartulli wrote: L'alternativa è usare la rete cablata per fare mesh in senso proprio e quindi dare eth0 in pasto a batman-adv come faresti per una interfaccia wireless (ed in questo caso BLA2 non c'entra nulla). quindi in realta' adesso quello che si fa e' dare in pasto eth0 nonostante sia bridgiata invece del bridge?? io voglio che batman-adv usi la ethernet anche per far transitare pacchetti oltre che per i client attaccati li pensavo che usarla come backbone svolgesse questa funzione Queste son le due possibilità..adesso onestamente ho perso di vista quello che vorrebbe fare Luca. Forse lui propende per la seconda soluzione perchè vorrebbe usare la LAN come un possibile link della rete mesh..? lo vorrei fare anche io pero' avevo capito che se tu lo bridgi con bat0 automaticamente BLA II vede se ci sono altri nodi attaccati li e lo usano quasi come se fosse una mesh con delle piccole differenze ( ovvero che epr esempio non si propagano certe informazioni tipo il gw_mode ) signature.asc Description: This is a digitally signed message part. ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Testing firmware eigennet con batman-adv = 2013.0.0
On Wed, May 15, 2013 at 04:51:32PM +0200, Gioacchino Mazzurco wrote:
On Wednesday 15 May 2013 16:42:43 Antonio Quartulli wrote:
L'alternativa è usare la rete cablata per fare mesh in senso proprio e
quindi dare eth0 in pasto a batman-adv come faresti per una interfaccia
wireless (ed in questo caso BLA2 non c'entra nulla).
quindi in realta' adesso quello che si fa e' dare in pasto eth0 nonostante
sia
bridgiata invece del bridge??
io voglio che batman-adv usi la ethernet anche per far transitare pacchetti
oltre che per i client attaccati li
pensavo che usarla come backbone svolgesse questa funzione
Queste son le due possibilità..adesso onestamente ho perso di vista quello
che vorrebbe fare Luca. Forse lui propende per la seconda soluzione perchè
vorrebbe usare la LAN come un possibile link della rete mesh..?
lo vorrei fare anche io pero' avevo capito che se tu lo bridgi con bat0
automaticamente BLA II vede se ci sono altri nodi attaccati li e lo usano
quasi come se fosse una mesh con delle piccole differenze ( ovvero che epr
esempio non si propagano certe informazioni tipo il gw_mode )
No. sulla LAN di backbone non passa alcun OGM, solo i pacchetti di BLA2 che
istruiscono i nodi a tagliare i loop.
Se un nodo A bridgato nella LAN deve parlare con un nodo B _non_ bridgato nella
LAN, proverà a contattarlo direttamente usando la mesh, la LAN non viene
considerata.
Per usare una interfaccia per fare routing devi necessariamente dargliela in
pasto (batctl if add ifname0).
Quindi teoricamente si, devi mettere l'interfaccia eth0 sia nel bridge che in
batman-adv.
Però, dato che questa configurazione mischierebbe un po il traffico (e per
altro diventerà una configurazione illegale da batman-adv-2013.3.0 perchè il
kernel non vuole che un'interfaccia abbia più di un master: quindi o bat0 o
br0), il mio consiglio in questo scenario è di creare una VLAN, diciamo eth0.10,
e di usare questa per la mesh.
Quindi ti troverai bat0={eth0.10} e br0={bat0,eth0} che, se disegni tutto su un
foglio, è meno complicato di quanto sembri a scriverlo via email :P
Ciao!
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto Che Guevara
signature.asc
Description: Digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Testing firmware eigennet con batman-adv = 2013.0.0
On Wed, May 15, 2013 at 04:51:32PM +0200, Gioacchino Mazzurco wrote: On Wednesday 15 May 2013 16:42:43 Antonio Quartulli wrote: L'alternativa è usare la rete cablata per fare mesh in senso proprio e quindi dare eth0 in pasto a batman-adv come faresti per una interfaccia wireless (ed in questo caso BLA2 non c'entra nulla). quindi in realta' adesso quello che si fa e' dare in pasto eth0 nonostante sia bridgiata invece del bridge?? io voglio che batman-adv usi la ethernet anche per far transitare pacchetti oltre che per i client attaccati li pensavo che usarla come backbone svolgesse questa funzione Queste son le due possibilità..adesso onestamente ho perso di vista quello che vorrebbe fare Luca. Forse lui propende per la seconda soluzione perchè vorrebbe usare la LAN come un possibile link della rete mesh..? lo vorrei fare anche io pero' avevo capito che se tu lo bridgi con bat0 automaticamente BLA II vede se ci sono altri nodi attaccati li e lo usano quasi come se fosse una mesh con delle piccole differenze ( ovvero che epr esempio non si propagano certe informazioni tipo il gw_mode ) Comunque credo che - qui http://www.open-mesh.org/projects/batman-adv/wiki/Bridge-loop-avoidance-II - qui http://www.open-mesh.org/projects/batman-adv/wiki/Bridge-loop-avoidance-Testcases - qui http://www.open-mesh.org/projects/batman-adv/wiki/Bridge-loop-avoidance-Protocol - e qui http://www.open-mesh.org/projects/batman-adv/wiki/Bridge-loop-avoidance ci fosse sufficiente documentazione ufficiale a riguardo, con tanto di disegnini :P Ciao! -- Antonio Quartulli ..each of us alone is worth nothing.. Ernesto Che Guevara signature.asc Description: Digital signature ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Testing firmware eigennet con batman-adv = 2013.0.0
On Wednesday 15 May 2013 17:00:27 Antonio Quartulli wrote: Però, dato che questa configurazione mischierebbe un po il traffico (e per altro diventerà una configurazione illegale da batman-adv-2013.3.0 perchè il kernel non vuole che un'interfaccia abbia più di un master: quindi o bat0 o br0), il mio consiglio in questo scenario è di creare una VLAN, diciamo eth0.10, e di usare questa per la mesh. quindi cosi' fovrebbe funzionare, luca puoi fare una patch e testarla con questo setup ? e poi magari fai una merge request su gitorious ? signature.asc Description: This is a digitally signed message part. ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Testing firmware eigennet con batman-adv = 2013.0.0
ma voi due tutti questi discorsi non potevate farli prima di usarmi come cavia? :DDD cmq, con la versione attuale di eigennet, cioè mettendo eth0 dentro il bridge dei client ed allo stesso tempo mettere eth0 in bat0, il risultato che si ottiene è che la mesh non funziona ma funzionano solo i client. ora faccio qualche test con le vlan. credo che metterò eth0 dentro bat0, e poi una vlan eth0.1 dentro il bridge dei client. in questo modo tutti possono mettere eth0 senza complicanze in bat0. ordex dici che così funziona? 2013/5/15 Gioacchino Mazzurco g...@eigenlab.org On Wednesday 15 May 2013 17:00:27 Antonio Quartulli wrote: Però, dato che questa configurazione mischierebbe un po il traffico (e per altro diventerà una configurazione illegale da batman-adv-2013.3.0 perchè il kernel non vuole che un'interfaccia abbia più di un master: quindi o bat0 o br0), il mio consiglio in questo scenario è di creare una VLAN, diciamo eth0.10, e di usare questa per la mesh. quindi cosi' fovrebbe funzionare, luca puoi fare una patch e testarla con questo setup ? e poi magari fai una merge request su gitorious ? -- luca.postregna.name twitter.com/lucapost ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Testing firmware eigennet con batman-adv = 2013.0.0
On Wednesday 15 May 2013 18:21:57 Luca Postregna wrote: ma voi due tutti questi discorsi non potevate farli prima di usarmi come cavia? :DDD e ce li eramavo fatti un po ma non ci si era capiti :| ora faccio qualche test con le vlan. credo che metterò eth0 dentro bat0, e poi una vlan eth0.1 dentro il bridge dei client. in questo modo tutti possono mettere eth0 senza complicanze in bat0. ordex dici che così funziona? mi sa che ti conviene il contrario, e in ogni caso ricordo che su motli hardware ci sono problemia mettere vlan dentro ai bridge :| quindi direi meglio il contrario ;) ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Testing firmware eigennet con batman-adv = 2013.0.0
eth0 nel bridge ed eth0.10 in bat0, funge! 2013/5/15 Gioacchino Mazzurco g...@eigenlab.org On Wednesday 15 May 2013 18:21:57 Luca Postregna wrote: ma voi due tutti questi discorsi non potevate farli prima di usarmi come cavia? :DDD e ce li eramavo fatti un po ma non ci si era capiti :| ora faccio qualche test con le vlan. credo che metterò eth0 dentro bat0, e poi una vlan eth0.1 dentro il bridge dei client. in questo modo tutti possono mettere eth0 senza complicanze in bat0. ordex dici che così funziona? mi sa che ti conviene il contrario, e in ogni caso ricordo che su motli hardware ci sono problemia mettere vlan dentro ai bridge :| quindi direi meglio il contrario ;) -- luca.postregna.name twitter.com/lucapost ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Testing firmware eigennet con batman-adv = 2013.0.0
On Wednesday 15 May 2013 18:57:44 Luca Postregna wrote: eth0 nel bridge ed eth0.10 in bat0, funge! perfetto aspetto la merge request!! ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
[Ninux-Wireless] Virtualizzazione linux ottimizzata con LXC
https://plus.google.com/104492301562638456962/posts/K76HKmFAkaG questo sembra molto interessante, a quanto pare l'ottimizzazione della memoria condivisa su LXC non me l'ero pensata solo io :D e sembra funzionare molto bene ;) ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Testing firmware eigennet con batman-adv = 2013.0.0
ancora un dubbio, quando sia eth0_mesh che eth0_clients sono disattivati, che ci faccio di eth0? gli do un ipv4 di backup? On Wed, May 15, 2013 at 7:00 PM, Gioacchino Mazzurco g...@eigenlab.orgwrote: On Wednesday 15 May 2013 18:57:44 Luca Postregna wrote: eth0 nel bridge ed eth0.10 in bat0, funge! perfetto aspetto la merge request!! -- luca.postregna.name twitter.com/lucapost ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Testing firmware eigennet con batman-adv = 2013.0.0
On Wednesday 15 May 2013 19:09:14 Luca Postregna wrote: ancora un dubbio, quando sia eth0_mesh che eth0_clients sono disattivati, che ci faccio di eth0? gli do un ipv4 di backup? no non serve piu' perche' la puoi raggiungere con l'ipv6 link local basta che ti assicuri che venga messa up con una configurazione tipo questa config interface eth0 option proto 'none' option ifname 'eth0' option auto 1 in oltre mettere gli ip di backuo causava qualche problemiccio di comprensione ai novizi e tanti avvisi di ip duplicati, ma adesso non e' piu' necessario :) ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Community Wireless Networks (IS4CWN) in Berlin, Oct. 2-4, 2013:
Cercherò di esserci, probabilmente anche il mio collega Andrea che lavora su OpenWISP. Federico Il 05/14/2013 06:38 PM, Saverio Proto ha scritto: Io ci vado: Please spread the word and join us at the International Summit for Community Wireless Networks (IS4CWN) in Berlin, Oct. 2-4, 2013: http://2013.wirelesssummit.org/ sto gia prenotando i biglietti per ottobre per pagare poco. Probabile vado con AirBerlin. se qualcuno e' interessato mi faccia sapere, ci si organizza per partire insieme. Saverio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Virtualizzazione linux ottimizzata con LXC
Preferisco non risparmiarla la ram ma avere un sistema robusto e resiliente. Credo che la vera ottimizzazione della memoria la fai in fase di progettazione si sistema interamente virtualizzato : type 1 o 2 e quante VM e di che dimensioni caricare su ogni server. From: g...@eigenlab.org To: eigenlab.riot-works...@inventati.org; wireless@ml.ninux.org Date: Wed, 15 May 2013 19:04:49 +0200 Subject: [Ninux-Wireless] Virtualizzazione linux ottimizzata con LXC https://plus.google.com/104492301562638456962/posts/K76HKmFAkaG questo sembra molto interessante, a quanto pare l'ottimizzazione della memoria condivisa su LXC non me l'ero pensata solo io :D e sembra funzionare molto bene ;) ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Virtualizzazione linux ottimizzata con LXC
On Wednesday 15 May 2013 20:08:48 federico la morgia wrote: Preferisco non risparmiarla la ram ma avere un sistema robusto e resiliente. Perche' si perde resilienza/robustessa se condividi le librerie in memoria? Dovrebbero essere readonly tra l'altro In ogni caso solitamente si ottimizza se vuoi risparmiare, se puoi permetterti risorse in abbondanza e' un altro discorso... ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Virtualizzazione linux ottimizzata con LXC
che poi sia VMware che Hyperv permettono il primo memory overcommitting, il secondo dynamic memory. Sono molto efficienti ed utilizzano tecniche veramente interessanti. Il problema della vistualizzazione user-level è sempre l'allocazione di risorse, soprattutto sul i/o disco. 2013/5/15 Gioacchino Mazzurco g...@eigenlab.org On Wednesday 15 May 2013 20:08:48 federico la morgia wrote: Preferisco non risparmiarla la ram ma avere un sistema robusto e resiliente. Perche' si perde resilienza/robustessa se condividi le librerie in memoria? Dovrebbero essere readonly tra l'altro In ogni caso solitamente si ottimizza se vuoi risparmiare, se puoi permetterti risorse in abbondanza e' un altro discorso... ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Virtualizzazione linux ottimizzata con LXC
Ed è per questo che si virtualizza anche lo storage e lo si posiziona, almeno quello principale, fuori dal server interconnesso in grandi aggregati SAS oppure direttamente tramite SAN storage. Date: Wed, 15 May 2013 22:58:12 +0200 From: p.chec...@ieee.org To: wireless@ml.ninux.org Subject: Re: [Ninux-Wireless] Virtualizzazione linux ottimizzata con LXC che poi sia VMware che Hyperv permettono il primo memory overcommitting, il secondo dynamic memory. Sono molto efficienti ed utilizzano tecniche veramente interessanti. Il problema della vistualizzazione user-level è sempre l'allocazione di risorse, soprattutto sul i/o disco. 2013/5/15 Gioacchino Mazzurco g...@eigenlab.org On Wednesday 15 May 2013 20:08:48 federico la morgia wrote: Preferisco non risparmiarla la ram ma avere un sistema robusto e resiliente. Perche' si perde resilienza/robustessa se condividi le librerie in memoria? Dovrebbero essere readonly tra l'altro In ogni caso solitamente si ottimizza se vuoi risparmiare, se puoi permetterti risorse in abbondanza e' un altro discorso... ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
[Ninux-Wireless] OpenWRT
Scusatemi, qual'e' la differenza fra questi progetti ? https://github.com/ninuxorg/attitude_adjustment https://github.com/ninuxorg/packages_12.09 -- *Dott. Giorgio Desideri* *PGP-Public Key*: 2048R/B1079A5D *PGP Fingerprint*:06B6 741E 5F35 B532 1749 46CA 2A7E E39D B107 9A5D *If people do not believe that mathematics is simple, it is only because they do not realize how complicated life is (J. von Neumann) * *Il saggio coltiva Linux, perché sà che Window$ si pianta da solo !* ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] OpenWRT
On May 16, 2013, at 5:54 AM, Giorgio Desideri wrote: Scusatemi, qual'e' la differenza fra questi progetti ? https://github.com/ninuxorg/attitude_adjustment https://github.com/ninuxorg/packages_12.09 Il repo attitude_adjustment contiene il sistema di base, kernel, base tool etc... Nell'altro ci sono tutti i packages aggiuntivi, i feeds, tipo radvd, ip6tunnel etc.. I due sono collegati, fai il clone del primo, poi aggiungi i link del secondo nel file feeds.conf.default (vado a memoria) cosi che quando esegui il comando feeds update invece di scaricare quelli della versione ufficiale prende il fork di ninux. Saluti, Matteo___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
