[Battlemesh] Extremely odd wireless network in the air causing problems

Wed Nov 27 23:48:16 CET 2013

Sometimes weather radar units are put up for sale at Hamfests.

http://ads22.imgur.com/all

Trigger DFS for all your friends, uncooperative spectrum neighbors
included. ;)

On Wed, Nov 27, 2013 at 4:00 PM, Michel de Geofroy <
micheldegeofroy at gmail.com> wrote:

> Maybe this is exactly what it is ... RF jamming ... I know of a ibiza WISP
> that jammed the competition to prepare his entry in the market.
>
>
>
> Michel
>
>
> Proudly Accepting Bitcoins 178QhTbSins1EnBqyL62k2uUrigh1Xc56Z you too
> start exchanging in bitcoins and join the revolution :)
>
> If you want to donate money or more to a good cause check out
> http://www.amigosolidarios.com/es/que_hacer.asp
>
> +34 606 88 22 79
> Skype micheldegeofroy
>
>
> On Wed, Nov 27, 2013 at 8:11 PM, Musti <musti at wlan-si.net> wrote:
>
>> Hi,
>>
>> thanks for the reply. Meanwhile I have figured this may be a non-targeted
>> deauthentication jamming.
>> http://hackaday.com/2011/10/04/wifi-jamming-via-deauthentication-packets/
>>
>> However what I am seeing now with tcpdump analysis is that these deauth
>> packets from a single source have an incremental destination address in a
>> rather peculiar form. First two sections remain constant, the others start
>> incrementing from left to right, rolling over back to 49:00:00…. in a
>> period of hours. Now that attack does not make sense, because it is not
>> targeting any specific manufacturer of type of the network, performing
>> pretty much just an RF jam and succeeding in it.
>>
>> 1029548 2450.247257000 28:00:de:6c:11:9e 49:00:1f:86:b5:6f 802.11 102 Deauthentication,
>> SN=2145, FN=1, Flags=........C[Malformed Packet] -89 dBm 6.0
>> 1029549 2450.252103000 28:00:de:6c:11:9e 49:00:2c:86:b5:6f 802.11 102 Deauthentication,
>> SN=2145, FN=1, Flags=........C[Malformed Packet] -90 dBm 6.0
>> 1029550 2450.260856000 28:00:de:6c:11:9e 49:00:43:86:b5:6f 802.11 102 Deauthentication,
>> SN=2145, FN=1, Flags=........C[Malformed Packet] -89 dBm 6.0
>>
>> Ideas welcome.
>>
>> Regards,
>> Musti
>>
>>
>>
>> On 27 Nov 2013, at 18:37, Ben West <ben at gowasabi.net> wrote:
>>
>> If there is any remote chance the party operating these radios is using
>> atheros chipsets with the ath9k_htc driver, then it may be possible to
>> spoof them into revealing their actual MAC addresses.
>>
>> http://www.mathyvanhoef.com/2013/11/unmasking-spoofed-mac-address.html
>>
>>
>> On Wed, Nov 27, 2013 at 3:19 AM, Musti <musti at wlan-si.net> wrote:
>>
>>> Hi folks,
>>>
>>> I am writing to you all with a description of a problem I am facing at
>>> the moment here in Slovenia, where a very odd wireless network is causing
>>> problems in existing networks. Any thoughts and ideas would be welcome.
>>>
>>> Location: Maribor, Slovenia
>>>
>>> A few days ago a network appeared in the air, that uses 802.11 but is
>>> not a conventional AP or mesh, transmitting at a rather high power in
>>> several directions, possibly omni at 5680MHz (ch 136). Triangulation of the
>>> signal thus-far has been a failure, not being able to find any consistent
>>> direction of the origin and perform triangulation. But looking at the
>>> traffic generated by this “thing” is where it gets weird.
>>>
>>> All the packets transmitted have a common BSSID: DE:6C:11:9E:DE:6C and
>>> originate from the following devices:
>>>
>>> 10:0E:DE:6C:11:9E
>>> E8:00:DE:6C:11:9E
>>> 28:00:DE:6C:11:9E
>>> 3E:00:DE:6C:11:9E
>>> 64:00:DE:6C:11:9E
>>> 30:00:DE:6C:11:9E
>>>
>>> As well as
>>> 10:0E:00:00:00:00
>>> E8:00:00:00:00:00
>>> 28:00:00:00:00:00
>>> 3E:00:00:00:00:00
>>> 64:00:00:00:00:00
>>> 30:00:00:00:00:00
>>>
>>> The MAC addresses do not appear to be from a valid vendor, first to
>>> sections changing make no sense really.
>>>
>>> Now things get even more strange, the traffic is of 6M bitrate,
>>> consisting only of DeAutehntication packets, utilising the maximum
>>> throughput of the channel, mostly originating from 28:00:DE:6C:11:9E.
>>> Example from tcpdump verbose output:
>>>
>>> 01:54:32.120993 30290112us tsft 6.0 Mb/s 5680 MHz 11a -87dB signal
>>> antenna 1 DeAuthentication (28:00:de:6c:11:9e (oui Unknown)): Reserved
>>>
>>> Some other packets of type ACK and RTS have been seen, but absolutely no
>>> data of any form.
>>>
>>> The measurements and observations were made using Ubiquiti Nanostation
>>> Loco M5, Nanobridge M5 25dB running openwrt AA, using Horst and tcpdump.
>>> Btw, on these devices the only way how to make horst listen on a specific
>>> channel appears to be by creating an ap on that channel and then adding a
>>> mon0 interface. Any ideas how to use it more conveniently or use automatic
>>> channel hopping. Manual setting of the channel allows only the first two
>>> digits to be entered.
>>>
>>>
>>> Any ideas on what other experiments to do and how to go about finding
>>> the source of this “noise” would be appreciated.
>>>
>>> Kind regards,
>>> Musti
>>> wlan slovenija
>>>
>>>
>>>
>>> _______________________________________________
>>> Battlemesh mailing list
>>> Battlemesh at ml.ninux.org
>>> http://ml.ninux.org/mailman/listinfo/battlemesh
>>>
>>
>>
>>
>> --
>> Ben West
>> http://gowasabi.net
>> ben at gowasabi.net
>> 314-246-9434
>>  _______________________________________________
>> Battlemesh mailing list
>> Battlemesh at ml.ninux.org
>> http://ml.ninux.org/mailman/listinfo/battlemesh
>>
>>
>>
>> _______________________________________________
>> Battlemesh mailing list
>> Battlemesh at ml.ninux.org
>> http://ml.ninux.org/mailman/listinfo/battlemesh
>>
>>
>
> _______________________________________________
> Battlemesh mailing list
> Battlemesh at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
>
>

-- 
Ben West
http://gowasabi.net
ben at gowasabi.net
314-246-9434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/battlemesh/attachments/20131127/ca99aa0f/attachment-0001.html>