Re: [Ninux-Wireless] routing a terra con batman-adv e linette verdi sul mapserver
Come hai collegato le antenne al tp-link? Mi capitò una cosa simile quando feci un bridge delle VLAN sul router a terra; le antenne associate con le 2 del tetto si vedevano tutte a 1 hop. Gabriel Luca Postregna luca.postre...@gmail.com ha scritto: ___ 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] routing a terra con batman-adv e linette verdi sul mapserver
Il problema sembra identico al mio, controlla i bridge tra le porte (o le VLAN) a cui sono collegate le antenne via ethernet sul tplink. Dovresti avere un interfaccia separata (eth0.2 eth0.3) per ogni antenna. Gabriel Luca Postregna luca.postre...@gmail.com ha scritto: ___ 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] routing a terra con batman-adv e linette verdi sul mapserver
Non sono sicuro su Batman di come funzioni, ma dovresti configurare le due interfacce separatamente in modo da non unire i due link in uno solo. Su olsrd é possibile specificare le interfacce di ascolto singolarmente. Alla fine se non ricordo male la bat0 ( quella virtuale di batman) rimane una sola, ma le segnalazioni di batman vengono fatte separamente su 2. Guardo un attimo come si può fare e rispondo. Gabriel Luca Postregna luca.postre...@gmail.com ha scritto: ___ 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] apparati radio con firmware originali
Tra l'altro a breve dovrebbe pure uscire una versione dell'edgerouter con POE e 6 porte. Noi qui a firenze abbiamo provato così: Tplink WR842 + 3 apparati Nanostation con openwrt che fa routing sulla porta eth1 e sulla WiFi Switch managed e router dlink dir825 con openwrt Per qualsiasi informazione chiedi pure Gabriel PS ho appena scoperto che la tplink produce anche un modello WR843 con alimentazione poe. Perfetto da mettere sui tetti. Alessandro Gnagni enterprise...@gmail.com ha scritto: Abbiamo sperimentato queste tre soluzioni: Tp-link 1043nd con openwrt Ubiquiti EdgeRouter Lite Server linux debian per quanto riguarda gli approfondimenti per email la questione è un po lunga. In breve: il tplink va molto bene per fare routing a terra, ma non bisogna fargli fare altro perchè la macchina non ha abbastanza potenza. l'edgerouter a mio parere è la soluzione migliore, consuma poco essendo una macchina embedded ed ha potenzialità sia per la piattaforma che ubiquiti ha sviluppato sia perchè puoi fargli fare tutto quello che può fare una macchina debian. la soluzione con il server può andare bene per chi ha una macchina sempre accesa sotto il nodo, tuttavia ci sono i problemi di consumo energetico e dell'avere un server a fare routing che in caso di problemi o riavvii ti porta già tutto il nodo. In linea di massima per un rapporto qualità-prezzo consiglio l'edgerouter a chi debba allestire un supernodo. Il 02/10/2013 16.31, Luca Postregna ha scritto: @gnagni, un piccolo riassunto? non so se ci sarò al ninux day, sono un po' fuori mano... 2013/10/2 Alessandro Gnagni enterprise...@gmail.com mailto:enterprise...@gmail.com Se riusciamo a fare il talk non il primo giorno possiamo vederci nella prima giornata e vi faccio vedere cosa ho portato avanti qua a roma con il routing a terra. Al momento abbiamo testato 3 diverse configurazioni con 3 tipologie di apparati. Il 02/10/2013 14.42, Alessio ha scritto: On 10/02/2013 02:07 PM, Luca Postregna wrote: farò questi test sicuramente nei prossimi giorni e vi farò sapere. Verrai al Ninux Day? Perché io ho in scaletta un talk sul routing con le VLAN. L'idea è di fare un talk introdduttivo all'argomento e poi fare una tavola rotonda sulle differenti implementazioni in giro per le isole. Potrebbe essere un ottimo momento di confronto. nolith ___ Wireless mailing list Wireless@ml.ninux.org mailto:Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless ___ Wireless mailing list Wireless@ml.ninux.org mailto:Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless -- luca.postregna.name http://luca.postregna.name/ twitter.com/lucapost http://twitter.com/lucapost ___ 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
Re: [Ninux-Wireless] test scooreggione-AA-dynack, brick e unbrick con Arduino, considerazioni sui super nodi.
A Firenze lo stiamo adottando come pratica fissa per tutti i supernodi utilizzando switch manager o tp-link wr842nd con antenne ubiquiti con firmware stock Nell'ultimo nodo montato, per esempio, abbiamo utilizzato 3 apparati ( nanom5, bulletm5 e una m2loco), questi sono stati collegati alle porte 1 2 3 di un tplink ( in una scatola sul tetto) Dal punto di vista più sw ogni porta risulta, tramite le VLAN, un interfaccia a se( eth0.1 eth0.2 etc) Olsrd é configurato su 4 interfacce separate La porta wan é stata utilizzata per la rete interna. Un unico cavo cat5 scende verso terra e porta poe e dati. É molto più pratico da mantenere in quanto hai un solo apparato in cui configurare il firewall e un unica instanza olsr che genera traffico di segnalazione. Ci sarà un talk tenuto da Alessio ( nolith) al ninux day Gabriel Alessandro Gnagni enterprise...@gmail.com ha scritto: ___ 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] Digest di Wireless, Volume 50, Numero 27
Ciao a tutti, sono Gabriel di ninux Firenze. Sono a Roma per qualche giorno per Codemotion e Romecup e volevo venire alla riunione settimanale al fusolab. Qualcuno potrebbe dirmi l'ora a cui inizia e un modo per arrivarci da termini? ( se qualcuno passasse in zona accetterei volentieri pure un passaggio) Ruspondete direttamente per pvt, che con il digest non so quando mi arriva la mail Gabriel wireless-requ...@ml.ninux.org ha scritto: Invia le richieste di iscrizione alla lista Wireless all'indirizzo wireless@ml.ninux.org Per iscriverti o cancellarti attraverso il web, visita http://ml.ninux.org/mailman/listinfo/wireless oppure, via email, manda un messaggio con oggetto `help' all'indirizzo wireless-requ...@ml.ninux.org Puoi contattare la persona che gestisce la lista all'indirizzo wireless-ow...@ml.ninux.org Se rispondi a questo messaggio, per favore edita la linea dell'oggetto in modo che sia più utile di un semplice Re: Contenuti del digest della lista Wireless... Argomenti del Giorno: 1. Problema design policy routing Ninux (Saverio Proto) 2. Re: olsr mdns plugin chiacchierone? (Alessio Caiazza) 3. [blog] Reverse FAQ: Cosa non siamo (geegeek) 4. [blog] Reverse FAQ: Cosa non siamo-old (geegeek) 5. [blog] (geegeek) 6. [blog] Reverse FAQ: Cosa non siamo (geegeek) -- Message: 1 Date: Wed, 20 Mar 2013 13:44:52 +0100 From: Saverio Proto ziopr...@gmail.com Subject: [Ninux-Wireless] Problema design policy routing Ninux To: wireless wireless@ml.ninux.org, nodi-r...@ml.ninux.org Message-ID: capmmg8uylnc_nflaihjgmw5izop5iq3auwclo0y3npa0mlf...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Ciao, grazie a Lorenzo che ha messo in campo a Viterbo l'archiettura con il policy routing abbiamo trovato un problema di design: premesse, non centrano nulla le network a blackhole come si pensava al principio del troubleshooting. su un nodo con policy routing troviamo questa situazione: XM.v5.5.sdk# ip rule show 0: from all lookup local 4: from all to 10.0.0.0/8 lookup 111 4: from all to 172.16.0.0/12 lookup 111 4: from all to 192.168.0.0/16 lookup 111 4: from all to 176.62.53.0/24 lookup 111 4: from 176.62.53.0/24 lookup 111 5: from all lookup main 6: from all lookup 112 111 è la tabella delle rotte OLSR e 112 è la tabella della default via OLSR XM.v5.5.sdk# ip route show table local broadcast 10.183.1.255 dev eth0 proto kernel scope link src 10.183.1.11 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 local 172.16.183.2 dev ath0 proto kernel scope host src 172.16.183.2 local 10.183.1.11 dev eth0 proto kernel scope host src 10.183.1.11 broadcast 172.16.0.0 dev ath0 proto kernel scope link src 172.16.183.2 broadcast 10.183.1.0 dev eth0 proto kernel scope link src 10.183.1.11 broadcast 172.16.255.255 dev ath0 proto kernel scope link src 172.16.183.2 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 XM.v5.5.sdk# XM.v5.5.sdk# ip route show table main blackhole 176.62.53.0/24 10.183.1.0/24 dev eth0 proto kernel scope link src 10.183.1.11 172.16.0.0/16 dev ath0 proto kernel scope link src 172.16.183.2 blackhole 192.168.0.0/16 blackhole 172.16.0.0/12 blackhole 10.0.0.0/8 XM.v5.5.sdk# Nell'esempio di casa mia la LAN è 10.183.1.0/24 Lo sbaglio sta nel pensare che la route per la rete locale 10.183.1.0/24 si trova nella tabella local che è la prima che viene esaminata. In local ci sta la route per 10.183.1.255 (broadcast) ma non la route per gli host locali, che sta invece nella tabella main: 10.183.1.0/24 dev eth0 proto kernel scope link src 10.183.1.11 Ora succede che visto che girava in OLSR come HNA 10.110.0.0/18 (annunciata dal concentratore VPN quando Viterbo non parlava OLSR) questa network anche se meno specifica delle varie LAN /24 che usano a Viterbo (esempio 10.110.1.0/24) veniva sempre preferita alla network locale su eth0. Si poteva risolvere un due modi, o con una network aggiunta a mano nella table local: ip route add 10.110.1.0/24 dev eth0 table local oppure togliendo di mezzo l'HNA dell'aggregato /18. abbiamo testato tutti e due i workaround e funzionano. resta da risolvere in modo elegante il problema perché adesso basterebbe un annuncio HNA di un grande aggregato come 10.0.0.0/8 per interrompere la connettività dei nodi con la propria LAN se contenuta in quell'aggregato. vi ricordo che la tabella main contiene la rotta di default che viene inserita opzionalmente a mano dall'utente nell'interfaccia web, e quindi deve essere valutata per forza dopo la table 111. a mio avviso ci sono due strade. O facciamo in modo che non c'è MAI una default nella main, e quindi la possiamo valutare per prima della 111, altrimenti
