Re: [Ninux-Wireless] traffico bloccato da un'antenna dopo eventi strani

2017-02-20 Per discussione Matteo Pedani 
Si mi sembra che il collegamento radio  non funzioni. Magari qualcuno sta
usando lo stesso canale, oppure qualcuno usa le stesse frequenze che usi tu
ma magari neanche tcp-ip  prova a fare air-vgiew con l'antenna

Matteo

2017-02-20 13:50 GMT+01:00 Claudio :

> casualmente mi accorgo che da un nodo configurato in modo groundrouter da
> un'antenna il traffico olsr risulta bloccato sia uscita e entrata .
>
> facendo il restart di olsr da entrambi i router non cambiava assolutamente
> niente
>
> ho risolto solo riavviando l'antenna (litebeam M5AC) access point
>
> qualcuno mi sa spiegare il motivo??
>
> ricercando un pò su google sembrerebbe qualcosa tipo: Attacco DDOS o
> cosa??? ma in porte diverse...
>
> i log. del router
>
>
> Neighbour IP Hostname Interface Local interface IP LQ NLQ ETX SNR
> 172.31.90.31 ? antenna1 172.31.90.54 1.000 1.000 1.000 ?
> 172.31.90.48 ? antenna3 172.31.90.56 0.195 1.000 5.100 ?
> 172.31.90.47 ? antenna2 172.31.90.55 0.000 1.000 0.000 ?
>
>
>
>
> Sun Feb 19 14:25:41 2017 kern.debug kernel: [85121.37] UDP: bad
> checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
> Sun Feb 19 16:09:44 2017 kern.debug kernel: [91364.28] UDP: short
> packet: From 172.31.90.47:698 624/592 to 172.31.255.255:698
> Sun Feb 19 16:30:29 2017 kern.debug kernel: [92610.13] UDP: short
> packet: From 172.31.90.47:698 158/156 to 172.31.255.255:698
> Sun Feb 19 17:27:24 2017 kern.debug kernel: [96024.77] UDP: short
> packet: From 172.31.90.47:17082 1376/352 to 172.31.255.255:698
> Sun Feb 19 18:01:31 2017 kern.debug kernel: [98071.40] UDP: bad
> checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
> Sun Feb 19 18:11:54 2017 kern.debug kernel: [98695.11] UDP: bad
> checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
> Sun Feb 19 18:21:19 2017 kern.debug kernel: [99259.26] UDP: short
> packet: From 172.31.90.47:698 260/256 to 172.31.255.255:698
> Sun Feb 19 21:05:57 2017 kern.debug kernel: [109137.97] UDP: short
> packet: From 172.31.90.47:698 170/168 to 172.31.255.255:698
> Sun Feb 19 22:11:38 2017 kern.debug kernel: [113078.63] UDP: bad
> checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
> Mon Feb 20 00:14:57 2017 kern.debug kernel: [120478.05 <050%2>]
> UDP: bad checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 36
> Mon Feb 20 04:29:10 2017 kern.debug kernel: [135730.52] UDP: short
> packet: From 172.31.90.47:698 4292/196 to 172.31.255.255:698
> Mon Feb 20 04:43:53 2017 kern.debug kernel: [136613.51] UDP: bad
> checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
> Mon Feb 20 05:30:10 2017 kern.debug kernel: [139390.93] UDP: bad
> checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 76
> Mon Feb 20 08:04:44 2017 kern.debug kernel: [148664.22] UDP: bad
> checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
> Mon Feb 20 08:10:09 2017 kern.debug kernel: [148989.19] UDP: short
> packet: From 172.31.90.47:698 33124/356 to 172.31.255.255:698
> Mon Feb 20 10:14:49 2017 kern.debug kernel: [156469.96] UDP: bad
> checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
> Mon Feb 20 11:49:27 2017 kern.debug kernel: [162147.47] UDP: bad
> checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
> Mon Feb 20 12:00:06 2017 kern.debug kernel: [162786.32] UDP: short
> packet: From 172.31.90.47:698 2396/348 to 172.31.255.255:698
> Mon Feb 20 12:09:08 2017 kern.debug kernel: [163328.33] UDP: short
> packet: From 172.31.90.47:698 440/312 to 172.31.255.255:1722
> Mon Feb 20 12:18:34 2017 kern.debug kernel: [163894.17] UDP: bad
> checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
> Mon Feb 20 12:26:42 2017 kern.debug kernel: [164382.85] UDP: short
> packet: From 172.31.90.47:698 4324/228 to 172.31.255.255:698
> Mon Feb 20 12:41:00 2017 kern.debug kernel: [165240.52] UDP: short
> packet: From 172.31.90.47:698 408/400 to 172.31.255.255:698
> Mon Feb 20 12:46:30 2017 kern.debug kernel: [165570.49] UDP: short
> packet: From 172.31.90.47:954 1360/336 to 172.31.255.255:1722
>
>
>
> ___
> Wireless mailing list
> Wireless@ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/wireless
>
>


