<div dir="ltr">Hi Ben,<div><br></div><div>I am using a specially configured bridge based on OpenVSwitch... it works well without in Adhoc-mode without wpa_supplicant, no VLAN necessary. So I think there are some intereferences between the bridge and wpa_supplicant.</div>
<div><br></div><div>Henning</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 7, 2014 at 4:10 PM, Ben West <span dir="ltr"><<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Henning,<br><br></div>Adhoc wireless interfaces actually can't be bridged (AFAIK), at least not with the conventional 'bridge' option in /etc/config/wireless. I believe the preferred approach is to use the trelay package to forwards packages to/from a wireless interface to a VLAN.<br>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 7, 2014 at 1:36 AM, Henning Rogge <span dir="ltr"><<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
things getting even more strange... WPA2 WORKS if I remove the wlan<br>
interface from the openvswitch bridge...<br>
<br>
connection over the bridge does also work without wpa2... but not with both.<br>
<br>
very strange...<br>
<span><font color="#888888"><br>
Henning Rogge<br>
</font></span><div><div><br>
On Sat, Apr 5, 2014 at 7:26 AM, Henning Rogge <<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> found out the "psk2" vs "psk2+aes" problem myself, after looking<br>
> through OpenWRT scripts for a few hours... something in /lib/wifi/...<br>
> just looks for the "psk2" string, without any wildcards. So now it<br>
> seems encryption is active, but I have no connectivity at all<br>
> anymore... but that is a step forward.<br>
><br>
> Will continue to look into this matter on Monday. Thanks for your help.<br>
><br>
> Henning<br>
><br>
> On Fri, Apr 4, 2014 at 5:13 PM, Ben West <<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>> wrote:<br>
>> Ah ha! Some surprises from the OpenWRT folks!<br>
>><br>
>> Apologies for not fully testing the parameter set I gave. That was actually<br>
>> what I'm migrating all nodes towards that I manage, to drop older/outdated<br>
>> encryption standards. Yes, it looks like "encryption=psk2+aes" does not<br>
>> work for adhoc mode, failing silently, even though it works just fine for<br>
>> ap/sta mode.<br>
>><br>
>> "encryption=psk2" works for me on OpenWRT AA r39928 using the wpad package,<br>
>> which I verified (at least superficially) by running iwlist on an adjacent<br>
>> node.<br>
>><br>
>><br>
>><br>
>> On Fri, Apr 4, 2014 at 5:18 AM, Henning Rogge <<a href="mailto:hrogge@gmail.com" target="_blank">hrogge@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> are you sure about this parameter set?<br>
>>><br>
>>> I tested it between two Ubiquiti M Bullets (ath9k driver) on a up to<br>
>>> date OpenWRT AA with installed wpad.<br>
>>><br>
>>> I didn't got any error, everything worked. But then I noticed that<br>
>>> there is no wpad process running. So I changed the password on one of<br>
>>> the two nodes and rebooted it... and they still can talk to each<br>
>>> other. I assume that the network still runs "open".<br>
>>><br>
>>> Any tips what I could do?<br>
>>><br>
>>> Henning<br>
>>><br>
>>> On Thu, Apr 3, 2014 at 6:02 PM, Ben West <<a href="mailto:me@benwest.name" target="_blank">me@benwest.name</a>> wrote:<br>
>>> > This is possible in current generations of OpenWRT Attitude Adjustment,<br>
>>> > although I'm not completely sure if the pre-compiled v12.09 binaries<br>
>>> > support<br>
>>> > it reliably. It is called IBSS-RSN. You would need to include the<br>
>>> > package<br>
>>> > wpad or hostapd + wpa_supplicant. The wpad_mini package as-is doesn't<br>
>>> > include IBSS-RSN support.<br>
>>> ><br>
>>> > Below is an example /etc/config/wireless which I use for adhoc<br>
>>> > encryption on<br>
>>> > a UBNT Nano M2. To my knowledge, tho, IBSS-RSN is only possibly with<br>
>>> > pre-shared keys (i.e. key stored locally on each node's flash), which<br>
>>> > does<br>
>>> > bring up security issues. I.e. WPA Enterprise-style distribution<br>
>>> > encryption<br>
>>> > management isn't available yet.<br>
>>> ><br>
>>> > config wifi-device radio0<br>
>>> > option type mac80211<br>
>>> > option channel 5<br>
>>> > option hwmode 11ng<br>
>>> > option macaddr DC:XX:XX:XX:XX:XX<br>
>>> > option htmode HT20<br>
>>> > list ht_capab SHORT-GI-20<br>
>>> > list ht_capab SHORT-GI-40<br>
>>> > list ht_capab TX-STBC<br>
>>> > list ht_capab RX-STBC1<br>
>>> > list ht_capab DSSS_CCK-40<br>
>>> > option beacon_int 337<br>
>>> > # REMOVE THIS LINE TO ENABLE WIFI:<br>
>>> > option disabled 0<br>
>>> ><br>
>>> > config wifi-iface wmesh<br>
>>> > option network 'mesh'<br>
>>> > option mode 'adhoc'<br>
>>> > option device 'radio0'<br>
>>> > option ssid 'MyMesh'<br>
>>> > option bssid '02:CA:FF:EE:BA:BE'<br>
>>> > option encryption 'psk2+aes'<br>
>>> > option key 'areallyreallyreallyreallystrongpassword'<br>
>>> ><br>
>>> > To take advantage of all the entropy available, I'd recommend using a<br>
>>> > tool<br>
>>> > like pwgen to generate a randomized with maximum entropy, and of maximum<br>
>>> > length (e.g. 63chars).<br>
>>> ><br>
>>> > 802.11s meshing, i.e. layer 2 meshing, will at some point support the<br>
>>> > authsae encryption agent, i.e. for distributed encryption management<br>
>>> > that<br>
>>> > does not depend on pre-shared keys. But, I don't believe it's at a<br>
>>> > usable<br>
>>> > state just yet.<br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > On Thu, Apr 3, 2014 at 8:57 AM, Andrea Mannoni <<a href="mailto:andrea.mannoni@email.it" target="_blank">andrea.mannoni@email.it</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> Hi all,<br>
>>> >><br>
>>> >> I'm working for the implementation of an ad-hoc network that works, in<br>
>>> >> each repeater, with Openwrt + OLSR.<br>
>>> >><br>
>>> >> I discovered that one critical problem in an ad-hoc network is the<br>
>>> >> impossibility to encrypt it.<br>
>>> >><br>
>>> >> Did you find a solution at this problem?<br>
>>> >><br>
>>> >> Thank you for your support.<br>
>>> >><br>
>>> >> --<br>
>>> >><br>
>>> >><br>
>>> >> --<br>
>>> >> Olsr-users mailing list<br>
>>> >> <a href="mailto:Olsr-users@lists.olsr.org" target="_blank">Olsr-users@lists.olsr.org</a><br>
>>> >> <a href="https://lists.olsr.org/mailman/listinfo/olsr-users" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-users</a><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> ><br>
>>> > --<br>
>>> > Ben West<br>
>>> > <a href="mailto:me@benwest.name" target="_blank">me@benwest.name</a><br>
>>> ><br>
>>> > --<br>
>>> > Olsr-users mailing list<br>
>>> > <a href="mailto:Olsr-users@lists.olsr.org" target="_blank">Olsr-users@lists.olsr.org</a><br>
>>> > <a href="https://lists.olsr.org/mailman/listinfo/olsr-users" target="_blank">https://lists.olsr.org/mailman/listinfo/olsr-users</a><br>
>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Ben West<br>
>> <a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br>
>> <a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>
>> <a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>
314-246-9434<br></div>
</div>
</div></div></blockquote></div><br></div>