Re: [Ninux-Wireless] Elevazione (sulla mappa)

[Stefano De Carlo]

Il 03/01/2015 10:22, Elena ``of Valhalla'' ha scritto:
> On 2015-01-02 at 23:30:32 +0100, Giuliano G wrote:
>> Io sposterei l'attenzione su quale parametro sia più comodo da inserire per
>> l'utente, tanto poi prendendo l'altitudine s.l.m. da db esterni si può
>> ricavare sia altezza del nodo dal suolo che quella s.l.m.
>>
>> Credo quindi che l'altezza dal suolo del nodo sia più semplice da inserire
>> x l'utente.
> ma così l'utente che vuole sapere a che altezza sia il nodo deve 
> poi fare più fatica per andare a prendere l'altitudine s.l.m. e sommarla 
> all'altezza dal suolo inserita, e così come idea mi pare che 
> il dato venga inserito una volta e letto tante, non è meglio ottimizzare
> per la lettura?
>
> (mi chiedo se valga la pena di mettere i due campi e ciascuno inserisce
> quello che si sente di inserire, ma almeno si sa che dato sia)

Inserimento:
- Altezza s.l.m., dato recuperabile con precisione da risorse esterne in 
funzione di un input *già fornito* dall'utente, ovvero le coordinate. 
Richiedere in input manuale un dato con precisione arbitraria, quando lo stesso 
è dato è reperibile automaticamente, con precisione nota e coerente, è pessima 
UX. [1]
- Altezza rispetto suolo, è sia il dato che più ovviamente [2] l'utente si 
aspetta di *poter* inserire, sia quello più utile ad eventuali funzionalità 
aggiuntive come il calcolo della fattibilità del link (perché non reperibile in 
modi diversi rispetto all'input dell'utente).
- Elaborando su quanto prima: la percentuale di utenti che NON inserisce alcun 
dato sull'altitudine è infinitamente superiore al combinato di chi inserisce 
l'altitudine (qualsiasi tipo). Anche posto che qualcuno sia deciso sul 
significato della richiesta (che è ambigua), rispondere richiedere il lavoro 
extra di reperire l'altitudine. Che la maggior parte, basta cliccare a caso 10 
volte sui nodi del map server per vederlo, non intraprende. Un inserimento 
dell'altitudine rispetto al suolo è estremamente più triviale per l'utente e 
pertanto credo che porterebbe ad un maggior uso della funzionalità, con 
conseguenti lampanti benefici per il map server e eventuali feature aggiuntive.
- La mia implementazione preferita sarebbe un dropdown di equivalenza del tipo
Livello Suolo / 0-4 metri
Primo Piano / 4-8 metri
Secondo Piano / 8-12 metri
[...]
Tetto / [casella] metri
in modo da evitare tutte le possibili diverse nomenclature che ci sono 
attualmente (pt, piano, metri, mt., m, ecc, balcone, terrazzo) e poter parsare 
il contenuto se serve.

Stefanauss.

[1] http://zachholman.com/posts/shit-work/
[2] http://en.wikipedia.org/wiki/Principle_of_least_astonishment



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Elevazione (sulla mappa)

[Stefano De Carlo]

Il 02/01/2015 12:16, Simone Magrin ha scritto:
>
> Il 02/gen/2015 11:27 "nemesis" mailto:neme...@ninux.org>> 
> ha scritto:
> >
> > Elevazione del nodo (dove sono installate le antenne) rispetto a al livello 
> > del mare.
>
> Corro subito a cambiare! Considerando che l'altezza slm del suolo è 
> conosciuta, pensavo servisse l'altezza della casa da sommarvi (I software che 
> fanno fresnel/visibilità ottica chiedono infatti l'altezza dal suolo).
>
> Buono a sapersi!
>

In realtà il tuo approccio credo sia quello corretto e quello (aneddoticamente) 
più diffuso tra chi inserisce voci sul map server.

L'altezza rispetto al livello del mare è un dato estrapolabile da basi di dati 
dotate di API. È poco realistico aspettarsi che l'utente debba/possa inserire 
un valore più utile, coerente e corretto rispetto a questi db e pertanto non 
dovrebbe essere il valore che il map server "suggerisce" (con una nomenclatura 
ambigua, vedi post di nemesis) di inserire.

Un valore invece rispetto all'altezza dal suolo, anche indicativo (3° piano, 
ecc), ritengo che sia mediamente più utile da richiedere manualmente 
all'utente, lasciando quello rispetto livello mare all'estrapolazione 
automatica in funzione delle coordinate.
Questo perchè questo valore dipende dalla contingenza della specifica 
installazione, il map server non può certo ricavarlo e dunque ha senso 
chiederlo all'utente.

IMO dovrebbe essere questa la "elevazione" intesa e richiesta, una volta 
identificata una nomenclatura più adatta.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Auguri a tutti! Qual'è il vostro "obiettivo Ninux" per il 2015?

[Stefano De Carlo]

Il 31/12/2014 13:25, nemesis ha scritto:

> Quindi vorrei farvi una domanda che può essere un pò personale, se posso 
> permettermi: qual'è il vostro desiderio più grande riguardante ninux che 
> vorreste realizzare nel 2015?
>

Con 2 componenti "core" che si sono aggiunti nel team NinuCS abbiamo potuto 
fare una caterva di cose in più e portare avanti molte più attività, studio, 
montaggi, lavoro.
Non posso che desiderare di conoscerne/aggiungere altri 2-4 core Ninuxers 
cosentini nel 2015 :)

E quello che hai detto te a proposito del costante, magari anche noioso, lavoro 
e studio di sottofondo, di raffinamento dei dettagli piuttosto che inseguire 
una Next Big Thing (TM) al giorno, di sviluppo incrementale piuttosto che di 
un'architettura diversa al giorno, che più ninuxer partecipino con questa forma 
mentis è un mio desiderio personale.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Monitoraggio OLSR su PfSense

[Stefano De Carlo]

Il 29/12/2014 16:44, Michele Salerno ha scritto:
>
>
> Prova questo:
>
> Spunta attiva su Announce self as Dynamic Gateway
> Spunta attiva su Enables the OLSR Dynamic Gateways Announcing feature
> NON aggiungere 0.0.0.0/0.0.0.0 o niente del 
> genere, fai rimenere il tutto con la sola 10.27.0.0/24 .
> Salva.
>
> Dovrebbe andare così.
> Questo perchè "Announce self as Dynamic Gateway" è proprio una HNA4 
> "0.0.0.0 0.0.0.0" hardcoded, nel momento in cui tu la vai ad aggiungere a 
> mano in Local Routes, oltretutto con la sintassi sbagliata, vai in conflitto.
>
> Prova e facci sapè,
> Stefanauss.
>
> Niente da fare. Dai log lo vedo attivo ma in dashboard lo vedo stoppato.
> Piò che altro mi interessa sapere se lavora in modo corretto.
>

Lascia stà la X rossa.
Devi confermare che, facendo quanto sopra, disable, save, enable, save, il 
servizio OLSR parta e acquisisca le rotte.

"pgrep olsr" e vedi se il processo è attivo
"netstat -r" vedi se prende rotte (ammesso che sei linkato a qualcuno, non 
ricordo)
"cat /var/etc/olsr.conf" e leggi il file di config generato attualmente

> con entrambi mi va in crash anche la connessione WAN.
>

Che intendi per crash?

> Disabilitando la prima voce ed abilitando solo la seconda voce, il servizio 
> parte (lo vedo nei log)

Non puoi attivare solo "Announce self", devi attivare per forza "Enable dynamic 
gw", AnnounceSelf è dipendente da EnableDynGw.

In generale, se il servizio non ti è partito (e non lo devi dedurre dalla 
spunta rossa, ma dal pgrep), consulta l'output di

olsrd -f /var/etc/olsr.conf -d 0

Occhio, qualsiasi modifica fai, cicla disable+save+enable+save.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Monitoraggio OLSR su PfSense

[Stefano De Carlo]

Il 18/12/2014 15:37, Michele Salerno ha scritto:
> Nella mia Announce Dynamic Local Route ho: 10.27.0.0/24 
>
> Ho attivato anche
> Announce self as Dynamic Gateway - Enables the OLSR Dynamic Gateways 
> Announcing feature
>
> Se in "Announce Dynamic Local Route" aggiungo 0.0.0.0/0.0.0.0 
>  OLSR si pianta!
>
> Come faccio ad annunciare che condivido anche internet?
>
> ecco il mio settaggio:
> https://www.dropbox.com/s/ifooghmhffepofc/fw.ninux.mt.jpg?dl=0
>
> grazie! :)

Prova questo:

Spunta attiva su Announce self as Dynamic Gateway
Spunta attiva su Enables the OLSR Dynamic Gateways Announcing feature
NON aggiungere 0.0.0.0/0.0.0.0 o niente del genere, fai rimenere il tutto con 
la sola 10.27.0.0/24.
Salva.

Dovrebbe andare così.
Questo perchè "Announce self as Dynamic Gateway" è proprio una HNA4 "0.0.0.0 
0.0.0.0" hardcoded, nel momento in cui tu la vai ad aggiungere a mano in Local 
Routes, oltretutto con la sintassi sbagliata, vai in conflitto.

Prova e facci sapè,
Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Ninux Backbone

[Stefano De Carlo]

Il 27/12/2014 18:53, Massimiliano CARNEMOLLA ha scritto:
> On 27/12/2014 18.18, Stefano De Carlo wrote:
>
>> * Ulteriore layer
>
> A cosa e' riferito ?
>

Al fatto che due livelli di protezione indipendenti tra loro sono meglio di un 
singolo.

>
>> * Sicurezza di protocolli non-cifrati
>
> Si potrebbe ipotizzare la loro "inesistenza" in uno scenario del genere ? ;-)

Si, si potrebbe, io rispondevo alla tua domanda in generale sulle ragioni di 
una VPN ;)

>
>> * Sicurezza dei metadati
>
> Header etc. ?

Yes.

>
>
>> tra le altre cose, sintetizzando.
>
> Si risparmia un po' in velocita' pero'.
>
> Dovrei fare qualche ricerca tipo "ip tunnel vs vpn" ?

VPN encryption overhead, cleartext/plaintext vs encrypted tunnel, tutte 
ricerche che ti possono fare approfondire molto. [1]
È un compromesso da trovare, si, e dipende anche da hw e sw scelto.
Ad esempio dopo vari test [2] qui in Calabria si è visto che OpenVPN su 
NinucsWrt @ 1043NDv1 perde il 15-20% del throughput massimo con encryption 
attiva laddove sia coinvolto del NAT.
Se ti va bene stacce, altrimenti sposti la VPN su dell'hw superiore. Già con 
una rPi c'era il 100% della banda internet disponibile all'altro capo del 
tunnel.

Stefanauss.

[1] http://www.cse.wustl.edu/~jain/cse567-08/ftp/ovpn/index.html
[2] http://ml.ninux.org/pipermail/calabria/2014-July/003522.html && altro 
sparso nella lista Calabria.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Servizi in rete

[Stefano De Carlo]

Il 27/12/2014 21:13, impythefr...@gmail.com ha scritto:
>
> Approposito di sicurezza, qualcuno ha mai testato oslr/batman ad attacchi? A 
> logica è possibile che un nodo inietti pacchetti che facciono girare il 
> routing a suo piacimento... (credo sia possibile un dos evitando che un nodo 
> venga raggiunto)
>

Certo, se ne sono anche scoperti di nuovi in Ninux.

OLSR plugin's oversized HTTP headers - Fix by Nolith (Ninux Firenze)

http://ml.ninux.org/pipermail/wireless/2014-May/014019.html

OLSR fake HNA announcement originator DoS - Analisi by Zio Proto (Ninux Roma)

http://ml.ninux.org/pipermail/wireless/2014-May/014269.html
http://ml.ninux.org/pipermail/wireless/2014-May/014301.html

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Servizi in rete

[Stefano De Carlo]

Il 27/12/2014 20:25, Michele Salerno ha scritto:
> Voi come vi comportate sulle macchine server?
> Le mettere in sicurezza con firewall & C. o le lasciate libere essendo in 
> rete "locale" e non su internet?
>

Tutto chiuso by default, progressivamente si apre solo quel che serve, a chi 
serve.
In generale non hanno senso le distinzioni in approccio tra Ninux e Internet, 
in termini di messa in sicurezza.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] AP-STA

[Stefano De Carlo]

Il 28/12/2014 14:37, Massimiliano CARNEMOLLA ha scritto:
> Su AirOS e RouterOS non e' possibile settare il wireless in adhoc.
>
> si puo' utilizzare 1 modalita' master e piu' STA contemporaneamente ?
>

AirOS: l'hw lo supporta, ma non il sistema operativo.
RouterOS: boh. Credo di ricordare di si, ma solo in modalità WDS.
OpenWrt: lo supporta se il driver lo supporta. Su tutte le Ubiquiti è così.

Esempio di config: 
http://wiki.ninux.org/FirmwareScooreggione#Esempio_Configurazione_come_AP-STA_contemporaneo

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Ping

[Stefano De Carlo]

> Dov'e' che stavo sbagliando ?
>

Sembrerebbe su subnet mask e/o rotte, ma è impossibile dire senza
configurazioni e contesto.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Ninux Backbone

[Stefano De Carlo]

Il 27/12/2014 12:04, Massimiliano CARNEMOLLA ha scritto:
>
> Se creiamo link wireless senza protezione e poi la applichiamo a livello dati 
> (SSL etc.) mi domandavo la necessita' di adottare sicurezza su tunnel VPN.
>

* Ulteriore layer
* Sicurezza di protocolli non-cifrati
* Sicurezza dei metadati

tra le altre cose, sintetizzando.

>
> Sono fermo al momento perche' volevo implementare il routing a terra ma ho 
> avuto problemi a livello AirOS... (e' un bel po' di tempo che ho lasciato 
> perdere...)
>

Lascia stare le VPN, riprendi questi fili interrotti :)

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Esperienze con RouterBoard133C3?

[Stefano De Carlo]

Il 18/12/2014 18:32, Luigi ha scritto:
> In più 45 Dollah per far da AP.. openwrt time :-)
> Se supporta anche una TNETW1130GVF che mi ritrovo da un vecchio Netgear siamo 
> a posto :-)
>
Alla prossima hacklab session se non hai ancora fatto facciamo compilation time 
:)

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nuovi acquisti....consigli?

[Stefano De Carlo]

Il 15/12/2014 20:17, Michele Salerno ha scritto:
>
> Domanda: qualora c'è necessità di superare un palazzo come ostacolo (che 
> rende non visibili 2 nodi) che soluzione si può trovare?
>

Non c'è nessuna soluzione reattiva al problema.
Devi essere proattivo ed espandere costantemente la tua isola, coinvolgere 
nuova gente, dare densità ai nodi, perché in una situazione densa hai maggiori 
possibilità di trovare il modo di aggirare/triangolare l'ostacolo.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nuovi acquisti....consigli?

[Stefano De Carlo]

Il 14/12/2014 02:45, Michele Salerno ha scritto:
> La rocket non va bene per la backbone?pensavo fosse qualcosa di superiore.

[generalizzando, ma giusto per darti un'idea. Poi mano a mano che approfondisci 
capisci che non è tutto bianco/nero.]

Backbone = collegamenti dedicati molto performanti (il più possibile).

Non è la Rocket a decidere "dedizione" e "performance". È solo una base 
station, contiene la scheda madre di controllo, tutto tranne l'antenna.
Se "fai backbone" oppure no dipende dunque da che antenna ci metti, dove la 
punti, come la imposti, e la logistica del link.

La parte "dedizione" la indirizzi utilizzando antenne il più possibile 
direttive, la parte "performance" associando la dedizione con un alto guadagno.