-- 
*Matteo Pedani*

www.pedani.it
mobile +39  3343637690
phone +39 0699341466
phone +39 069415152
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] traffico bloccato da un'antenna dopo eventi strani

2017-02-20 Per discussione federico la morgia 
Sembra che banalmente 172.31.90.47

ti abbia inviato robaccia tra pacchetti errati e/o troppo corti, vedi cosa 
arrivava da quell'ip ed saprai cosa può essere.


Federico.



Da: wireless-boun...@ml.ninux.org  per conto di 
Claudio 
Inviato: lunedì 20 febbraio 2017 13.50.03
A: wireless@ml.ninux.org
Oggetto: [Ninux-Wireless] traffico bloccato da un'antenna dopo eventi strani

casualmente mi accorgo che da un nodo configurato in modo groundrouter da 
un'antenna il traffico olsr risulta bloccato sia uscita e entrata .

facendo il restart di olsr da entrambi i router non cambiava assolutamente 
niente

ho risolto solo riavviando l'antenna (litebeam M5AC) access point

qualcuno mi sa spiegare il motivo??

ricercando un pò su google sembrerebbe qualcosa tipo: Attacco DDOS o cosa??? ma 
in porte diverse...

i log. del router


Neighbour IP Hostname Interface Local interface IP LQ NLQ ETX SNR
172.31.90.31 ? antenna1 172.31.90.54 
1.000 1.000 1.000 ?
172.31.90.48 ? antenna3 172.31.90.56 
0.195 1.000 5.100 ?
172.31.90.47 ? antenna2 172.31.90.55 
0.000 1.000 0.000 ?




Sun Feb 19 14:25:41 2017 kern.debug kernel: [85121.37] UDP: bad
checksum. From 172.31.90.47:698 to 
172.31.255.255:698 ulen 60
Sun Feb 19 16:09:44 2017 kern.debug kernel: [91364.28] UDP: short packet: 
From 172.31.90.47:698 624/592 to 
172.31.255.255:698
Sun Feb 19 16:30:29 2017 kern.debug kernel: [92610.13] UDP: short packet: 
From 172.31.90.47:698 158/156 to 
172.31.255.255:698
Sun Feb 19 17:27:24 2017 kern.debug kernel: [96024.77] UDP: short packet: 
From 172.31.90.47:17082 1376/352 to 
172.31.255.255:698
Sun Feb 19 18:01:31 2017 kern.debug kernel: [98071.40] UDP: bad checksum. 
From 172.31.90.47:698 to 
172.31.255.255:698 ulen 60
Sun Feb 19 18:11:54 2017 kern.debug kernel: [98695.11] UDP: bad checksum. 
From 172.31.90.47:698 to 
172.31.255.255:698 ulen 60
Sun Feb 19 18:21:19 2017 kern.debug kernel: [99259.26] UDP: short packet: 
From 172.31.90.47:698 260/256 to 
172.31.255.255:698
Sun Feb 19 21:05:57 2017 kern.debug kernel: [109137.97] UDP: short packet: 
From 172.31.90.47:698 170/168 to 
172.31.255.255:698
Sun Feb 19 22:11:38 2017 kern.debug kernel: [113078.63] UDP: bad checksum. 
From 172.31.90.47:698 to 
172.31.255.255:698 ulen 60
Mon Feb 20 00:14:57 2017 kern.debug kernel: [120478.05] UDP: bad checksum. 
From 172.31.90.47:698 to 
172.31.255.255:698 ulen 36
Mon Feb 20 04:29:10 2017 kern.debug kernel: [135730.52] UDP: short packet: 
From 172.31.90.47:698 4292/196 to 
172.31.255.255:698
Mon Feb 20 04:43:53 2017 kern.debug kernel: [136613.51] UDP: bad checksum. 
From 172.31.90.47:698 to 
172.31.255.255:698 ulen 60
Mon Feb 20 05:30:10 2017 kern.debug kernel: [139390.93] UDP: bad checksum. 
From 172.31.90.47:698 to 
172.31.255.255:698 ulen 76
Mon Feb 20 08:04:44 2017 kern.debug kernel: [148664.22] UDP: bad checksum. 
From 172.31.90.47:698 to 
172.31.255.255:698 ulen 60
Mon Feb 20 08:10:09 2017 kern.debug kernel: [148989.19] UDP: short packet: 
From 172.31.90.47:698 33124/356 to 
172.31.255.255:698
Mon Feb 20 10:14:49 2017 kern.debug kernel: [156469.96] UDP: bad checksum. 
From 172.31.90.47:698 to 
172.31.255.255:698 ulen 60
Mon Feb 20 11:49:27 2017 kern.debug kernel: [162147.47] UDP: bad checksum. 
From 172.31.90.47:698 to 
172.31.255.255:698 ulen 60
Mon Feb 20 12:00:06 2017 kern.debug kernel: [162786.32] UDP: short packet: 
From 172.31.90.47:698 2396/348 to 
172.31.255.255:698
Mon Feb 20 12:09:08 2017 kern.debug kernel: [163328.33] UDP: short packet: 
From 172.31.90.47:698 440/312 to 
172.31.255.255:1722
Mon Feb 20 12:18:34 2017 kern.debug kernel: [163894.17] UDP: bad checksum. 
From 172.31.90.47:698 to 
172.31.255.255:698 ulen 60
Mon Feb 20 12:26:42 2017 kern.debug

