[Olsr-users] High-level questions about encryption on OLSR ad-hoc mesh

Keith Berkoben (spam-protected)
Wed Apr 13 15:25:58 CEST 2011


Hmm, I've been using picoM and nanoM-loco devices with ath9K in openWRT, and
I admit I've never sniffed a packet to see if it's actually encrypted, but
it doesn't yell at me when I set encryption to psk2, and all the devices
talk happily.

As far as diminishing returns, you're only upping the data rate by a factor
of 4 or so with 100Mbps links.  I can't imagine that's enough to render an
otherwise fairly robust encryption useless.

~Keith

On Tue, Apr 12, 2011 at 9:49 PM, Ben West <(spam-protected)> wrote:

> Hi Keith,
>
> My present firmware stack (OpenWRT + ath9k in mesh mode) appears to support
> no layer2 encryption for Nano M5 radios I'm using, i.e. WPA-NONE, WPA, WEP.
>  I'd love to be wrong about that.  Madwifi might do it, but then I'd lose
> nice features of the radio like HT modes.
>
> Also, other responders on this thread mentioned diminishing returns in
> using even WPA2 (?) for 100Mbs+ links, since you reduce the time required
> for cracking the key, IIRC.
>
>
> On Tue, Apr 12, 2011 at 8:42 PM, Keith Berkoben <(spam-protected)>wrote:
>
>> Why would WPA not work?  (assumes you have control of all the nodes in the
>> network to set the keys)
>>
>> ~Keith
>>
>> On Tue, Apr 12, 2011 at 9:32 PM, Ben West <(spam-protected)> wrote:
>>
>>> Hi Saverio,
>>>
>>> Thanks for the references to tinc.
>>>
>>> Going on the assumption that one still wouldn't want to run tinc on
>>> access point itself (whose CPUs run at 180MHz or 400MHz), and that the
>>> end-user wouldn't run tinc on their desktop, do you have experience running
>>> tinc on a dedicated box at the mesh's edge, with the other end of the tinc
>>> tunnel terminating at whatever box manages your mesh's wired uplink(s)?
>>>
>>> For example, a scenario I see: a subscriber to my 5GHz adhoc mesh wants
>>> to use a credit card reader, which has a 10baseT port. Although my mesh's
>>> routing plane is somewhat secured using olsr_secure plugin, the actual
>>> traffic is not encrypted due to lack of WEP/WPA/etc, and the reader would
>>> furthermore be sending card numbers (possibly in plaintext!) over that link.
>>>
>>> My mesh's wired uplink is managed by a Mikrotik board, 400MHz CPU / 64MB
>>> RAM, running OpenWRT for QoS, but no radio or OLSR.  Assuming this board has
>>> adequate CPU/RAM bandwidth spare to terminate one (or preferably several)
>>> tinc tunnels thru the mesh, could I secure the reader's link with a ~50$US
>>> box with 32MB RAM running OpenWRT+tinc, sitting between the reader's LAN
>>> port and its mesh access point?
>>>
>>> That is, something like this:
>>> http://www.bizsyscon.com/product/MIKROTIK__+RB450__5038.html
>>>
>>> Or even a WRT54GL running OpenWRT under 16MB RAM and 180MHz CPU?
>>>
>>> Are there effective minimum hardware requirements for tinc?  The credit
>>> card traffic in this example would be very small (e.g. <100kbs), but it
>>> would be latency sensitive.
>>>
>>> On Tue, Apr 5, 2011 at 2:49 AM, ZioPRoTo (Saverio Proto) <
>>> (spam-protected)> wrote:
>>>
>>>> > limited encryption is supported for adhoc/mesh modes, I'm curious if
>>>> anyone
>>>> > on the list has good experience using OpenVPN with OpenWRT meshes?
>>>>  I'm
>>>>
>>>> we do not use tunnels on the mesh itself, however to convey traffic
>>>> from the edge of the mesh towards our central server where the NAT to
>>>> the actual Internet is done, we use tinc-vpn
>>>>
>>>> we like much more tinc than openvpn on embedded devices
>>>>
>>>> http://tinc-vpn.org/
>>>> http://wiki.ninux.org/TincVPN
>>>>
>>>> regards
>>>>
>>>> Saverio
>>>>
>>>
>>>
>>>
>>> --
>>> Ben West
>>> (spam-protected)
>>>
>>>
>>> --
>>> Olsr-users mailing list
>>> (spam-protected)
>>> http://lists.olsr.org/mailman/listinfo/olsr-users
>>>
>>
>>
>
>
> --
> Ben West
> (spam-protected)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20110413/b7ce571f/attachment.html>


More information about the Olsr-users mailing list