Il motivo per cui la Rocket "non va bene per la backbone" è che una volta che 
ne hai una tra le mani, per dare "dedizione" e "performance" i costi si alzano, 
di parecchio, _per un vantaggio quasi intangibile_ rispetto ad una soluzione 
CPE come NanoBeam/NanoBridge/NanoStation. Con queste tre hai "dedizione e 
performance" in un pacchetto unico, già pronto, dai costi bassi. Questo perché 
poi la tua soluzione minima (quasi sempre *eccessiva* ai fini di backbone) 
diventa accoppiarla ad un Dish 30, e siamo già sui 200€.

Con la Rocket acquisisci modularità, sposti più avanti le performance massime e 
le soluzioni percorribili, ma così facendo stai anche alzando il costo della 
parte bassa del range (indicativamente 2x rispetto ad una CPE).

Questo è il motivo per cui su Ninux, quasi sempre, le Rocket vengono utilizzate 
precisamente dove forniscono soluzioni non percorribili in altre Ubiquite vie, 
ovvero la distribuzione settoriale (*) 90-120°.
Lì chiaramente ti godi la qualità della Rocket, che è parecchia.

Stefanauss.

(*) A meno che non consideri 60° "settoriali". Io sono tra quelli.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Photogallery - Categorie-sottocategorie

[Stefano De Carlo]

Il 14/12/2014 16:39, federico la morgia ha scritto:
> Salve a tutti, una domanda rapida rapida : sto effettuando degli upload di 
> sopralluoghi per la nuova isola a Pescara in Abruzzo, ma anche altre isole 
> che sto creando un pò in tutta la regione e dovrei creare la categoria 
> Abruzzo e le sottocategorie una per ogni provincia, la domanda è : Come si fà 
> a creare categorie e sottocategorie da web ??? Ho provato a cercare nelle 
> varie voci ma non ho trovato nulla.
> Qualcuno può darmi una mano ?
>
> Federico.

Non si può fare, è una prerogativa necessariamente dell'account admin.
Io e Wikipedia (*) abbiamo creato Abruzzo/L'Aquila+Teramo+Chieti+Pescara.

Stefanauss.

(*) che vergogna.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Simulatori emulatori di Reti Wireless

[Stefano De Carlo]

Il 12/12/2014 11:13, Massimiliano CARNEMOLLA ha scritto:
> Ciao, quali software utilizzate per emulare simulare una rete wireless ed 
> aggiungere macchine reali virtuali ?

Io conosco:

CORE - http://www.nrl.navy.mil/itd/ncs/products/core
ns3 - http://www.nsnam.org/
Netkit - http://wiki.netkit.org/index.php/Main_Page
GNS3 - http://www.gns3.com/

Cisco Packet Tracer - 
https://www.netacad.com/it/web/about-us/cisco-packet-tracer (Proprietario)

Ma non ti potrei indirizzare su nessuno in particolare, non capisco che tipo di 
simulazione cerchi e che intendi per "macchine reali virtuali".

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] OLSR o BATMAN

[Stefano De Carlo]

Il 10/12/2014 21:27, Massimiliano CARNEMOLLA ha scritto:
>
>
> E' un po' la filosofia di OLSR, porting su molte svariate architetture 
> software. (BSD
> Development
> i386
> iPhone
> Linux
> Mac OSX
> Release
> Win32
> )
>
>

Ma non con lo stesso feature set.
L'unica full-fledged è Linux, le altre si lasciano qualcosa dietro (tipo il 
supporto alle multiple routing tables su BSD, che per Ninux ha un bell'impatto.)

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] NanoBeam, le nuove NanoStation?

[Stefano De Carlo]

Il 11/12/2014 15:40, federico la morgia ha scritto:
> Proprio per questo mi sto orientando verso le mikrotik ac che permettono 
> anche 80 mhz di larghezza di banda e quindi complessivi 866 mbit ma a fronte 
> di un minore guadagno d'antenna.

Anche i device della Ubiquiti supportano gli 80 Mhz, ma solo in PtP mode.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] NanoBeam, le nuove NanoStation?

[Stefano De Carlo]

Il 09/12/2014 20:08, Simone Magrin ha scritto:
>
>
> in lombardia stiamo pensando a:
> NANO(POWER)BEAM M5-400 per linkarsi ad un altro nodo, e

FIY, entro i 15km vanno benissimo anche le 300.

>
> vorrei invece provare *la serie AC*...qualcuno ne sa qualcosa? soprattutto: 
> qualcuno sa se sono "retro-compatibili" con, ad esempio, un rocket m5 e se le 
> nanobeam hanno già la funzione PtMP?
> mi dicevano che ancora andavano implementate via software...
>

Loro dicono questo ufficialmente, che il deploy della serie AC consiste di tre 
fasi:

1) Lancio: PtP-only.
2) Tra poco: PtMP
3) Prima o poi (ma sulla TODO list): Retrocompatibilità con AirMax N.

"poco", "retrocompatibilità", "poi", sono termini potenzialmente assoggettati 
alle ridefinizioni volanti della Ubiquiti :)

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] NanoBeam, le nuove NanoStation?

[Stefano De Carlo]

Il 02/12/2014 16:55, Ilario Gelmetti ha scritto:
> Il 24/11/2014 21:10, Stefano De Carlo ha scritto:
>> Eccome, hanno il doppio della direttività vs NSM5.
> Finalmente ho capito cosa vogliono dire i grafici nei datasheet,

Tieni presente questo: per quello che ricordo, il beamwidth, non so se per 
convenzione o per qualche sorta di industry standard, è l'angolo del grafico 
entro il quale la perdita si mantiene entro un certo valore. -3dBi, credo.
Se non fosse così posso arrivare pure a dire che la NBE-M5 ce l'ha di 90°.

Questo dà proprio 60° per la NanoStationM5, che è il beamwidth con la quale 
viene pubblicizzata. Nel caso delle NanoBeam NBE-M5 dà un 30° gradi per il 
modello da 16 e un 20° per quello da 19 (parlando di horizontal).

Ecco perché come dici tu la forma del grafico rimane importante, cambia il 
punto di  "attacco" del beamwidth e quello che succede nelle immediate 
vicinanze, che è chiaro motivo di interesse.
Altro motivo per cui conta moltissimo la forma, e che è quella che vai a 
variare quando agisci sul tilt meccanico ed elettrico, quindi conta la base da 
cui parti.

>
>> Per raggiungere la stessa flessibilità di montaggio che hai con le NBM5, con 
>> le NSM5 dovevi prendere degli accessori.
> Eh questo pare na figata, anche se a noi serve raramente...

Aspetta, fai più nodi, situazioni sempre più diverse, diventa cooler :)

>> * il software: OpenWrt soffre un po' di frescura su questo device e 
>> soprattutto con AirOS XW ci sono problemi di compatibilità con apparati 
>> legacy Ubiquiti [1].
> Tranqui, se è un problema software verrà risolto :) ottimismo :)

La penso anche io così.
Il fatto è che la Ubiquiti ha fatto un macello. Al momento dell'ultimo test che 
abbiamo potuto fare, il problema era noto da 7 mesi almeno, e almeno 8 revision 
di AirOS "questa è la volta buona".
Il loro claim è che finalmente AirOS 5.6 su XW fixi questa categoria di 
incompatibilità ma non siamo in condizioni in questo momento di effettuare un 
test nelle stesse condizioni precedenti, cosa che attendevamo con ansia di fare 
:(
Comunque 7 mesi di hw di fatto di fatto inoperabile sono abbastanza 
sconcertanti.
Meno male che non ci facciamo dindi, con Ninux.

> O sconsigli di fare isole miste XM/XW potendo?

Se hanno fixato, il mio consiglio implicito nella precedente mail (e motivo per 
cui abbiamo messo in hold l'acquisto massivo di altro hw, a Cosenza, per ora) 
non vale più.
Era una cosa annegata nella situazione contingente di questo bug.
Il tutto sta a confermarne il fix, potendo.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Firmware per TL-WA7510N

[Stefano De Carlo]

Il 07/12/2014 10:46, Michele Salerno ha scritto:
> Ok, spiego i passaggi fatti dall'inizio
>
> 1) Software originale TP-Link...
> 2) Provo a caricare il firmware scorreggione - factory dice che non è 
> valido
> 3) Provo a caricare il firmware scorreggione - sysupgrade parte 
> l'aggiornamento
> 4) Ho OpenWRT
> 5) telnet è disabilitato, solo ssh con password "root"
> 6) faccio il cambio di IP da /etc/config/network agggiungendo alla lan il 
> gateway
> 7) opkg update & opkg install luci olsr etc
> 8) entro in luci e faccio le modifiche di conf.
>
> Se spengo o riavvio l''antenna muorenon da segni di vita, l'unico modo 
> per riasumarla è il tastino del reset e devo ripartire dal punto 5
>

Se flashi il sysupgrade invece del factory, il risultato AFAIK è un partition 
layout sfanculato, con ogni genere di effetto collaterale.

Puoi provare così (assumento che tu abbia TL-WA7510N ___v1___)

- Scarica il DD-WRT revert qui 
http://www.dd-wrt.com/phpBB2/viewtopic.php?t=85237 (te l'ho mirrorato qui, 
sennò ti devi registrare: 
https://drive.google.com/file/d/0B9RNHh47KzvibExBRmJMbXBGYkU/)
- scp  root@192.168.1.1:/tmp/backtostock.bin
- loggati in ssh
- mtd -r write /tmp/backtostock.bin firmware
- ASPETTA
- non mi ricordo se reboota da solo oppure no, onestamente. In ogni caso, 
attendi una conferma visiva che ha terminato il flash
- Reboota
- Ora dovrebbe essere di nuovo col fw originale
- Riprova a flashare openwrt-factory
- Se ti da invalid, prova con le immagini trunk
- Ad ogni modo, riparti dal fw di fabbrica.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] TP-Link Outdoor CPE-510 /520 + CPE-210/220

[Stefano De Carlo]

Ciao ragazzi,

la TP-Link ha partorito di recente (*) delle vere CPE inspired-by-NanoStation, 
sia M2 che M5. Si tratta della famiglia composta da

* CPE-510 (5 GHz, 13dBi)
* CPE-520 (5 GHz, 16dBi)
* CPE-210 (2.4 GHz, 9 dBi)
* CPE-220 (2.4 GHz, 12 dBi)

Pagina Prodotto: http://www.tp-link.com/en/products/details/?model=CPE510

OS dedicato alle CPE, nome PharosOS, anche questo ispirato all'ennesimo MAC 
TDMA proprietario che estende lo standard wireless, chiamato Pharos.

Pharos : PharosOS = AirMax : AirOS.
very tdma, much proprietary, so copy.

vs NanoStation: more RAM, more power. Prezzo, non saprei.

Purtroppo, a leggere i manuali, non c'è esposto in PharosOS il supporto alle 
VLAN :(
Ma il SoC le supporta, quindi siamo ad un aggiornamento firmware di distanza 
dall'averle.

Confortante che ci sia già un supporto preliminare in OpenWrt Chaos Calmer per 
tutte queste CPE.

https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg27558.html

@Calabria: possono essere interessanti e le aggiungo alla liste delle 
sperimentazioni.

Stefanauss.

(*) annunciata la prima a fine 2013 ad uno showroom, ma shippate negli ultimi 
2-3 mesi, AFAIK.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] Reti Comunitarie e Ninux @ Mongrassano (CS), 5 Dicembre

[Stefano De Carlo]

Ciao,

broadcasto nella speranza di raggiungere tutti i nord-calabri che possano fare 
domani un salto in provincia di Cosenza :)

http://calabria.ninux.org/2014/12/04/reti-comunitarie-e-ninux-mongrassano-5-dicembre/

Domani 5 Dicembre 2014, Ore 17:00, alla Sala Ilenia/ex-Cisa di Mongrassano (CS) 
la community di Ninux Cosenza inconterà i membri del nascente progetto 
Connect.me.

*NinuCS* (Ninux Cosenza) parlerà di un *concetto di rete diverso dalla solita 
Internet*, quello delle *reti comunitarie* aperte, libere e di proprietà del 
cittadino che stanno nascendo in tutta Italia (in Calabria: Cosenza, Catanzaro, 
Reggio, Lamezia, Crotone); del perché sono importanti e di come si realizza 
questo riappropriarsi della propria presenza in rete.

*Connect.me * è la voglia dei 
mongrassanesi di creare una MAN con lo scopo di abbattere il digital-divide e 
fornire *connettività Internet a tutti i residenti*, secondo un modello dove i 
cittadini stessi creano il loro provider (Do-It-Yourself ISP). Ma non solo: 
risorse interne, e un’interfaccia verso la pubblica amministrazione per offrire 
servizi utili alla comunità.

Quali*punti di contatto* tra i due progetti? È possibile *unire le forze di 
queste due realtà* e realizzare entrambi gli obbiettivi? Vi aspettiamo per 
parlarne assieme: dopo le presentazioni seguirà un’ampia sessione di 
*domande-e-risposte*, dibattiti e interventi!

/Happy Ninux, Happy Connection/!

Stefanauss.





signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo Matera ed evento di presentazione domenica 7 dicembre

[Stefano De Carlo]

Il 04/12/2014 12:21, Darkman ha scritto:
> Michele, 
> non ho il piacere di conoscerti, ma, visto che mi sento tirato in causa, ho 
> il dovere di risponderti.
>

Ciao,
Se Michele ha detto delle inesattezze sul progetto Neco, puoi fargliele notare 
costruttivamente.
Ma niente di ciò che ha detto giustifica il termine "infamante". Avrai il 
dovere di rispondere, ma misurati per favore.

>
> forse perché non siamo abbastanza radical chic e non passiamo le giornate
> a segarci su arduino (facciamo altro nella vita e non ci danno stipendi per 
> scaldare seggiole),

Non ti stai ponendo affatto nella miglior posizione per esigere rispetto, spero 
tu te ne renda conto.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Access point con 8 porte gigabit

[Stefano De Carlo]

Il 27/11/2014 01:11, Francesco Rapanà ha scritto:
> La situazione attuale è quella di un nodo foglia, la configurazione della 
> rete interna è su 3 piani, schematizzata qui:  
> http://photogallery.ninux.org/albums/userpics/10003/c5l_mdmonaco.png
> Poiché lo switch Zyxel ha deciso di andare a 80mbit in un verso e 8 (o meno) 
> nell'altro, è giunta l'ora di un upgrade.
> Come dicevo la soluzione più semplice è cambiare lo switch con un Netgear 
> GS10E o un TP-Link TL-SG108E, spesa minore di 40€

+1, farei cosi.

>
>
> Il giorno 26 novembre 2014 12:07, Stefano De Carlo  <mailto:stefana...@gmail.com>> ha scritto:
>
> Se le metti in bridge, il paccheto deve risalire tutto lo stack ed essere 
> gestito in software, al gigabit non ci arrivi così. su queste CPU
> Quel che devi fare, e probabilmente quel che intendevi, è agire sulla 
> configurazione dello switch per mettere la porta blu nella stessa VLAN 
> principale delle 4 gialle (rendendola, di fatto, come una gialla).
>
>
> Su un 1043ND ho questa config anche se non l'ho mai stressato a fondo, non so 
> se è diverso sul 3600, è questo che intendevi?
>
> config interface 'lan'
> option ifname 'eth0.1 eth1'
> option type 'bridge'
> option proto 'static'
> option netmask '255.255.255.0'
> option accept_ra '1'
> option gateway '192.168.0.1'
> option dns '192.168.0.1'
> option ipaddr '192.168.0.2'
>
> config switch
> option reset '1'
> option name 'switch0'
> option enable_vlan4k '1'
> option enable_vlan '1'
>
> config switch_vlan
> option vlan '1'
> option device 'switch0'
> option ports '0 1 2 3 4 5t' 