Re: [Ninux-Wireless] [gaia] Thailand Community Networks

2017-02-20 Per discussione willi uebelherr 

On 19/02/2017 18:33, Arjuna Sathiaseelan wrote:

All - I wrote a blog piece on the Thailand Community Network
initiative by Asian Institute of Tech which would be of interest:
https://blog.apnic.net/2017/02/17/taknet-community-networking-thailand/


Dear Arjuna,

this text is not a perspective for Community Networks. It is a way to 
hold the old capitalistic occupation from Europe in Asia.


Clear, you work for that, you have a job for that, you get your money 
from that. But i think, the most people on our planet have not this 
problem and are able to think independent.


The perspective for the Community Networks are the local technical 
infrastructures based on our global network for free technology.


This is the background for our regional interconnection as a base for 
our community interconnection. And this is, like the streets and roads, 
a public task from our societies. Then, we don't need money for that, 
because we don't need private companies, and we don't need state 
institutions. The people organise it self.


many greetings, willi
Asuncion, Paraguay

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

[Ninux-Wireless] traffico bloccato da un'antenna dopo eventi strani

2017-02-20 Per discussione Claudio 
casualmente mi accorgo che da un nodo configurato in modo groundrouter da
un'antenna il traffico olsr risulta bloccato sia uscita e entrata .

facendo il restart di olsr da entrambi i router non cambiava assolutamente
niente

ho risolto solo riavviando l'antenna (litebeam M5AC) access point

qualcuno mi sa spiegare il motivo??

ricercando un pò su google sembrerebbe qualcosa tipo: Attacco DDOS o
cosa??? ma in porte diverse...

i log. del router


Neighbour IP Hostname Interface Local interface IP LQ NLQ ETX SNR
172.31.90.31 ? antenna1 172.31.90.54 1.000 1.000 1.000 ?
172.31.90.48 ? antenna3 172.31.90.56 0.195 1.000 5.100 ?
172.31.90.47 ? antenna2 172.31.90.55 0.000 1.000 0.000 ?