È un 1043ND v1? Mi sembra di si.
Se è così allora la sezione vlan è corretta, tutte le porte sono switchate e 
"gialle".
Non mi torna perchè hai

option ifname 'eth0.1 eth1'
option type 'bridge'

Se hai il wireless disattivo la riga bridge non dovrebbe esserci e ifname 
dovrebbe contenere solo eth0.1.
Se il 1043 deve fare anche da AP allora la riga bridge è ok ma neanche qui 
dovrebbe esserci eth1 in ifname.

Non dovrebbe essere bloccante, comunque. Semplicemente OpenWrt ignorerà eth1.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] R: Re: R: Installazioni

[Stefano De Carlo]

Il 27/11/2014 20:20, Simone Magrin ha scritto:
>
> Il wr740 è un po' borderline per usarlo con olsr...anzi mi sa proprio che non 
> hai spazio per installarlo.
> Ci vorrebbe almeno un 841nd
>

Hanno entrambi 4 MB di Flash, che sono più che sufficienti  per olsr e 
luci-app-olsr anche su Barrier Breaker.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] IP per l'isola lombarda

[Stefano De Carlo]

Il 26/11/2014 17:57, Elena ``of Valhalla'' ha scritto:
> On 2014-11-26 at 17:24:47 +0100, Stefano De Carlo wrote:
>> È più una questione che non ci sono ragioni per non stare su dual stack.
>> Difficilmente puoi rimuovere IPv4 dagli stack software dei device che usi, 
>> quindi tanto vale utilizzarlo.
> beh, lo si può disabilitare / non configurare

Sempre footprint è (spesso su 4 MB totali).
E spesso non è vero: ci sono ancora casi dove per tara storica 
applicazioni/demoni/ecc proprio si aspettano IPv4.
Andare IPv6-only (ora) è un palo nel sederino per nessun apparente benefit.


> (ok, adesso ho voglia di provare a compilare un kernel con meno pezzi 
> di ipv4 possibile, ma me la farò passare, che sarebbe una perdita 
> di tempo)

Disabilita completamente tutto "net" e rendi http://tools.ietf.org/html/rfc1149 
la sola componente della tua protocol suite.

>> E usare (anche) IPv4 abbassa la barriera di ingresso, indubbiamente.
> beh, abbassa la barriera di ingresso solo se di fatto si decide 
> di non usare ipv6, altrimenti tutti devono configurare anche quello

La barriera di ingresso è un concetto che vale, appunto, all'ingresso.
Permettere a quei, neanche pochi, interessati a Ninux che hanno almeno l'ABC 
del networking di entrare, configurandosi i propri apparati avendo almeno il 
beneficio di concetti "familiari", mi sembra un enorme plus.
IPv6 si può sempre configurare dopo, quando hai avuto ormai tempo di 
padroneggiarlo, o lo puoi configurare subito "a memoria", approfondendo il 
funzionamento dopo.
Ma da dentro. L'importante è che non ti si pari davanti quando *entri*.
L'intero punto del dual stack non è avere funzionalità replicate per il gusto 
di, ma è proprio dare il tempo di transizionare.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] IP per l'isola lombarda

[Stefano De Carlo]

Il 26/11/2014 17:12, Elena ``of Valhalla'' ha scritto:
> On 2014-11-26 at 16:25:11 +0100, Stefano De Carlo wrote:
>>> P.S. qualcuno invece ha per caso deciso di usare solo ipv6? 
>> IPv6-only? No.
> qualcuno ci ha già pensato e ha scoperto che ci sono particolari 
> controindicazioni per cui è meglio non farlo?

È più una questione che non ci sono ragioni per non stare su dual stack.
Difficilmente puoi rimuovere IPv4 dagli stack software dei device che usi, 
quindi tanto vale utilizzarlo.
E usare (anche) IPv4 abbassa la barriera di ingresso, indubbiamente.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] IP per l'isola lombarda

[Stefano De Carlo]

Il 26/11/2014 16:13, Elena ``of Valhalla'' ha scritto:
>> [spiegone snippato]
> ho appena forwardato alla lista lombarda, seguiamo queste indicazioni
>
> P.S. qualcuno invece ha per caso deciso di usare solo ipv6? 

IPv6-only? No.

> ci sono pratiche standard per farlo?
>

No. E la nostra documentazione a proposito è ancora più sparuta.

Le situazioni sono molto diverse. Roma ha una /64 pubblica, unicast globali.
Verona non l'ho capito. TunnelBroker di LibreMesh?
Firenze usa gli ULA: http://wiki.ninux.org/Firenze/GestioneIndirizzi#IPv6
Calabria IPv4-only.

Non ci sono pratiche standard.
Io ti direi: partite con gli ULA, poi valutate con calma, magari con la 
crescita di Ninux ci saranno altre opportunità di assegnamenti di pubblici IPv6.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] IP per l'isola lombarda

[Stefano De Carlo]

Il 26/11/2014 14:35, Elena ``of Valhalla'' ha scritto:
> Ciao
>
> stavamo decidendo che IP prendere per l'isola lombarda: dato che 
> il metodo dei CAP di fatto funziona solo a Roma (CAP inizianti per 000), 
> stavamo pensando di prendere 10.2.0.0/16 o 10.20.0.0/16 (dalla 
> pagina di `gestione indirizzi`_ mi paiono entrambe libere) e 
> qualcosa di equivalente in ipv6 e sottoassegnarcele in base al 
> secondo numero del CAP.
>
> Quindi ad esempio in provincia di Varese (CAP 21xxx) useremmo 
> 10.2.11.0/24, e una volta finito quello 10.2.12.0/24 ecc, 
> a Milano (20xxx) 10.2.1.0, a Como (22xxx) 10.2.21.0.
> Ci sono delle province con numero in comune (ad es. Lecco e Sondrio 
> condividono 23xxx), e Mantova ha 46xxx (e Cremona 26xxx), 
> che pensavo o di lasciare assieme o meglio di gestire con indirizzi 
> tipo 10.2.131.0.
>
> Cosa ne dite? potrebbe essere un buon metodo? Ci prendiamo l'indirizzo?

Ciao Elena,

si sta da tempo cercando di deprecare ogni riferimento a regole del cap e 
procedere al filling dei pezzi non contingui di indirizzamento, oltre che di 
procedere con lo stesso standard per tutte le nuove isole.

Se non ci sono particolari ragioni per fare diversamente rispetto alle altre 
isole, e non mi sembra, e assumendo che la vostra mesh sarà OLSR-based, e mi 
sembra, basta fare come han fatto le ultime isole

1) 172.[last+1].0.0/16 riservato per tutta la regione = 172.25.0.0/16 per il 
backbone Lombardo, che poi subnetterete in una /24 per isola/provincia/città
2) 10.x.0.0/16 riservato, da cui estrarre le LAN /24 a nodo da annunciare.

Il punto 1 è roba standard.
Il punto 2, in teoria si potrebbe dare una /16 per isola/provincia/città, per 
quanto overkill (prima di arrivare a 254 nodi, ne passerà). Ma non è che 
manchino, queste /16 dallo spazio 10/8, e può essere utile nella situazione 
dove si vogliano annunciare gli aggregati.
In Calabria abbiamo fatto così, e a me sembra che la situazione sia identica 
(più città coinvolte che cominciano assieme).

Forse ti può essere utile: 
http://wiki.ninux.org/IndirizziCalabria#Coordinamento_con_l.27indirizzamento_complessivo_Ninux.org

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Access point con 8 porte gigabit

[Stefano De Carlo]

Il 26/11/2014 11:53, Francesco Rapanà ha scritto:
> Ciao a tutti, conoscete qualche access point con 8 porte gigabit?

Ciao,
guarda, così su due piedi: http://routerboard.com/RB2011UiAS-2HnD-IN

Ma ti faccio queste precisazioni:

- Sono 5 GigabitEthernet e 5 FastEthernet
- Così come tutti gli Integrated Service Router, il backplane è tutto 1Gbps 
diviso per le porte, non è 1Gbps/porta.
- In questo preciso momento questo modello su OpenWrt ha un bug sulle porte 
gigabit, che dunque non vanno gigabit (vanno 10mbps half-duplex, se non ricordo 
male).

> Per il momento la soluzione economica che più si avvicina è usare un WDR3600 
> configurato con WAN e LAN in bridge, avendo così 5 porte (dovrebbe essere 
> possibile).

Se le metti in bridge, il paccheto deve risalire tutto lo stack ed essere 
gestito in software, al gigabit non ci arrivi così. su queste CPU
Quel che devi fare, e probabilmente quel che intendevi, è agire sulla 
configurazione dello switch per mettere la porta blu nella stessa VLAN 
principale delle 4 gialle (rendendola, di fatto, come una gialla).

> Preferirei però un'opzione con 8 porte per futuri upgrade.
>

Ci dici il tuo caso d'uso? La configurazione che vorresti poi implementare?
Perchè potrebbe essere tranquillamente che la cosa che ti tecnicamente ha più 
senso sia un 3600 + uno smart switch.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] airMAX Omni e Rocket M

[Stefano De Carlo]

Il 25 novembre 2014 20:37, Davide Bettio  ha scritto:
> Ultima curiosità, ubiquiti sul suo sito afferma: "2x2 MIMO performance in
> Line-of-Sight (LOS) or Non-Line-of-Sight (NLOS) applications."

Te lo dicono come ti potrebbero dire "best used with Ubiquiti base
stations". Vuol dire tutto e niente.
Entro certi limiti NLOS "va", di certo non te lo garantiscono ne consigliano.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] NanoBeam, le nuove NanoStation?

[Stefano De Carlo]

Il 24/11/2014 19:40, Ilario Gelmetti ha scritto:
> Ciao gente!
> Qualcuno ha mai usato le NanoBeam? [1,1a]

NBE-M5-16 e 19.
Anche le 300, ma quelle sono eredi della NanoBeam.
Oltre che in Ninux le abbiamo usate anche per un lavoro in condizioni di NLOS, 
camminano!

> Pare siano perfino supportate da OpenWrt! [2]
> Il modello meno direttivo fa 16dbi, ossia quanto fa una NanoStation M5
> sulla carta, poi non riesco ben a capire dai grafici nei datasheet
> [3,4,4a] se ci sia una differenza sostanziale e in quale senso.

Eccome, hanno il doppio della direttività vs NSM5.

> Dunque la domandona è:
> le NanoBeam 16dbi rendono di fatto obsolete le NanoStation M5?

Si.
Migliori spec, specialmente sul beamwidth.
Per raggiungere la stessa flessibilità di montaggio che hai con le NBM5, con le 
NSM5 dovevi prendere degli accessori.
È migliorato il lato estetico che era un fattore per i WISP, a noi ce ne frega 
davvero poco.
Costi più bassi.

L'unico problema è
* la disponibilità relativamente bassa
* il software: OpenWrt soffre un po' di frescura su questo device e soprattutto 
con AirOS XW ci sono problemi di compatibilità con apparati legacy Ubiquiti [1].


> Ciao,
> Ilario
>
> [1] http://www.ubnt.com/airmax/nanobeamm/
> [1a] nella famiglia NanoBeam originariamente rientravano anche modelli
> più direzionali, poi rinominati in PowerBeam, chissà perché... Invece ha
> tenuto il nome di NanoBeam il modello da 19dbi

Avevano bisogno di un rebrand a) per funzionalità 802.11ac e b) e un po' di 
"facce fresche" causa tutta la pubblicità negativa alle serie XW tra gli 
addetti ai lavori.

Stefanauss.

[1] http://ml.ninux.org/pipermail/wireless/2014-September/016288.html




signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] no address range available for DHCP request

[Stefano De Carlo]

Il 19 novembre 2014 15:52, Matteo Arlotti - DNS LAB 
ha scritto:
> Secondo voi perche ricevo un LOG del genere se cerco di accedere alla mia
> picostationM2 via wifi?
>
> Wed Nov 19 14:44:20 2014 daemon.warn dnsmasq-dhcp[14851]: no address range
> available for DHCP request via eth0.3
>

Perchè in broadcast ricevi richieste DNS e non hai un range preparato
a servirle.

> La picostation è sulla eth0.3. Ho anche abilitato il DHCP server (.126/.200)
> per quella interfaccia, su un range diverso da quello abilitato per la
> br-lan (.100/.125)

Occhio che "limit" non è la massima "host part" dell'indirizzo IPv4, è
il numero *totale* di indirizzi servibili dal range.
Quindi se per br-lan hai messo start 100/limit 125, in realtà gli stai
dicendo di servire da x.y.z.100 a x.y.z.224, che chiaramente ti
sconfina in quello che hai impostato per eth0.3.

Potrebbe essere questo?

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Comprare nanostation (a basso costo)

[Stefano De Carlo]

Il giorno 04 novembre 2014 22:08, Carlo Reggiani 
ha scritto:

>
> Partendo dai 77 euro di riferimento di Amazon.it (spedizione e IVA
> inclusi) ho trovato su
> http://www.nventawires.it/ubiquiti-nanostation-m5.html prezzi
> interessanti:
>
> dai 10 pezzi in su sono sui 68 euro con IVA e spese spedizione.
>
>
> Conoscete questo fornitore? Altri che fanno scontistica maggiore?
>
>

a Cosenza [http://wiki.ninux.org/GruppoAcquisto/Cosenza] abbiamo fatto 2
ordini da 1500€ di materiale, nessun problema.

La scontistica era quella applicata sul sito per grossi quantitativi, con
in più un qualcosa a metà per quantitativi intermedi tra due scaglioni. Non
ti so quantificare perché non ricordo le differenze esatte tra quanto
esposto lato-web e quanto corrisposto.

Contatta telefonicamente, dì che sei di Ninux e capiscono l'antifona, ma è
veramente molto molto meglio se ti assicuri di fare ordini di almeno 1000€.

Stefanauss
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] OLSR su PfSense

[Stefano De Carlo]

Il 03 novembre 2014 21:54, Michele Salerno  ha scritto:
> Strefanauss, io penso che è qualcosa nella GUI del pfsense che non
> funzionaa questo punto si fa uno scritino che funziona, magari via cron
> si fa un killall ogni x tempo con restart del comandoe via!
> Trovare una soluzione perfetta è l'ideale, ma se non va...
> se poi vogliamo scaricare il pacchetto e crearne uno nostro "ninux" è un
> altro discorsoanche se l'idea non è male!
>

Io "insisto" perché abbiamo un fw pfSense deployato e il boot non
fallisce mai. Quindi se po fa.
E anche perché se capiamo cos'è lo scriviamo da qualche parte e chi lo
farà dopo non deve ripassarci.
Ma va bene anche It Just Works (TM)

:)

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] OLSR su PfSense

[Stefano De Carlo]

Il 03 novembre 2014 21:50, Michele Salerno  ha scritto:
> con il comando manuale parte senza problemi
> ho provato anche a togliere il comando:
> announce self as Dynamic Gateway = yes
>
> ma sto notando che l'interfaccia gui da il simbolo X...come servizio
> stoppato
>
> facendo un ps aux !grep olsrd
> ho questo output
> root   31809  0.0  0.2  3324  1556  ??  S 9:48PM   0:00.08
> /usr/local/sbin/olsrd -f /var/etc/olsr.conf
> root   89066  0.0  0.1  3468  1232   0  S+9:48PM   0:00.01 grep olsrd
>
>
> premetto, l'output è dopo il riavvio del fw.
>

S sto capendo bene la situazione attuale è che
* È enabled sulla GUI
* nonostante questo, non ti parte automaticamente all'avvio
* Se avvii manualmente, col comando sopra citato che fa riferimento
stesso file di config che lui si autogenera (var/etc/olsr.conf),
parte.

Ammesso che abbia inteso bene

1) In che parte di pfSense di da la X-servizio-stoppato?
2) Riavvia il fw, e posta l'output di Status: System logs: Routing

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] OLSR su PfSense

[Stefano De Carlo]

Il 02 novembre 2014 19:36, Michele Salerno  ha scritto:
> Allora, ho cancellato quella precedente, ho tolto dal boot il mio scritptino
> ed ho compilato i campi così:
>

È ok così.
Adesso? Ancora non ti si autoavvia?
Cosa succede all'output di olsrd -f /var/etc/olsr.conf adesso che hai
fixato la riga 30?

Se ancora non ti funziona, oltre a incollare qui il nuovo errore, fai
anche una prova togliendo la spunta a

announce self as Dynamic Gateway = yes

non vorrei che le due sintassi HNA diverse creino problemi.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Linux Day 2014, ci raccontate qualcosa?

[Stefano De Carlo]

Il 01 novembre 2014 18:03, Nemesis  ha scritto:
> Ciao a tutti,
>
> ci potreste raccontare qualcosa?
>
> Ad esempio:
>
> c'era gente?

Una 40ina

> era la vostra prima presentazione su ninux?

La seconda, ma la prima di tipo divulgativo.

> dopo il linux day ci sono state nuove partecipazioni?

La solita leggera impennata di contatti.
Però forse comincia una collaborazione veramente veramente
interessante, credo inedita in Ninux :) Vedremo.

> pensate che ci sono cose che si dovrebbero migliorare nelle prossime
> presentazioni?

Devo ridurre di almeno 20 minuti il running time xD

> che impressioni avete avuto?

Se te la giochi bene c'è curiosità, la gente ti segue e s'appassiona.
Penso che fosse genuina perché su 18 slides 6 erano di NON SIAMO/DIAMO
Internet, e nessuno mi ha chiesto "si ma Internet?" dopo.

> avete qualche foto che possiamo pubblicare?

Not really.

> avete già caricato le vostre presentazioni qui:
> http://wiki.ninux.org/Presentazioni ?
>

Le metto quando ho un hosting definivo.
Le ho viste su twitter di Ninux però.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Ai ninuxer più attivi: FATEVI UNA CHIAVE PGP

[Stefano De Carlo]

Il 02 novembre 2014 11:38, Nemesis  ha scritto:
> Spesso mi capita di dover mandare delle password in giro, intercettando
> queste password si possono fare molti danni.
>
> Perfavore, vorrei esortare tutti i referenti ei membri più attivi che oramai
> sono divenuti un punto di riferimento a farsi una chiave PGP.
>
> Nemesis
>

http://pgp.mit.edu/pks/lookup?op=vindex&search=0xA2EA3AEEE9B2DDEA

(tu già ce l'hai)

N.B. Retroshare defaulta a 2048bit invece di 4096, e usa un suo
keyring separato. Insomma, sarebbe preferibile non usare le sue chiavi
per altro.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] OLSR su PfSense

[Stefano De Carlo]

2014-11-02 11:55 GMT+01:00 Michele Salerno :
> facendo un cat -n | grep 30
> la riga interessata è
> 30  10.27.0.0/255.255.255.0
>
> Hna4
> {
> 10.27.0.0/255.255.255.0
> 0.0.0.0 0.0.0.0
> }
>
> qui ho capito che non vuole la / ma uno spazio, di default inserisce anche
> 0.0.0.0 che indica la presenza di internet...ok!
>

Infatti. La sintassi corretta, lato file-config, è con uno spazio tra
network address e subnet mask, oppure direttamente in CIDR.
Ogni altra cosa causa errore di parsing.

Che cosa hai compilato nel campo Services > OLSRD > "Announce Dynamic
local route"?
Indendo proprio copia-e-incolla, come è la sintassi che hai usato?

Io per annunciare due voci HNA nella GUI di pfSense devo scrivere nel
campo "Announce Dynamic local route"

10.87.1.0/24, 10.11.12.13/32

e nient'altro.
Questo corrisponderà, poi, a:

Hna4
{
10.87.1.0/24, 10.11.12.13/32
}

Non so cosa hai nel campo "Announce ecc ecc", ma sembrerebbe ci sia
un'alternanza di sintassi.
Scegline una e applicala a entrambe le voci, dovrebbe andare.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] OLSR su PfSense

[Stefano De Carlo]

Il 27 ottobre 2014 22:54, Michele Salerno  ha scritto:
> Stefanauss, quella riga non l'ho trovata.
> Allego il file di che hai indicato.
> Premetto che è la versione di pfsense 2.1.5 ed il pacchetto di olsr è la
> versione 1.0.1
>

Ciao Michele,

niente, non la trovi perchè (finalmente!) hanno fixato il bug. Quindi
non è quello il problema.

Spulciando il thread ho notato che log dell'errore non ne hai postati.
Per far partire al boot OLSR su pfSense conviene avviarlo nel
"pfSense-way", lasciando che faccia le sue cose e semplicemente
moddando quello che serve.

Fai cosi:
- Disabilita il tuo avvio manuale
- Configura pfSense da GUI con le opzioni che ti interessano
- Fai enable, e chiaramente non ti parte
- vai da terminale e manda

olsrd -f /var/etc/olsr.conf

e incolla qui in lista l'output.
È rilevante perchè in questo caso /var/etc/olsr.conf è il file
autogenerato da /usr/local/pkg/olsrd.inc, quindi l'output dovrebbe
contenere indizi sul problema che impedisce l'autoboot del demone.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Server, domini, dns, vpn

[Stefano De Carlo]

Il 30 ottobre 2014 23:30, Michele Salerno  ha scritto:
> Vorrei sapere quali sono i dns della rete ninux

AFAIK Ninux non ha name server pubblici.
Di conseguenza quanto sotto riportato è relativo al tirare su un
server DNS interno, che sia autoritativo per il/i tld dell'isola e in
più faccia da Recursive Caching per i domini Internet.

Ninux ha due sottoreti:

10.11.12.0/25
10.10.10.0/24

riservate a servizi anycast, tra cui il DNS.

In queste subnet sono riservati per i DNS

10.10.10.10 DNS Primario
10.10.10.11 DNS Secondario

Ma anche (perchè ormai ce ne sono parecchi in giro)

10.11.12.13 DNS Primario
10.11.12.14 DNS Secondario

Usa quale ti garba delle due convenzioni, ma poi rendile uno
"standard" nella tua isola.
A Cosenza usiamo 10.11.12.13, per esempio.

> e qual'è l'estensione (tld) usata.

A Roma usano .nnx
In Calabria ci siamo autoritativizzati per
- .cs
- .cal
- .calabria
- .ninux

ma da prima dei generic tld di ICANN, che se gli gira potrebbero
collidere in futuro con cal e calabria (molto molto improbabile, ma
vai a sapere).

Puoi usare nnx se vuoi, o .ninux, ma nel momento in cui poi
colleghiamo le nostre isole in VPN Isole, non possiamo essere
autoritativi entrambi per quel tld, e dovremo coordinarci per le
deleghe (DNS sucks big time).

Consiglio: scegliti un tld carino che non sia già qui:
http://data.iana.org/TLD/tlds-alpha-by-domain.txt
e che non abbia troppa probabilità di esserci un giorno,
e usa quello.

.matera?

Ma considerato che il DNS non lo pieghi alla decentralizzazione in un
milione di anni, && se vuoi fare una cosa spettacolare && vuoi
smanettare:

http://namecoin.info/ (domini .bit)
oppure
http://dotp2p.io/ (domini .p2p)

> Sui domini interni che policy ci sono? intendo stile CAP
> attualmente, in fase di test, l'ho chiamato cloud.ninux.loc
>

Nessuna. Ma credo che riservare/mettere da parte la zona
nomenodo.miotld per poterla delegare ad ogni nodo che ne faccia
eventualmente richiesta sia scontato.

Docs (non aggiornatissimi): http://wiki.ninux.org/DnsInterno

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] OLSR su PfSense

[Stefano De Carlo]

Il 22/10/2014 19:45, Michele Salerno ha scritto:
> Ma il punto è anche...come lo avvio al boot?

Devi modificare il file /usr/local/pkg/olsrd.inc e commentare la riga

LinkQualityWinSize 10

È un'opzione deprecata fin già da olsr 0.6.3 incluso in pfSense 2.1.x, ma è 
stata erroneamente inclusa nel template di generazione della configurazione, e 
quindi il demone s'incazza quando la trova.

Commenti la riga, togli la spunta ad enable olsr, apply, la rimetti, apply. E 
dovrebbe essere partito da solo a quel punto. Chiaramente disabilita il tuo 
script per esserne sicuro.

Attento che devi ripetere la procedura ad ogni successivo upgrade di pfSense 
2.1.x.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo Pollutri::Nickloris attivo

[Stefano De Carlo]

Il 20/10/2014 16:43, Emanuele ha scritto:
>
> Gia che ci siamo avrei dovuto scrivere anche io per lo stesso motivo.
>
> Potete marcare il nodo "Emanuele" come attivo?

Attivo.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo Pollutri::Nickloris attivo

[Stefano De Carlo]

Il 20/10/2014 17:19, Saverio Proto ha scritto:
>> Penso che le persone in "contatti" possano benissimo gestire anche il
>> mapserver.
>> Eviterei la possibilità di attivare i nodi da singoli utenti se no ci
>> troveremmo migliaia di nodi attivi quando invece non è vero.
>> E' anche un modo per "farsi vivi".
> Fabio mi hai frainteso.
> Giuseppe De Marco è attivissimo in Ninux Calabria. Volevo dire di dare
> anche a lui le credenziali per attivare i nodi perché è una persona
> molto presente in quell'isola.
>
> Giuseppe scrivi su conta...@ninux.org che ci organizziamo.

Non credo sia più necessario, ho condiviso con Peppe privatamente l'unico 
account che utilizziamo per tutta Cosenza, che ci ha fornito Clauz all'epoca.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Samsung rivoluziona la tecnologia del WiFi

[Stefano De Carlo]

"Gli attuali 108 Mbps"?

Vabbhè dai, dovremo riscrivere un pochino il reghack :)

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] Corso Advanced Networking @ Hacklab Cosenza

[Stefano De Carlo]

Ciao a tutti,

volevo segnalare che questo Sabato parte il corso di Advanced Networking 
organizzato dall'Hacklab Cosenza.
Tutte le info qui: http://hlcs.it/formazione/advanced-networking/

Il corso segue il curricula della certificazione Cisco CCNA, che poi integriamo 
con seminari specifici sul networking in GNU/Linux e OpenWrt, oltre a special 
mentions per reti mesh e OLSR. Lo teniamo in 3-4 ninuxer calabri (io, Spax, 
Petruzzo e Vin-San).

Tutte le lezioni sono videoregistrate e in streaming, gratuite. Partiamo da 
zero, quindi può essere un'ottima occasione per i Ninuxer in erba :)

Per chi vuole conseguire effettivamente la certificazione CCNA, c'è una quota 
da versare all'associazione. Il corso si può seguire anche da remoto, 
interamente, con i (pochi) downside specificati nella info.
In ogni caso, per chi semplicemente vuole cominciare a studiare le reti 
dall'ABC, 100% free.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Corriere della Sera: La nuova carta dei diritti di internet

[Stefano De Carlo]

Il 14 ottobre 2014 11:59, Nemesis  ha scritto:
> Abbiamo veramente bisogno di questa carta?
>

In base a quante volte, in uno qualsiasi dei dibattiti sulle questioni
relative ai 14 punti, ho sentito varianti di "non si può pensare di
applicare a Internet normative pensate 50 anni fa", allora ti dico di
sì, l'idea di ricominciare dal principio a redarre testi specifici è
probabilmente corretta.

Sui contenuti, se ne deve discutere.
Non è un brutto testo, ma è sconvolgentemente debole su alcune cose,
sul post-Snowden.

E comunque, chiaramente con contenuti in larga parte diversi, non è un
brutto format per un futuro manifesto Ninux. Punti chiari e brevi, con
i rationale altrove.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo Kali su Matera

[Stefano De Carlo]

Il 13/10/2014 20:18, Michele Salerno ha scritto:
>
> Comunque ho cambiato io gli IP (non è giusto che li cambiano i torinesi, 
> immaginavo che mi fossero state assegnate dai gestori.
>
> Ho messo:
> Backbone Basilicata 172.75.0.0/16 
> Backbone Matera 172.75.0.0/24 
> LAN space HNA 10.75.0.0/24 
>
> Come nodo mi sono preso la 10.75.0.0/24 che ho diviso in 
> 2 /25
> Una sottorete la uso come gestione e l'altra come hotspot
> Cosa ne pensate?
>

172.75.0.0/16 è una subnet di indirizzi *pubblici*. Internet.
È completamente fuori dall'indirizzamento Ninux, che copre l'address space 
descritto nella RFC1918.

 10.0.0.0-   10.255.255.255  (10/8 prefix)
 172.16.0.0  -   172.31.255.255  (172.16/12 prefix)
 192.168.0.0 -   192.168.255.255 (192.168/16 prefix)

Non puoi andare fuori da questi range.
Leggi attentamente le prime sezioni di http://wiki.ninux.org/GestioneIndirizzi
Anche questo forse può fare chiarezza: 
http://wiki.ninux.org/IndirizziCalabria#Coordinamento_con_l.27indirizzamento_complessivo_Ninux.org

Oltre a questo, sul gestore indirizzi c'era una folder Basilicata, ma la folder 
è un meccanismo di immissione che non consente di usufruire del warning quando 
si sta prendendo un indirizzo già occupato.
Le subnet vanno inserite con "Root Subnet" 10.0.0.0/8 (se LAN space) o 
172.16.0.0/12 (se Backbone).

Per farla breve ho sistemato direttamente io, spero che non ti dispiaccia.
Ho preservato il numero comune (10.x, 172.x), una comodità che probabilmente 
volevi.

Basilicata Backbone: 172.27.0.0/16
Basilicata LAN: 10.27.0.0/16

http://indirizzi.frm.ninux.org/subnets/3/681/
http://indirizzi.frm.ninux.org/subnets/3/682/

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] [Ninux-Calabria] openwrt nanobridge

[Stefano De Carlo]

Il 12 ottobre 2014 20:05, BornAgain  ha scritto:
> Ciao ,
>
> devo caricare openwrt su una nanobridge.
>
> sapete indicarmi di Scooreggione quale imm devo mettere?
>
> http://stud.netgroup.uniroma2.it/~saverio/scooreggione-AA-v5/
>

openwrt-ar71xx-generic-ubnt-bullet-m-

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo Kali su Matera

[Stefano De Carlo]

Il 12/10/2014 00:56, Michele Salerno ha scritto:
> Ho rifatto le configurazioni seguendo la guida del routing a terra ma c'è 
> qualcosa che non va.
> Ho fatto degli screenshot
> http://topmodelcompany.com/docs/Nodo_Kali_MT.pdf
> il dominio è solo di appoggio per il PDF
> Quando ho fatto i test con l'antenna integrata mi funzionava. Con la Bullet 
> M2 no.
> Un client che si connette all'AP (m2) non ottiene l'IP dal server DHCP 
> configurato in PfSense.
> La M5 non essendoci nessuno vicino a me non posso testarla.
> E' tutto il giorno che ci sbatto sopra, qualcuno può illuminarmi su dove 
> sbaglio?
>

Ciao Michele,
Con la configurazione che hai fatto hai "messo a terra" anche la Bullet M2, ma 
da come hai descritto la tua "idea per Kali", la M2 deve fare distribuzioni ai 
client finali ovvero: chi si collega alla M2 non fa girare il protocollo di 
routing.

Mi pare di capire che tu ti aspettavi che i client collegati alla M2 
ottenessero in DHCP l'indirizzo 10.23.0.x da pfSense.
Questo è impossibile, perché sulla Bullet il bridge è tra Wifi e VLAN4, che sul 
tp-link ha
- Indirizzamento 172.23
- DHCP Server disabilitato (non si vede negli screenshot, ma è il default, 
quindi presumo di si)