Sun Feb 19 14:25:41 2017 kern.debug kernel: [85121.37] UDP: bad
checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
Sun Feb 19 16:09:44 2017 kern.debug kernel: [91364.28] UDP: short
packet: From 172.31.90.47:698 624/592 to 172.31.255.255:698
Sun Feb 19 16:30:29 2017 kern.debug kernel: [92610.13] UDP: short
packet: From 172.31.90.47:698 158/156 to 172.31.255.255:698
Sun Feb 19 17:27:24 2017 kern.debug kernel: [96024.77] UDP: short
packet: From 172.31.90.47:17082 1376/352 to 172.31.255.255:698
Sun Feb 19 18:01:31 2017 kern.debug kernel: [98071.40] UDP: bad
checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
Sun Feb 19 18:11:54 2017 kern.debug kernel: [98695.11] UDP: bad
checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
Sun Feb 19 18:21:19 2017 kern.debug kernel: [99259.26] UDP: short
packet: From 172.31.90.47:698 260/256 to 172.31.255.255:698
Sun Feb 19 21:05:57 2017 kern.debug kernel: [109137.97] UDP: short
packet: From 172.31.90.47:698 170/168 to 172.31.255.255:698
Sun Feb 19 22:11:38 2017 kern.debug kernel: [113078.63] UDP: bad
checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
Mon Feb 20 00:14:57 2017 kern.debug kernel: [120478.05] UDP: bad
checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 36
Mon Feb 20 04:29:10 2017 kern.debug kernel: [135730.52] UDP: short
packet: From 172.31.90.47:698 4292/196 to 172.31.255.255:698
Mon Feb 20 04:43:53 2017 kern.debug kernel: [136613.51] UDP: bad
checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
Mon Feb 20 05:30:10 2017 kern.debug kernel: [139390.93] UDP: bad
checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 76
Mon Feb 20 08:04:44 2017 kern.debug kernel: [148664.22] UDP: bad
checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
Mon Feb 20 08:10:09 2017 kern.debug kernel: [148989.19] UDP: short
packet: From 172.31.90.47:698 33124/356 to 172.31.255.255:698
Mon Feb 20 10:14:49 2017 kern.debug kernel: [156469.96] UDP: bad
checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
Mon Feb 20 11:49:27 2017 kern.debug kernel: [162147.47] UDP: bad
checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
Mon Feb 20 12:00:06 2017 kern.debug kernel: [162786.32] UDP: short
packet: From 172.31.90.47:698 2396/348 to 172.31.255.255:698
Mon Feb 20 12:09:08 2017 kern.debug kernel: [163328.33] UDP: short
packet: From 172.31.90.47:698 440/312 to 172.31.255.255:1722
Mon Feb 20 12:18:34 2017 kern.debug kernel: [163894.17] UDP: bad
checksum. From 172.31.90.47:698 to 172.31.255.255:698 ulen 60
Mon Feb 20 12:26:42 2017 kern.debug kernel: [164382.85] UDP: short
packet: From 172.31.90.47:698 4324/228 to 172.31.255.255:698
Mon Feb 20 12:41:00 2017 kern.debug kernel: [165240.52] UDP: short
packet: From 172.31.90.47:698 408/400 to 172.31.255.255:698
Mon Feb 20 12:46:30 2017 kern.debug kernel: [165570.49] UDP: short
packet: From 172.31.90.47:954 1360/336 to 172.31.255.255:1722
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Decentralized internet

2017-02-20 Per discussione Nemesis 
On 02/19/2017 09:27 AM, Claudio Pisa wrote:
> On 02/05/2017 11:57 AM, nemesis wrote:
>> Io e Hispanico siamo a FOSDEM nella decentralized internet devroom,
> 
> Quello che mi salta all'occhio e' che parliamo di "decentralized
> internet", ma Internet al momento (almeno ai livelli 1-2-3) e'
> decentralizzata. Cosa volevano dire gli organizzatori con questo titolo?

Sarebbe da chiedere a loro, ma andando indietro riesco a ritrovare
l'annuncio iniziale che venne forwardato su varie liste:

https://lists.fosdem.org/pipermail/fosdem/2016-November/002495.html

I pezzi salienti a mio avviso:

"PCs are less and less used  while smartphones are soaring and data is
collected and stored on servers on which we have very limited control as
users."

...

"What happened to our  freedom and empowerment in the meantime?  The
outlook is not so great: we  have less and less control over our digital
environment."

"Network Neutrality is in danger and most code we use is proprietary and
runs on servers we don't have control over."

...

"We invite projects/individual working around these issues/topics to
submit proposals"

...

Topics could include all layers of the stack, from network, hardware,
OS, platform, apps and services:

* Community-driven networks, DIY access providers,
* Self-hosting software and distributions,
* Software aimed at keeping control over personal data,
* Community-hosted alternatives to GAFA

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