In sostanza l'errore è che la M2 non va configurata con routing a terra.

Sull'antenna: niente VLAN, la lasci nel bridge di default tra WLAN0 e LAN0. Al 
bridge assegni un altro 10.23.0.x statico e come gw 10.23.0.1 (pfSense)
Sul TP-Link: cancelli completamente ANT_M2, la corrispondente VLAN, e imposti 
la porta (untagged) nella VLAN 10.

E adesso i client collegati alla M2 prendono l'indirizzo dal DHCP di pfSense 
sulla NIC Ninux.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Bug Watch: NanoBeam/XW vs Legacy/XM, flapping TX/RX rate

[Stefano De Carlo]

Il 16 settembre 2014 18:53, Stefano De Carlo  ha scritto:
> (scusate la lunga mail ma è impossibile sintetizzare qui)
>

(il report era qui:
http://ml.ninux.org/pipermail/wireless/2014-September/016288.html )

Il Changelog di AirOS 5.6 beta 5 sembra finalmente interessante:

- Fix: AirMax Capacity/Quality are fixed with Fixed Rates
- Fix: TX queue stop instead of silent TX packet drop, also multiqueue
support for proper priority handling. (XW)
- Fix: Error after run Speed Test (XW)
- Fix: ACK/Distance miscalculation when connecting to XM AP. (HT8, HT30, XW)
- Fix: AP/STA performance issues (XW, airMax).
- Fix: HT20 Rates are reported/used when device is configured to
operate in HT40 and fixed rate is selected. Alternative rate module
selected

Purtroppo abbiamo il nodo dove facevamo le comparative down, quindi il
test di questa nuova beta è rimandato.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Aggiornare AIROS?

[Stefano De Carlo]

Il 09/10/2014 15:32, federico la morgia ha scritto:
> Secondo me questa è la parte importante dei problemi visti su questa ML.
> Fixes:
> - Fix: Ethernet negotiation issues when using 100Mbps PoE with gigabit 
> capable devices
> Improvements: 
> - Low TX issue improvements
> - airMax: Improvements for narrow channel widths usage scenarios
> - airMax: Improvements addressing Low TX when connecting to XM AP
> - Ethernet: 100Mbps negotiation for NanoBeam M5 400 (XW) and Rocket M5 
> Titanium (XW)
> - Data rates: Improved Data Rate selection when connecting to XM devices
>
> Sarebbe da sperimentare per chi ha un ponte radio tra apparati XW se 
> veramente qualche cosa migliora oppure bisogna ancora attendere.

Qui abbiamo provato già la 5.5.10-RC3 (che dovrebbe essere identica alla final) 
sul link buggato dai datarates di cui parlavo qui:

http://ml.ninux.org/pipermail/wireless/2014-September/016288.html

ma la situazione non è migliorata di una virgola.
Proveremo per scrupolo la final appena possibile, ma 99% è tutto uguale.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Aggiornare AIROS?

[Stefano De Carlo]

Il 09/10/2014 14:54, leandro Noferini ha scritto:
>
> XM, per ora lascio il 5.5.8 che ho allora.
>
>> Confronta i changelog:
>>
>> http://dl.ubnt.com/firmwares/XW-fw/v5.5.10/changelog.txt
>> http://dl.ubnt.com/firmwares/XM-fw/v5.5.10/changelog.txt
> Non li trovo.
>
>
> [...]

Sorry: http://dl.ubnt.com/firmwares/XN-fw/v5.5.10/changelog.txt

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Aggiornare AIROS?

[Stefano De Carlo]

Il 09/10/2014 14:22, leandro Noferini ha scritto:
> Ciao a tutti,
>
> ho visto che per la mia M5 c'è l'aggiornamento ad AirOS 5.5.10: qualcuno
> l'ha già provato? È da mettere?

Se hai una NanoStation della serie XW, è estremamente consigliato.
Se XM non serve.
Confronta i changelog:

http://dl.ubnt.com/firmwares/XW-fw/v5.5.10/changelog.txt
http://dl.ubnt.com/firmwares/XM-fw/v5.5.10/changelog.txt

P.S. Se stai upgradando da 5.5.6 e sei in compliance test occhio:
* lo hanno rimosso nella 5.5.8
* Ora c'è il lock per quasi tutte le country: una volta selezionate devi 
resettare per cambiarle.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nuova Isola Torino

[Stefano De Carlo]

Il 07/10/2014 15:47, Ste Sca ha scritto:
> Ciao  a tutti,
> volevo aggiornarvi sugli sviluppi del gruppo di Torino.

Happy Ninux anche a Torino ragazzi :)

>
> Inizieremo da due nodi fra me e Uby per poi diramare verso altri. Ho 
> prenotato gli indirizzi
> per le connessioni backbone da gestire con il metodo del CAP, che mi è 
> sembrata una
> bella idea, sul 172.23.0.0/16 per Torino. Nella zona 
> mia e di Uby CAP 10137 ci divideremo
> la 172.23.37.0/24 .
>
> Mentre per le LAN locali ci divideremo la 10.23.37/24 fra me e Uby. Sottorete 
> della 10.23.0.0/16 .
>

Appena puoi, inserisci le sottoreti prenotate anche su 
http://wiki.ninux.org/GestioneIndirizzi, che per ora abbiamo deciso di 
mantenere in-sync con il CMS, per transizionarci completamente solo più tardi.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] photogallery down

[Stefano De Carlo]

Il 06/10/2014 23:11, Giuseppe De Marco ha scritto:
> Coppermine critical error:
> Unable to connect to database !
>
> MySQL said: Can't connect to local MySQL server through socket
> '/var/run/mysqld/mysqld.sock' (111)
>
>
> ps = stesso errore anche http://fotogallery.ninux.org

Ok, ora siamo di nuovo up.
Stanno DDoSsando il server, quindi si, insomma, all'erta :)

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Vorrei iscrivermi

[Stefano De Carlo]

Il 05/10/2014 02:34, Andry ha scritto:
> Salve a tutti

Ciao Andry,

questo messaggio è arrivato correttamente alla Mailing List, quindi risulti già 
iscritto ^^

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] Fwd: [OpenWrt-Devel] Barrier Breaker 14.07 Final

[Stefano De Carlo]

 Messaggio Inoltrato 
Oggetto:[OpenWrt-Devel] Barrier Breaker 14.07 Final
Data:   Thu, 02 Oct 2014 14:59:08 +0200
Mittente:   Steven Barth 
A:  openwrt-de...@lists.openwrt.org



The OpenWrt developers are proud to announce the final release
of OpenWrt Barrier Breaker.

  ___ __
 |   |.-.-.-.|  |  |  |..|  |_
 |   -   ||  _  |  -__| ||  |  |  ||   _||   _|
 |___||   __|_|__|__||||__|  ||
  |__| W I R E L E S S   F R E E D O M
 -
 BARRIER BREAKER (14.07)
 -
  * 1/2 oz Galliano Pour all ingredients into
  * 4 oz cold Coffeean irish coffee mug filled
  * 1 1/2 oz Dark Rum   with crushed ice. Stir.
  * 2 tsp. Creme de Cacao
 -

http://downloads.openwrt.org/barrier_breaker/14.07/

Important changes since RC3
* various ath9k related fixes
* a few board related fixes
* fixes for packages depdending on curl
* per feed download folders

Important changes since RC2
* NAT & firewall throughput improvements
* Security updates for OpenSSL & PolarSSL
* Minor fixes in DHCP & DHCPv6 handling
* Configuration support for GRE tunnels
* Various other fixes

Important changes since RC1
* fix a long standing ath9k deadlock bug
* all feeds are now built
* image builder now works and RC2 contains all board specific images
* various board/stability fixes

** Highlights since Attitude Adjustment **
Default configuration and images

* Linux kernel updated to version 3.10
* Procd: new preinit, init, hotplug and event system written in C
* Native IPv6-support
- RA & DHCPv6+PD client and server
- Local prefix allocation & source-restricted routes
  (multihoming)
* Filesystem improvements
- Added support for sysupgrade on NAND-flash
- Added support for filesystem snapshot and rollback
- Rewritten mounting system in C for rootfs and block devices
* UCI configuration improvements
- Support for testing configuration and rollback to working
  last working state
- Unified change trigger system to restart services on-demand
- Added a data validation layer
* Networking improvements
- Netifd now handles setup and configuration reload of
  wireless interfaces
- Added reworked event support to allow obsoleting network
  hotplug-scripts
- Added support for dynamic firewall rules and zones
- Added support for transparent multicast to unicast
  translation for bridges
- Various other fixes and improvements

Additional highlights selectable in the package feeds or SDK
* Extended IPv6-support
- Added DS-Lite support and improved 6to4, 6in4 and 6rd-support
- Experimental support for Lightweight 4over6, MAP-E and MAP-T
- Draft-support for self-managing home networks (HNCP)
* rpcd: new JSONRPC over HTTP-frontend for remote access to ubus
* mdns: new lightweight mdns daemon (work in progress)
* Initial support for the musl C standard library
* Support for QMI-based 3g/4g modems
* Support for DNSSEC validation
* Added architecture for package signing and SHA256 hashing
* ... and many more cool things

Package feed reorganization
For quite a while already we are not very satisfied with the quality
of the packages-feed. To address this, we decided to do a fresh start
on GitHub. The new feed https://github.com/openwrt/packages should be
used from now on and package maintainers are asked to move their
packages there. For the final release we will still build the old
packages feed but it will be necessary to enable it manually in the
opkg package list to be usable.
Additionally we would like to give a big thank you to all of our 
package
maintainers working on our various feeds.

New build servers
We would like to express our gratitude to Imagination Technology for
funding the 2 build servers that we used for the release.

Whats next ?
We aim at releasing Chaos Calmer (CC) before the end of the year. The
CC release will use 3.14 or a newer LTS kernel as baseline.


Have fun!
The OpenWrt developer team
___
openwrt-devel mailing list
openwrt-de...@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel






signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Switch decente

[Stefano De Carlo]

Il 02/10/2014 10:16, Gabriele Jon Ficarelli ha scritto:
> Io in casa uso questo:
>
> http://www.amazon.it/dp/B92RRM/ref=pe_386201_37038291_TE_dp_1
>
> ​funziona bene, è gigabit, costa poco, supporta le vlan​ ed è anche bellino 
> (tutto in metallo)
>
>
> ​Ciao

Ciao,

quello che hai linkato è la versione NON-plus, che non è managed.
È sbagliato il link, oppure intendevi che non fa controlli su MTU e le lascia 
passare?

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo Kali su Matera

[Stefano De Carlo]

Il 01/10/2014 20:25, Michele Salerno ha scritto:
> Stefano, ho immaginato al rPi per ottimizzare i costima se questo 
> comporta l'acquisto di uno switch managed (che sicuramente è un mondo diverso 
> e migliore)i costi i non si ottimizzano.
>

È sufficiente uno "Smart" Switch. La TP-Link ne produce un modello gigabit 8 
porte da ormai solo 29€. Ce l'abbiamo su un nodo qui a Cosenza e funziona senza 
patemi.

Premesso che come costi e prestazioni un 4300 è ancora più conveniente rispetto 
a questa combo (30+30€, circa), chiaramente dipende dai tuoi obbiettivi. 
Potresti voler privilegiare la flessibilità di avere un vero e proprio PC con 
un Linux full-fledged sopra.

La cosa comincia a diventare universalmente interessante quando sostituisci 
alla rPi una delle tante altre board solo moderatamente più costose ma 
vastamente più potenti.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo Kali su Matera

[Stefano De Carlo]

Il 01/10/2014 19:24, Michele Salerno ha scritto:
>
> Interessante era se si riusciva a fare qualcosa di embedded su raspberry per 
> la gestione centralizzata delle antenne (routing a terra). Sarebbe comodo per 
> più nodi...con un DD su una CF...hai tutto semi-pronto e funzionante!

Ti serve uno switch managed o semi-managed per poter coinvolgere la rPi in 
un'operazione di routing a terra in un supernodo (antennE).
E hai solo ~60 Mbps di throughput a disposizione.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] edgerouter lite vs openwrt

[Stefano De Carlo]

Il 29/09/2014 21:03, Luca Postregna ha scritto:
> hanno fatto grossi passi avanti con l'ubiquiti edge router: 
> http://wiki.openwrt.org/toh/ubiquiti/edgerouter.lite
>
> sul mio ci gira il trunk perfettamente :D
>
> saluti
> LP

Anche pfSense 2.2 aggiungerà il supporto.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] WLAN Router FON2200 e configurazione UCI

[Stefano De Carlo]

Il 29/09/2014 20:36, Enrico Bassetti ha scritto:
>
> E mi è venuta in mente un'altra cosa da "programmazione domenicale 
> compulsiva" (rif. thread "ninux whois"): esiste un software che genera su PC 
> la configurazione, e poi la invia al device?

Non lo so ma...
Ci sono undocumented features di uci in giro, dispero che un config generator 
sia mai stato alto nelle priorità dei dev OpenWrt xD


> Oppure un software che usa le API per modificare la configurazione?
>

AFAIK le API ci sono solo da BB, nella forma di ubus

http://wiki.openwrt.org/doc/techref/ubus#access.to.ubus.over.http

col quale è possibile fare tante cose carine, tra cui anche accedere in 
scrittura alla configurazione attraverso HTTP

Ma anche qua è uno di quei casi in cui la documentazione *è il codice*.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Configurazione OLSR su OpenWRT

[Stefano De Carlo]

Il 29 settembre 2014 12:58, Nicola Ruscitto
 ha scritto:
> I default gw sia sui pc che i dispositivi (Smart TV,  cellulari ecc.) È
> settato sull'ip del router adsl.

Amesso che il ping dall'altra subnet arrivi (e dovrebbe, visto che
almeno all'antenna remota arrivi), al PC arriva un pacchetto che ha
come IP di origine quello dell'altra subnet.
Non avendo il PC una rotta specifica verso quella subnet, interpella
il default gw.
Ma se è il router ADSL, quello non sa dove si trovano le altre subnet
Ninux. Non sa come ritornare.

Per integrare il router ADSL e i suoi client in questo setup devi
impostarci sopra delle rotte statiche verso

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

che hanno come gw quello dell'antenna (che invece sa come arrivarci).

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Configurazione OLSR su OpenWRT

[Stefano De Carlo]

Il 29/09/2014 12:12, Nicola Ruscitto ha scritto:
> Buongiorno,
> sto provando da qualche giorno a smanettare con due antenne tp-link con 
> openwrt installato.
> Premetto che nelle mie prove il firewall in entrambe le antenne é 
> disabilitato.
> Il problema é che, nonostante abbia annunciato correttamente le sottoreti, da 
> una subnet non riesco a fare nessun ping sui pc della subnet vicina a parte 
> l'ip lan dell'antenna remota.
>
> cosa sto tralasciando?
>

Sembra uno di quei casi in cui il pacchetto arriva ma non sa come ritornare.
Sui pc della subnet che deve risponderti al PC, che default gw c'è? È 
l'antenna, o qualcos'altro?

> mi potete postare degli esempi di configurazione da /etc/config ?
>

Posta anche tu i tuoi
/etc/config/network
/etc/config/olsr
route -n

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] Random Linear Network Coding: TCP vs CTCP (Coded TCP)

[Stefano De Carlo]

Ciao,

http://www.electroyou.it/clavicordo/wiki/rlnc-random-linear-network-coding-verso-una-nuova-generazione-di-reti

in pratica è una tecnica che utilizza l'algebra lineare per risolvere i noti 
problemi del TCP, in particolare il fatto che abbia categoricamente bisogno di 
packet loss 0% per raggiungere throughput decenti, e che reagisce malissimo a 
perdite di pacchetti casuali, che interpreta subito come congestione.

Chiaramente c'è più di una menzione delle Wireless Mesh Networks tra i campi di 
applicazione.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] AutoSSH

[Stefano De Carlo]

Il 28/09/2014 10:41, Massimiliano CARNEMOLLA ha scritto:
> Ciao, ho installato questo pacchetto su OpenWRT, se lo faccio partire 
> manualmente funziona, al boot no.
>
> Se lancio ps il processo risulta in esecuzione.
>

Reboota,
poi posta l'output di logread.
Se autossh ha delle opzioni per aumentare il livello di verbose, prima di 
rebootare attivale.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo Kali su Matera

[Stefano De Carlo]

Il 26/09/2014 21:28, Michele Salerno ha scritto:
> Per avere una Bullet M2 stile M5

Ciao Michele,

che vuoi dire per "Stile M5"? (Nanostation M5?)

Quando l'antenna "dice POE" intende che l'alimentazione viene effettuata 
attraverso PoE. Tutte questa antenne Ubiquiti si alimentano tramite PoE.

Poi se l'alimentatore è incluso o meno è un discorso a parte.

Bullet M5 Titanium = Alimentatore POE incluso (come sulle NanoStation M5).
Bullet M2 Titanium = Alimentatore POE incluso (come sulle NanoStation M5).
Bullet M5HP = Alimentatore POE da acquistare a parte.
Bullet M2HP = Alimentatore POE da acquistare a parte

Se questo alimentatore a parte poi lo acquisto, l'unica differenza tra Titanium 
e HP diventa il telaio rugged. Per il resto sono identiche.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] messaggi e ordine cronologico

[Stefano De Carlo]

Il 25/09/2014 14:29, Andrea Milocco ha scritto:
>  
> Vorrei proporvi di rispondere sempre sotto al messaggio in modo che sia più 
> semplice leggere la "discussione" fatta da risposte multiple, ovvero in cima 
> il messaggio più vecchio e sotto una di seguito all'altra le risposte che 
> così automaticamente si leggono in ordine cronologico.
>
> Spero di essermi spiegato. Che ne pensate?
>

Ciao Andrea,

un pacato richiamo come il tuo a non effettuare il top-quoting fa sempre bene.
Purtroppo è difficile che tu possa trovare un riscontro tale da avere un 
impatto pratico, a breve. Anche chi sa che non si dovrebbe top-quotare tende 
comunque a farlo per ragioni che vanno dalla fretta, alllo smartphone, alla 
pigrizia. Non si sa mai, comunque.

Il mio consiglio è, se vuoi mantenere la modalità digest come è tua legittima 
preferenza, di usare le mail che ti arrivano come "reminder", ma di andarle 
effettivamente a leggere utilizzando la comoda funzionalità degli archivi (link 
in basso), secondo l'ordinamento che preferisci (thread o data).

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] profilo elevazione su nodeshot

[Stefano De Carlo]

Il 25/09/2014 02:05, leonaard ha scritto:
>
>> Ti va se lo pushiamo anche qui? https://github.com/ninuxorg/
> Ok

Ecco: https://github.com/ninuxorg/nodesquit
E ti ho aggiunto all'organization.

Già che ci sono ricordo ai coders ci sono ML dedicate all'hacking software 
Ninux:

http://ml.ninux.org/mailman/listinfo/ninux-dev

e una ancora più specifica per Nodeshot

http://ml.ninux.org/mailman/listinfo/nodeshot

>> Grazie
> Maddeche
>

Ho aggiunto la compatibilità con TamperMonkey/Chrome. La testo un po' meglio e 
poi pull-requesto.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] profilo elevazione su nodeshot

[Stefano De Carlo]

Il 24/09/2014 18:16, leonaard ha scritto:
> Ho scritto due javascripts per visualizzare via browser con immediatezza il 
> profilo altimetrico tra due nodi. E` codice buttato la ma se potesse servire: 
> https://gitorious.org/javasquits/nodesquit
>

Ciao Leonaard,

ti ho inviato una pull request per risolvere il bug dei nomi con ":", "::" e 
"-".

https://gitorious.org/javasquits/nodesquit/merge_requests/1

Ti va se lo pushiamo anche qui? https://github.com/ninuxorg/

Grazie, che cosa figa :) per lavoro uso sempre GreaseMonkey, ora lo userò di 
continuo pure in Ninux.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] profilo elevazione su nodeshot

[Stefano De Carlo]

Il 24/09/2014 22:52, leonaard ha scritto:
> On 09/24/2014 06:49 PM, Stefano De Carlo wrote:
>> ho provato a testarlo ma attivarli non permette più di selezionare la tab 
>> distanza.
>> Cliccandoci compare l'anchor nella barra degli indirizzi 
>> (http://map.ninux.org/#tab-dist), ma rimane in Dettagli Nodo.
>
> Avevo pushato i file sbagliati. Li ho aggiornati ma non escludo lo stesso 
> malfunzionamenti. Ciao
>

E infatti ora è a posto.
Grazie! È utilissimo.
Ti segnalo che il problema del trattino/duepunti è presente solo se il primo 
nodo selezionato ce li ha nel nome.

Es:
Stex -> ioggi-001 OK
ioggi-001 -> Stex KO

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] profilo elevazione su nodeshot

[Stefano De Carlo]

Il 24/09/2014 18:16, leonaard ha scritto:
> Ho scritto due javascripts per visualizzare via browser con immediatezza il 
> profilo altimetrico tra due nodi. E` codice buttato la ma se potesse servire: 
> https://gitorious.org/javasquits/nodesquit
>
> Il nuovo nodeshot avra nativamente questa funzione credo.
>

Ciao leonaard,

ho provato a testarlo ma attivarli non permette più di selezionare la tab 
distanza.
Cliccandoci compare l'anchor nella barra degli indirizzi 
(http://map.ninux.org/#tab-dist), ma rimane in Dettagli Nodo.

Se disabilito "alpha" il tab distanza funziona, compare il pulsante profilo, si 
apre il profiler ma nessuna elevazione: mi chiede di cliccare manualmente due 
punti sulla mappa.

Idea fighissima e comodissima comunque :)

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Info newbe

[Stefano De Carlo]

Il 23/09/2014 10:15, momo ha scritto:
> La mia domanda sul ripetitore perchè l'ho fatta?
> Ci sono casi in cui la distanza tra 2 punti "popolati" e maggiore di
> 10Km quindi nel mezzo in teoria andrebbe installato un node "fantasma"

Ciao momo,

questo è come ragionerebbe e opererebbe un operatore telefonico o
comunque di telecomunicazioni.
Ninux invece vive, prospera e si espande quando i nodi sono "vivi e
vegeti", mantenuti da persone che se ne occupano e interagiscono con la
community.
Quindi per quanto un ripetitore "stupido" sia tecnicamente fattibile, la
preferenza naturale della community è cogliere ogni occasione per fare
nuovi nodi "intelligenti", per ragioni che sono sicuro saranno chiare
quando avrai letto un po' di docs ^^

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo Kali su Matera

[Stefano De Carlo]

Il 22/09/2014 00:21, Michele Salerno ha scritto:
>
> Cmq penso che allora ci vuole una "corda passacavi" più lunga3-4
> mt non basta.costano tanto una da 20 mt?

Io ho preso questa:
http://www.amazon.it/Electraline-61055-Sonda-Tiracavi-Diametro/dp/B00EAQKN5C

Fatti aiutare da qualcuno, a far passare due cavi in un ø 16 ci metti 5
minuti in due, da solo rischi di non riuscirci per niente (probabilissimo).

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo Kali su Matera

[Stefano De Carlo]

Il 20/09/2014 16:48, Michele Salerno ha scritto:
> Differenza??
> Ho visto che c'è anche una titanium...è migliore?
>

A livello radio è identica.
Cambia
* ha un'armatura di metallo weatherproof
* include il POE, mentre la Bullet M2/M5 HP normale ne è priva e va
comprato a parte.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo Kali su Matera

[Stefano De Carlo]

Il 20/09/2014 16:45, Michele Salerno ha scritto:
> Ok...ci sto!

Ok :)
Ma mi domandavo un'altra cosa: hai tutto il tempo di approfondire, anche
con continue domande su questa ML e in chat, le caratteristiche di ogni
antenna in modo da essere convintissimo al 100% del parco hw che vuoi
per te. C'è tutto il tempo, mi sembra che tu abbia facile accesso al
luogo d'installazione e che quindi puoi fare un montaggio progressivo,
espansione dopo espansione.
Non c'è una ragione precisa per partire con un supernodo tutto-e-subito,
mi sbaglio?

> Non so se si è notato ma sono un fan di amazon, qui dalle mie parti
> non esistono negozi che vendono queste cose.

Con Amazon decisamente non risparmi su questi apparati, specie con tutti
i costi di spedizione.
Hai decisamente compreso e fatto tuo lo spirito "Ninux non è un
risparmio, è un costo", una cosa che è fondamentale capire, ma di certo
risparmiare qualche euro non farebbe male, no?
Se poi è una questione tua, di tranquillità perché con loro ti trovi
bene, è un altro discorso :)

> Come cerco la RM5 e la Sector 120?

"Rocket M5" per la stazione base, "Airmax Sector" per le antenne
settoriali da collegarvi.

> Per cella cosa si intende? E' un tipo di configurazione?
>

No, è più una questione logistica. Antenne disposte "a cella" è una
situazione dove hai antenne simili tra loro, con un angolo
d'illuminazione (beamwidth) simili, e le disponi in modo tale da coprire
tutti i 360° o giù di li con più esemplari opportunamente posizionati.

Esempio: 3 da 120° = 360
http://www.flyteccomputers.com/prodimg/image/540.jpg

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo Kali su Matera

[Stefano De Carlo]

Il 20/09/2014 16:32, Stefano De Carlo ha scritto:
> Il 20/09/2014 14:47, Michele Salerno ha scritto:
>> Bullet M2 è questo?
>> http://www.amazon.it/Bullet-High-Power-B2HP-Interfaccia/dp/B00DW2MMLS/ref=pd_sim_sbs_ce_1?ie=UTF8&refRID=07WBQASBD84C0EVESW4F
>>
> È lei, si.

Ops. No. È lei:
http://www.amazon.it/UBIQUITI-Networks-Bullet-M2-HP/dp/B00DTS6H2K/
Il modello è M2HP.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo Kali su Matera

[Stefano De Carlo]

Il 20/09/2014 14:47, Michele Salerno ha scritto:
>
> Bullet M2 è questo?
> http://www.amazon.it/Bullet-High-Power-B2HP-Interfaccia/dp/B00DW2MMLS/ref=pd_sim_sbs_ce_1?ie=UTF8&refRID=07WBQASBD84C0EVESW4F
>

È lei, si.

> Comunque qualche foto per dare l'idea del mio spazio visuale l'ho
> fatta e messa su http://photogallery.ninux.org/thumbnails.php?album=134
>

A me sembra che il tuo piano originario di fare un supernodo con me M5
sia ancora la scelta migliore per un supernodo che, credo, intende
facilitare al massimo l'aggancio di nuovi nodi in prospettiva.
Per il numero, 5, non saprei. Mi sembra eccessivo. Hai un discreto
numero di ostruzioni e la morfologia non sembra spettacolare.
Ma è una tua scelta anche in base a quanto budget vuoi dedicare al
progetto. Non ci sono dubbi che le RM5 siano superiori alle NSM5.
Al posto tuo:
* RM5 + Sector 120 verso quel varco che si allarga verso il nodo Ninux
che hai contattato.
* 2 NSM5 nel resto della cella.
* Bullet + Omni per distribuzione.


Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] TP-Link TL-WR1043ND v2.x, AR8237N strano e routing a terra

[Stefano De Carlo]

TL; DR: In fondo trovate le modalità con cui si può trattare questo
switch in modo che digerisca il routing a terra. Per configurarlo
correttamente vi serve solo leggere in fondo :)

TL; DS(croll): porta 6 sempre tagged + grhowto.

~~~

Ciao,

volevo condividere con voi alcune speculazioni sullo switch (AR8237N) di
questo router, che è elettronicamente cablato in maniera diversa dagli
altri che utilizzano lo stesso silicio (TL-WDR3500, TL-WDR3600,
TL-WDR4300, tra quelli supportati da NinucsWrt), e la cosa si riflette
in OpenWrt e ha un impatto sulla guida al routing a terra.

* Del silicio dell'AR8237N fanno parte dei MAC chip. Sono quei
componenti dello switch convertono i pacchetti in uno stream di bytes.
Attenzione, non gestiscono lo stadio fisico, gli impulsi elettrici, ma
"scrivono" e "leggono" i pacchetti Ethernet da/per la CPU.

* Del silicio dell'AR8237N fanno parte due 2 GMII (Gigabit Media
Independent Interface) distinte. Le GMII sono una "API elettronica" di
interconnessione tra MAC e PHY (lo strato fisico, quello che traduce i
bytes da/per il MAC in impulsi elettrici). Sono standard, che è l'intero
punto della questione, così MAC e PHY se ne possono fregare dei dettagli
l'uno dell'altro.

* Ogni PHY ha il suo MAC chip (normale), e in più (nell'AR8237N) ce ne
sono 2 di "raccolta" (GMAC0 e GMAC1)

L'associazione GMAC + MII è quella che conosciamo come "porta cpu" dello
switch. È cioè la porta non-fisica dello switch attraverso la quale la
CPU può parlare "MAC" con lo switch.
Il kernel, di regola, la chiama "eth0".

Se siete familiari con il routing a terra sapete che nei router
normalmente ci capitano due casi:

1) Tutte le porte fanno capo a "eth0". Questo significa che il GMAC0
raccoglie tutte le porte fisiche in un bridge "elettronico" che si
imposta nei registri dello switch. La porta "WAN" verrà quindi creata ad
un livello molto più alto, grazie alle VLAN (eth0.1, eth0.2).

2) Tutte le porte meno la "blu/WAN" fanno capo a "eth0". Questo
significa che il GMAC0 bridgia elettronicamente tutte le porte fisiche
*meno una*, una modalità anch'essa prevista dai registri dello switch
(un cortocircuito, banalmente).
Cosa succede alla porta "blu/WAN"? È agganciata ad una sua MII dedicata
e da essa direttamente alla CPU, da cui sarà gestita in toto. Niente
GMAC di raccolta, la CPU la vede direttamente come un'interfaccia a sè
stante, che solitamente il kernel chiama "eth1". Da notare che non può
essere una qualsiasi porta, ma *quella*, elettronicamente predisposta a
questa modalità.

Ora, se vi ricordate abbiamo detto che l'AR8237N ha due GMAC e relative
MII, ed è per questo che sui modelli che lo montano vi trovate una "port
6". Ma sopra non abbiamo mai menzionato GMAC1, perchè? Perché la TP-Link
lo lascia inutilizzato su 3500/3600/4300, non c'è collegata nessuna
delle porte fisiche.
Sul 1043NDv2 invece GMAC1 gestisce la porta "blu/WAN" su una SGMII dedicata.

Questa è una differenza sostanziale rispetto ai due casi soliti perché
stavolta ci sono *due* associazioni GMAC + MII e di conseguenza *due*
"porte cpu" dello *stesso* switch, e di conseguenza *due* interfacce
(eth0 e eth1) che però *non* sono distinte: cosa più importante,
condividono la stessa VLAN table, perché questa è propria dello switch.

== CONFIGURAZIONE ==

La ripartizione di default dello switch in OpenWrt è questa (t = tagged,
u = untagged, x = off):


   |   CPU  |
   |eth1eth0|
   ||
 ||
_||__
switch port   | p0 | p1 | p2 | p3 | p4 | p5 | p6 |
__||||||||
router port   |  - |lan4|lan3|lan2|lan1|wan |  - |
__||||||||
vlan1 |  u |  u |  u |  u |  u |  x |  x |
__||||||||
vlan2 |  x |  x |  x |  x |  x |  u |  u |
__||||||||


Questa ripartizione però assegna alle porte che partecipano nel br-lan
l'interfaccia eth1, mentre la solita eth0 viene assegnata alla WAN.
Tutto questo è rilevante perchè quando a partire da questo default si
vanno a modificare le VLAN agendo da LuCI, le interfacce corrispondenti
erroneamente (da netifd, methinks) vengono create su eth0.x, mentre a
noi servirebbero sulla eth1.x.
Se poi si creano nel passo successivo le Networks mettendo il pallino su
eth0.x, non funziona giustamente nulla.

Due possibili approcci (negli esempi, routing a terra con 1 antenna):

= Business as usual =


   |   CPU  |
   |eth1eth0|
   ||
 ||
_||__
switch port   | p0 |

Re: [Ninux-Wireless] long range link 46.5km

[Stefano De Carlo]

Heilà,

una curiosità: il link di 25km che c'è a Roma (NodoCelli - Salsedine),
dal map server si intuisce sia realizzato con due NanoBridge PtP.
Mi chiedevo: sapete che versione sono? 22 o 25 dBi?
Un'altra cosa: il map server mi dà ETX 1. È reale? Mi da
"raggiungibile", quindi presumo sia in grado di estrarre i dati in
tempo reale.
Se non lo è, me lo greppereste da una rotta?

Aneddoticamente, come vi va la vita con questo link?

Thanks!

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Fotovoltaico

[Stefano De Carlo]

Il 16/09/2014 21:26, federico la morgia ha scritto:
> Stefano è qui l'errore che hai ed avete commesso tutti non leggendo
> bene ciò che ho scritto.
> Io ho detto che fare un supernodo senza la 220v sul tetto (e non ho
> specificato come realizzarla se tramite fotovoltaico o portandola da
> casa, o più in generale tramite un'alimentazione presente sul tetto),
> quindi senza un'alimentazione accessibile direttamente sotto al nodo,
> significava darsi la zappa sui piedi perchè voleva dire portare giù a
> casa 1 cavo per ogni antenna che si voleva alimentare ! (se mettiamo
> il caso non si vogliano usare switch poe sul tetto).
>

"Assolutamente no"
"Inutile per Ninux"

Giudizi privi di contesto (aka: diktat) che nemmeno rispondo alla chiara
domanda motivatrice del thread, te la ripeto: "si può eludere il
passaggio della corrente sul tetto mediante l'adozione del fotovoltaico?"

E hai risposto pensando solo ai tetti senza corrente, che per qualche
ragione sono "assolutamente no" per i supernodi, e al diavolo i non
supernodi che sono "inutili per Ninux".
Niente di quel che hai detto contribuisce al merito della questione,
anzi, lo evita proprio, pur di farci partecipi del La Morgia Way Of
Networking.

Hai voglia i supernodi calabresi che pensavano di essersi comportati da
esseri razionali, analizzando la situazione e le alternative e
decidendo, dati alla mano, visto il contesto, di utilizzare singoli cavi.

C'è una cosa che non può trovare spazio in una WCN, e sono i toni perentori.
E si, posso assolutamente decidere i toni di una tua mail, poiché nel
corso di questi mesi hai lasciato indizi su indizi sulla tua poca
propensione a rispettare e concepire la diversità in una rete, che ci
sono tanti modi diversi di fare una rete, tanti criteri e priorità,
persone diverse.
Sai perfettamente che non è la prima volta che te lo si fa notare, e
l'elenco non si ferma a me e Nemesis.
Te lo spiegherai anche stavolta col fatto che "non ti si è interpretato
bene"?
Fai come vuoi.


> In più ho detto che fare solo nodi foglia è un problema perchè, nella
> modalità STA/AP, se il nodo foglia è generalmente una STA e gli casca
> il relativo AP, quello non sta più in rete !!!
> Ed è utile secondo voi tenere un nodo con queste criticità ? Secondo
> me no ed è quindi meglio avere sempre un'altra antenna che punti da
> un'altra parte della rete così da ridondare il nodo stesso ed evitare
> che rimanga disconnesso.

A parte che hai trasformato un discorso in potenza condivisibile al 100%
(una rete non può vivere di soli nodi foglia) in un'aberrazione (i nodi
foglia sono poco utili), applicando un criterio di utilità unilaterale e
fine a sè stesso (la rete al servizio della rete, non di chi ne fa parte).
Vorrei sapere con che faccia andresti dai nodi foglia che qui offrono
servizi, contenuti, fanno sperimentazione, a dire che sono inutili in
una WCN perché foglia.

La cosa davvero insopportabile è che il tuo è *l'ennesimo*
http://it.wikipedia.org/wiki/Argomento_dell%27uomo_di_paglia che ti si
scopre a postare

*Nessuno* sta discutendo di nodi foglia come di un fattore nella
discussione, *nessuno* a maggior ragione sta parlando di fare *solo*
nodi foglia.
A furia di distorcere gli argomenti presentati è semplice apparire
ragionevoli quando si propongono i propri, ma non lo sei.
L'unica ragione per cui stiamo parlando di nodi foglia adesso è che non
rientrano nel La Morgia Way of Networking, e al diavolo se i motivi per
cui non ci rientrano non hanno *nulla* a che fare col fotovoltaico.

> Se poi queste cose non le condividete non me ne frega nulla.
> Io esprimo _sempre_le mie idee, se non le condividete non mi importa,
> se le condividete manco mi importa!

Una ottima sintesi!
Non conta il merito, non contano le argomentazioni, non contano i dati,
non conta il contesto, non conta la possibilità che si trasformino,
impoveriscano o arricchiscano.
Conta esprimerle!
Se applichi questo principio alle *tue* idee, di che mi sorprendo della
tua sostanziale trasparenza alla diversità che c'è in questa community?

> allora ditelo

Impara a esprimere le tue idee in modi retoricamente onesti e che diano
anche solo l'illusione (se non te ne frega della sostanza) che tu abbia
presente che le reti mesh possano avere modi, tecniche, contesti,
priorità e criteri differenti ma ugualmente dignitosi.
Detto.

>  Però ricordati che rimane sempre l'incognita : e mo come faccio la
> messa a terra se il palazzo non ne è provvisto sul tetto in nessun modo ?

Come dibattuto in una interessante discussione il mese scorso in lista
http://ml.ninux.org/pipermail/wireless/2014-August/015854.html
La messa a terra del tetto non è un assolutismo, e può essere
indesiderata e indesiderabile.
Altri approcci sono possibili.

>
> P.S. : Vediamo se da casa la webmail di hotmail funziona a dovere.
>

In-Reply-To: <54186355.6050...@gmail.com>
References: ,
<54186355.6050...@gmail.com>

Funziona, disabilita l'html, k9 + imap su android e sei perfetto.

Stefanauss.



signatur

Re: [Ninux-Wireless] Bug Watch: NanoBeam/XW vs Legacy/XM, flapping TX/RX rate

[Stefano De Carlo]

Il 16/09/2014 19:09, leonaard ha scritto:
> Premetto che non ho letto con attenzione tutta la mail, a me tempo fa
> un link con la nanobeam flappava perche` avevo "Output Power" al
> default che e` tipo 8dBm e per poterlo aumentare ho dovuto settare
> "Antenna" a "Feed only".
>

Altra prova fatta e sepolata :)

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] Bug Watch: NanoBeam/XW vs Legacy/XM, flapping TX/RX rate

[Stefano De Carlo]

(scusate la lunga mail ma è impossibile sintetizzare qui)

Ciao a tutti,

qualche tempo fa Luca di IuliiNet aveva postato questo:

http://ml.ninux.org/pipermail/wireless/2014-June/014869.html
http://ml.ninux.org/pipermail/wireless/2014-July/014932.html (reprise
mese dopo)

TL;DR: LoS quasi perfetta, breve distanza, segnale -60dB, Airmax Q/C
buone, nessuna interferenza, e nonostante questo link inutilizzabile.
Il sintomo è l'estrema asimmetria dei valori di TX/RX rate di 802.11.
Tipo 6.5/130.
Luca risolse rapidamente rifacendo il link a 2.4 invece che a 5
(Nanostation M2).

Da qualche settimana a Cosenza, sul supernodo di Musk
http://map.ninux.org/select/msktrzhome/
stiamo sperimentando lo stesso problema.
Due NanoBeam M5 300 XW deployate, verso rispettivamente
NewSpig (AP: RM5 serie XM, Sector 90): http://map.ninux.org/select/newspig/
Lappanux Sud (AP: NSM5 serie XM): http://map.ninux.org/select/lappanux/

Mentre la NB vs NewSpig si comporta benissimo, valori ottimi e iperf
stabile 30 Mbit/s,
la NB verso Lappanux, nonostante i valori di segnale (-72) e CCQ (96)
buoni, e la LoS, ha un link incredibilmente instabile. Iperf oscillante
tra 2 e 24 Mbit/s.
Gli Air Rate a ponte scarico, sono alti, 162/108 e simili. Non appena si
comincia a fare del traffico, questi scendono a 6.5/6.5 e da lì flappano
paurosamente, tornando periodicamente a 6.5. Il link va talmente male a
volte che OLSR devia tutto il traffico verso un percorso che prevede hop
supplementari!

Mi sono ricordato del problema di Luca, e googlando è saltato fuori che
è una know issue fin dal lancio della NanoBeam

http://community.ubnt.com/t5/Installation-Troubleshooting/TX-RX-Rate-6-5-Mbps-6-5-Mbps-problem-in-nanobeam-m5/td-p/715087/page/15

Questo è il thread più lungo. A decine di altri sparsi, e un altro
altrettanto lungo nella sezione beta.
Il succo è che anche nel deserto, con una LoS perfetta, con segnali da
-50 e CCQ/Airmax 100%, distanze brevi, si può essere afflitti da questo
problema. Nessun parametro del link wireless riesce a risolvere.

Le condizioni dei "bug report" (informali quanto si vogliono, ma c'è
gente che ha comprato partite di hw nelle centinaia ed è molto incazzata
per questo bug, quindi la ubnt li tratta come ticket) sono variabili, e
il problema non si verifica con tutte le Beam, ma una costante è che è
presente più spesso quando si mischiano apparati della revisione XW con
i vecchi XM.

La stessa Ubnt ha riconosciuto questo problema di compatibilità tra
serie, come chiariscono i changelog delle versioni beta. Finora non ha
funzionato una ceppa.

Molti hanno fatto la madre di tutti i test: sostituito la NanoBeam XW
problematica con una NanoBridge XM identicamente configurata e puntata:
e improvvisamente throughput stabili e perfetti.
Ebbene, dopo qualche settimana di ogni prova possibile l'abbiamo fatto
anche noi: via la Beam, dentro una Nanostation M5 XM. Risultato? 40
Mbit/s istantanei e stabili (a -80!).

Le cose che avevamo provato nel mentre
* varie frequenze (no effetto)
* varie bandwidth (no effetto)
* ACK aka Distance manuale (no effetto)
* Air Rate fissi (bassissimi miglioramenti a patto di beccare quello giusto)
* Data Rate Module alternativo (no effetto)
* varie potenze di uscita
* Ripuntata 10mila volte.
* Tutti i 5.5.10 beta della Ubnt che "risolvono"

il link rimaneva flappante.

Non è un problema hw:
* la stessa Beam puntata verso l'altro nodo si comporta correttamente.
* Persino quando puntata sempre su Lappanux ma sull'AP che punta nella
direzione opposta (che è proprio all'angolo dell'illuminazione dei
90°...), la Beam si comporta stabilmente e con buoni throughput.

Abbiamo poi un'altro hw della serie XW (una AirGrid M5), puntata verso
la NSM5 di LappanuxSud, che ha lo stesso tipo di flapping.
Anche qua nessun parametro operativo riesce a ridurre il problema.
Se sarà possibile cercheremo di fare la stessa sostituzione di test
anche da qui, per confermare di nuovo che la compatibilità XM/XW è la
responsabile qui.

Da notare che anche NewSpig è una RM5 XM, ma proprio come ci si
aspetterebbe leggendo i thread di supporto, in questo caso le
connessioni XM/XW vanno da Dea. Abbiamo 6 NanoBeam M5 300 XW in modalità
STA associate a NewSpig e funzionano tutte quante perfettamente.
Con le NanoStation M5 XM (sperimentato), NanoBridge XM (thread), AirGrid
XM (thread), ci possono essere questi problemi quando un device della
serie XW si linka. Forse altri device.
Le Rocket sembrano quasi sempre immuni.

Fine report.

Ora le domande: avete mai notato il problema nelle altre isole?
Chiaramente sto parlando di chi utilizza AirOS sulle radio, ed ha un
device della serie XW. NanoStation, NanoBeam, AirGrid, etc che sia. AP o
STA che sia.

Luca, ti ricordi se le NanoStation M5 che ti davano questo problema
erano delle nuova serie XW?

È da un po' che ci sbattiamo la testa a Cosenza, penso che ci farebbe
bene qualche input. In modo soprattutto da poter valutare meglio i
prossimi ordini.

Stefanauss.



signature.asc
Descriptio

Re: [Ninux-Wireless] Fotovoltaico

[Stefano De Carlo]

Il 16/09/2014 16:54, federico la morgia ha scritto:
> Significa avere la possibilità di espandere la rete.
>  Se tutti possono fare solo da nodo foglia, cioè possono connettersi solo ad 
> un altro nodo, la wcn sostanzialmente o non si crea o non si espande.

Con risposte del genere rendi chiaro che non stai neanche partecipando
al dibattito, ma cogli ogni occasione per reiterare le tue convinzioni
su come debba essere fatta la rete.
Non è la prima volta.

Hai letteralmente dato per scontato che non si possano fare supernodi
fotovoltaici, quando è assolutamente evidente che si possono fare ma che
farli comporta x problema o y svantaggio.
E qui si vuole parlare di come risolvere questi problemi.

Se qualcuno per qualsiasi ragione reputa utile un nodo fotovoltaico
nella WCN di cui fa parte, quel nodo fotovoltaico è utile alla WCN.
La WCN è le persone che la fanno.
Ninux non è un totem da servire e riverire.
"Utile alla WCN" non ha un valore.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Quotar bene. WAS:Re: Fotovoltaico

[Stefano De Carlo]

Il 16/09/2014 16:52, federico la morgia ha scritto:
> È un problema di client di posta sul mio android e non mio.
> Conviene che apri un ticket su Microsoft.


Il dato di fatto, Federico, è che in una lista molto trafficata il tuo è
l'unico client che elimina gli ID nei campi References, e Reply-To.
Di conseguenza costringendo ogni client compliant a creare un nuovo thread.
Oltre alle modalità di quoting.

Ci sono dei client Android che non soffrono di questo problema.
La Microsoft non partecipa a questa community, tu si.
Il problema ti è stato illustrato, la volontà e il potere di farci
qualcosa ce l'hai te.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Fotovoltaico

[Stefano De Carlo]

Il 16/09/2014 13:44, federico la morgia ha scritto:
> Su una modalità supernodo assolutamente no.
> Per un nodo foglia ok, ma è poco utile per una wcn.

Ciao Federico,
mi descrivi cosa reputi "utile per una WCN"?

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nanobeam e openwrt

[Stefano De Carlo]

Il 14/09/2014 20:46, Andrea Milocco ha scritto:
> Il 14/09/2014 17:17, leonaard ha scritto:
>>> attenzione pero che (a quanto so) per la nanobeam non c'e` ancora una
>>> versione usabile di openwrt
>>>
>> Corretto.
>> L'unico device della serie XW ad avere il supporto ad OpenWrt è la
>> NanoStation M{2,5}.
>>
>> Stefanauss.
>>
>
> Ciao a tutti, 
> Mi potreste spiegare in cosa consiste il supporto mancante ad openwrt? 

Non sono sicuro di aver capito la domanda.
Il mancato supporto significa semplicemente che non puoi installare
OpenWrt sulle nuove serie Ubiquiti. Di conseguenza sei vincolato ad
AirOS e per utilizzare queste nuove serie Ubiquiti su Ninux devi
necessariamente usare la configurazione con routing a terra.

Se intendi "cosa manca per raggiungere il supporto", è qualcosa a
proposito del layout della memoria flash interna e del formato del
binario. Il processore e lo switch sono ampiamente supportati da tempo.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] dubbio su nanostation m5

[Stefano De Carlo]

Il 14/09/2014 17:17, leonaard ha scritto:
> attenzione pero che (a quanto so) per la nanobeam non c'e` ancora una
> versione usabile di openwrt
>

Corretto.
L'unico device della serie XW ad avere il supporto ad OpenWrt è la
NanoStation M{2,5}.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Canali a 5Ghz

[Stefano De Carlo]

Il 14/09/2014 14:07, Matteo ha scritto:
> Ci sono delle frequenze prestabilite per l'Italia a 5Ghz ... ce
> qualche link ufficiale?

Cerca "Codice delle Comunicazioni Elettroniche", è la normativa di
riferimento.
Qui trovi una sintesi: http://www.comunicazioniliguria.it/wifi.html


> Devo impostare Channel Shifting Enable

Channel shifting è una funzionalità proprietaria della Ubiquiti che ha
come obbiettivo quello di ridurre le interferenze. Non è una
funzionalità regolatoria.

In breve: la "frequenza" che utilizzi è in realtà composta da una
frequenza centrale (da scegliere tra quelle messe a disposizione dallo
standard 802.11) e una larghezza di banda (da standard, 20 e 40 Mhz, ma
con Ubiquiti sono possibili anche valori suppementari).
Nella realtà dei fatti tu trasmetti in un intervallo di  MHz, centrato nel canale che hai scelto.

Channel Shifting permette di "traslare" il canale centrale, e di
conseguenza tutte le frequenze che utilizzi, di qualche Megahertz al
fine di ridurre la sovrapposizione con i dispositivi privi di Channel
Shifting.


> perchè qualche legge lo obbliga? o posso impostare un canale fisso?

Puoi impostare un canale fisso.
L'unico obbligo di legge è costituito dal DFS, che deve essere attivo
per le frequenze per le quali è previsto dalla legge, se decidi di
utilizzarle.
Se imposti country code "Italy" Ubiquiti si prende cura di questi
particolari per te, ha il regulatory implementato in software e
costantemente aggiornato.
Cerca "Dynamic Frequency Selection" per approfondire.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] dubbio su nanostation m5

[Stefano De Carlo]

Il 12/09/2014 19:53, Michele Salerno ha scritto:
>
> Ho visto quello che fanno altri e non mancherò a mettere le foto,
> faccio da solo e vi metterò un selfie vicino le antenne!  :)
>
> Nella vita non bisogna mai pretendere ma chiedere.
> Avrei bisogno che qualcuno mi dia una mano nelle configurazioni.  Sia
> della Nanostation che di openwrt sul tplink.
> Suk tetto avrò la m5, più la omnidirezionale 15dbi a 2.4 ghz della
> tplink con il router tplink.
> Ho intenzione di aggiungere altre m5 ! Formare un quadrifoglio per
> avere un raggio più aperto.
>

Mi pare di aver capito che configurerai a terra.
Nel qual caso, nell'howto c'è veramente tutto quello che devi sapere
relativamente al tipo di config che vuoi operare: http://nnx.me/grhowto

> Sulla m5, che non conosco,  la seconda eth a che serve?
>

È una seconda interfaccia Ethernet a disposizione, che permette
all'antenna stessa di fare da router o da switch, a seconda di come
viene configurata.
Solitamente nelle installazioni rimane inutilizzata, il collegamento
all'antenna e/o la moltiplicazione delle porte disponibili avverà in
qualche switch o router a valle.

> Se non si vuole intasare la ML
>

La ML serve a questo :)
Il miglior contributo che puoi dare a "non intasarla" e leggere
preliminarmente tutta la documentazione Ninux disponibile, in modo da
non dover ripartire da zero ed evitare duplicazioni di sforzi da parte
di tutti.

Happy Ninux!

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] dubbio su nanostation m5

[Stefano De Carlo]

Il 10/09/2014 23:46, Michele Salerno ha scritto:
>
> su uno porta ladescrizione LOCO e sull'altro no.
> Dubbiosono lo stesso prodotto???

No.
La Loco M5 è una versione ridotta, in guadagno dell'antenna, rispetto
alla M5.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Banner per la net neutrality

[Stefano De Carlo]

Il 10/09/2014 11:09, Nemesis ha scritto:
>
> Volevo parlare con voi di questa cosa.
>
> Sebbene apprezzi molto l'iniziativa, volevo farvi una domanda.
>
> Non credete che sia un pò una protesta all'acqua di rose? Che tipo di
> benefici può avere una protesta del genere?
>
> []
>
> Quindi trovo molto più efficace lavorare nella direzione di costruire
> questa alternativa piuttosto che protestare o fare lobbying, che tanto
> poi sinceramente mandòcazzo volemo annà che quelli c'hanno molti più
> sordi de noi se comprano i politici a suon de case comprate "a loro
> insaputa".
>
> Nemesis

Costruire l'alternativa indipendente è il nostro default, non servono
ulteriori motivazioni. Lo scenario che prospetti non è impossibile.

Sul merito del quote sopra, può sembrare e anche essere all'acqua di
rose questa iniziativa.
Ma la protesta contro ACTA nacque con ste stupidaggini e poi portò
persone in piazza a livello globale, che fu una cosa senza precedenti
per una questione prevalentemente tecnologica e di un argomento
concepito come "astruso" come la proprietà intellettuale.

E fu un successo:
http://en.wikipedia.org/wiki/Anti-Counterfeiting_Trade_Agreement

Insomma, non c'è da essere cinici nei confronti di queste iniziative,
che non vanno concepite con "mo' ti fermo la Net Partiality" ma "mo' ti
faccio n'attimino fermare a pensare alla Net Neutrality".

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Subnet per Matera [era: help me! :)]

[Stefano De Carlo]

Il 09/09/2014 23:58, Michele Salerno ha scritto:
> Ops mi sono perso!
>
> Ricapitolando, le prenotazioni sarebbero
> * Backbone Basilicata: 172.23.0.0/16 
> * Backbone Matera: 172.23.0.0/24 
> * LAN space HNA Basilicata: 10.23.0.0/16 
>
> Ho cercato di raffigurare nell'immagine la mia situazione attuale.
> Dando in pfsense libero accesso...non mi va su internet!

Non ho ben capito che intendi o quale sia la "situazione attuale", ma ti
posso assicurare che lo schema di cui sopra è una mera organizzazione
dell'indirizzamento delle mesh Ninux che utilizzano OLSR.
Poi quando vai a implementare la rete puoi fare qualsiasi cosa
tecnicamente, tutto è demandato alla configurazione.
Approfondendo ti si chiarirà tutto, come tu stesso intuisci :)

>
> Più che altro chiederei maggiori delucidazioni su OLSRD in quanto non
> l'ho mai usato!

Per una carrellata rapida delle basi, ti consiglio questo video:
https://www.youtube.com/watch?v=g58VB7obXVU
Questo va più nel dettaglio: https://www.youtube.com/watch?v=dDAKBjqyBxc

Poi chiaramente, Google + lista-wireless siamo tuoi amico

>
> PS: di openwrt è necessario mettere qualche firmware particolare? Io
> ho messo quello che ho trovato compatibile per il mio tp-link e ci ho
> aggiunto luci :)

Ci sono dei "firmware Ninux" che sono appunto ottimizzati per la nostra
rete, tra config e pacchetti già inclusi. Cerca Scooreggione e NinucsWrt
sul wiki per maggiori info (Libre-Mesh se invece deciderai di utilizzare
Batman).
Ma non sono assolutamente obbligatori. Qualsiasi firmware o OS che
permetta di far girare un'implementazione di OLSR (in generale, del
protocollo di routing dinamico scelto) è utilizzabile.
OpenWrt liscio +  pacchetti a mano va benissimo.

> Ho provato ad installare il pacchetto openwrt ma non me lo fa mettere
> per mancanza di spazio nella rom.
> Ma credo che sia meglio poterlo gestire da pfsense.
>

Chiaramente le funzioni e il pedigree di pfSense non si discutono, ma
per esperienza diretta ti assicuro che OLSR è cittadino di seconda
classe su BSD in generale e pfSense in particolare.
Funziona eh, ma con rogne annesse.

OpenWrt + Luci + OLSR ci stanno senza patemi in 4 MiB di ROM, che il tuo
841 ha.
Se hai installato pacchetti per provare, e poi li hai rimossi, OpenWrt
non gestisce sempre bene questa situazione lasciando dietro della sporcizia.
Se puoi reinstallare tutto da OpenWrt liscio vedrai che ci stanno
tranquillamente.


> Idea personale del mio nodo a completamento:
> Antenna 2.4 con hotspot free (senza password) (1.70 mt di antenna).
> Sono al 7° piano e in una zona abbastanza alta (quasi a livello delle
> antenne dei CC).
> PfSense dedicato + Server Web con x servizi disponibili per la comunità
> Antenne 5Ghz n, 5 nanostation m5 da mettere a quadrifoglio anche se 5
> (amazon da il pacchetto di 5 a 300 euro).
>
> Cosa ne pensate?
>

È un setup con pochi pari per un supernodo con cui bootstrappare la rete. ;)

Happy Ninux,
Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Subnet per Matera [era: help me! :)]

[Stefano De Carlo]

Il 08/09/2014 14:16, nemesis ha scritto:
>
>> Immagino che sia una regola per il collegamento tra i nodi e non per
>> l'antennina da 2.4, giusto?
>
> E' bene che chi si collega alle antennine a 2.4 GHz possa raggiungere
> il resto della rete comunitaria, fai attenzione solo a questo.
>

Si, il principio è questo.
IMHO il modo più semplice, e che utilizziamo negli hotspot a Cosenza
(OLSR-powered), è dedicare una subnet LAN/HNA apposita all'hotspot.
Semplice, più facile da configurare ad ogni livello (routing,
firewalling, captive portal)

Questa subnet LAN/HNA apposita può essere
* estratta da quella già assegnata al tuo nodo: da una /24 ti tieni una
/25 per te, e una /25 per i client che si associano all'hotspot.
* una /24 supplementare da aggiungere al tuo nodo e dedicare all'hotspot.

Chi si collega all'hotspot è direttamente in Ninux, annunciato da te
usando gli HNA di OLSR.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Subnet per Matera [era: help me! :)]

[Stefano De Carlo]

Il 08/09/2014 14:16, nemesis ha scritto:
>
>
>> Per quanto riguarda la scelta degli IP/CAP si fa riferimento ai nodi
>> a 5 GHz o per la rete di distribuzione (2.4)?
>> Il mio cap è 75100.
>
> Meglio discutere di un assegnazione di una piccola subnet per matera,
> poi una volta che abbiamo assegnato una subnet puoi gestire gli
> indirizzi come meglio credi, col CAP col CUP o con il CUL.
>
> @TUTTI: assegnamo una subnet per matera?
>

Ciao Michele,

la cosa più importante da sapere è con quale protocollo di routing vuoi
bootstrappare la tua mesh ninux a Matera.
La maggior parte delle isole Ninux italiane utilizza OLSR (Layer 3),
alcune utilizzano BATMAN (Layer 2).
A seconda di quale scegli, cambia la suddivisione necessaria.

Se vuoi andare con la corrente maggiore, OLSR, serve prenotare due
sottoreti per Matera:
* Una sottorete "Backbone", per i link radio tra nodi
* Una sottorete "LAN", dal quale estrarre le sottoreti più piccole da
assegnare ai singoli nodi, che potranno poi annunciarle a loro
discrezione attraverso il meccanismo HNA di OLSR.

La procedura consolidata, e la best practice OLSR, credo sia questa:

* Già che ci siamo, riserviamo tutta la subnet Backbone per la
Basilicata: 172.23.0.0/16 è libera, future-proof.
* Da questa, per la Backbone a Matera, comincia riservando una /24:
172.23.0/24 va bene, e poi le altre città continueranno progressivamente.
* Per tutto lo spazio LAN, 10.23.0.0/16 è libera. Ogni nodo estrarrà una
/24 da questa, 254 nodi per cominciare bastano e avanzano.

Ricapitolando, le prenotazioni sarebbero
* Backbone Basilicata: 172.23.0.0/16
* Backbone Matera: 172.23.0.0/24
* LAN space HNA Basilicata: 10.23.0.0/16

Se ti torna puoi già aggiungere sul wiki/phpipadm, abbiamo fatto così
per molte isole, non c'è granché da dibattere, ma è importante che tu
capisca come funziona :)


Quanto sopra vale a prescindere da 2.4/5 GHz, e si può adattare sia che
vuoi fare dorsale radio (link PtP o PtMP tra nodi) sia che vuoi fare
distribuzione ai client finali (portatili, routerini, pc, cellulari, ecc).

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Richiesta manuale router a terra

[Stefano De Carlo]

Il 07/09/2014 14:29, digitalbyte ha scritto:
> Qualcuno con le nozioni giuste  può ampiare la guida router a terra
> con la parte wireless per usare il tplink come router a terra + access
> point.
>
> grazie
>

Ciao,

La guida al routing a terra andrebbe mantenuta focalizzata sui concetti
relativi al routing a terra (difatti, non include neppure la
configurazione del link radio).

Per il resto chiaramente hai fatto bene ad invitare chi sa a produrre
documentazione, ma è anche vero che potresti essere tu a raccogliere le
informazioni necessarie e ottenere due piccioni con una fava (config + 
documentazione). ^^

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] microtik, 2 antenne e routing a terra

[Stefano De Carlo]

Il 04/09/2014 14:20, marco impallaria ha scritto:
> Salve
>

Ehilà :)

> Volevo chiedere se l'idea che ho in mente è "campata per aria" o è
> fattibile.

Fattibilissima, di sicuro a Roma c'è più di un deployment di
configurazioni simili, attive e funzionanti.

> Sostanzialmente l'idea è la seguente:
> Alcuni apparecchi della microtik[1] consentono di montare una scheda
> miniPCI-e.
> Se tale scheda fosse un'altra scheda wireless[2] (anche se con meno
> potenza), si potrebbe avere un supernodo senza comprare due apparati,
> ma solo con due antenne?

Devi comunque avere tante antenne quanti chipset wireless (miniPCI/-e)
hai a disposizione, quindi non so se si può considerare "senza comprare
più apparati" con tutta questa moltitudine di miniPCI e antenne, però
si, è roba supernodabile.


> E questo, come si comporterebbe con il routing a terra, in particolare
> con le vlan?

Non ne avresti bisogno, la routerboard potrebbe essere già lei il ground
router e le vlan sarebbero superflue in quanto non hai bisogno del
bridge sull'antenna: l'antenna infatti è un'interfaccia propria,
discreta, della routerboard, da dare in pasto a OLSR.
Il problema è che RouterOS (AFAIK) non permette di farci girare
OLSR/BATMAN sopra, e pertanto dovresti sceglierne una compatibile con
OpenWRT. Però poi comincia il problema di scegliere le miniPCI
compatibili con OpenWRT.

Altrimenti si può sempre configurare in ground routing verso un router
OpenWRT, semplicemente creando le vlan e i bridge appositi su RouterOS.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless