[Commotion-dev] OpenWRT trunk r33202 does PSK-encrypted adhoc on ar71xx

[Ben West]

Hi All,

For a follow here, I have been able to get IBSS RSN (aka PSK-encrypted
mesh) working now on an Open Mesh OM1P (aka Atheros AR2315 chipset), and it
does successfully mesh with the existing two UBNT ar71xx nodes.  So,
encrypted mesh does work for atheros and ar71xx targets on OpenWRT trunk
r33202.

I've been letting all 3 nodes mutually fping each other as fast as they
will allow (roughly 1 ping per 50ms) for the past several days.  So for no
lockups or ugly complaints appearing in kernel logs, despite ifconfig
reporting multiple GBytes transferred.

The problem with ath5k images not booting is actually due to a recently
introduced compile option mucking with older ath5k devices:
https://lists.openwrt.org/pipermail/openwrt-devel/2012-August/016539.html

On Thu, Aug 23, 2012 at 6:04 PM, Ben West <ben at gowasabi.net> wrote:

> Hi All,
>
> Sharing some results from a couple weeks of surfing the choppy waters
> of recent OpenWRT trunk: I have been able to get 2 UBNT ar71xx nodes
> to mesh with PSK-encrypted adhoc, aka IBSS RSN.
>
> You can even configure the encryption in /etc/config/wireless,
> provided you use hostapd and wpa_supplicant packages instead of wpad
> or wpad-mini.
>
> Known so far:
> - The meshconfig tool bundled w/ Commotion does not work at all,
> likely due to significant changes made after trunk r31639 for netifd
> support.  I unfortunately could not glean more info about this, since
> nodes flashed w/ the commotionbase package atop r33202 trunk became
> completely unresponsive.  I have a TTL/serial cable on order, to
> hopefully learn more about this.
> - Likewise, the freifunk-watchdog service (ffwatchd), as configured &
> bundled w/ Commotion, doesn't seem to like an encrypted mesh.  I saw
> it repeatedly restarting the wireless interfaces, so I removed that
> pkg from the firmware images I was testing with.  I posted a query to
> this list previously if anyone knows of documentation available for
> ffwatchd.
> - Although you can indeed specify "encryption psk" for the mesh VAP in
> /etc/config/wireless, a bug with wpa_supplicant.sh causes that VAP to
> lose its assigned IP address thereafter.  I had do "ifconfig wlan0
> 10.12.x.x" after bringing up the wireless to restore the IP address.
> - "iw wlan0 station dump" suggests that nodes joining an encrypted
> mesh do not get reliably "authorized," even when they are
> "authenticated."  On the un-authorized node where I observed this, I
> bringing its wlan0 down and then back up resolved this.
> - My UBNT nodes were able to ping each other (even at 10ms intervals
> using fping) OK for days, until a power blip reset them.
>
> Unknown, so far:
> - Whether this works for ath5k too.  Trunk r33202 does not appear to
> boot at all on ath5k, although recent patches submitted to trunk do
> explicitly mention IBSS RSN support for ath5k.
> - What sort of speed penalty this imposes, or if the PSK encryption is
> done in hardware or software on either platform.
> - Whether ar71xx/ath5k driver will let you add more VAPs (encrypted or
> not) to a physical interface already broadcasting an encrypted mesh.
> - Whether hostapd-mini and wpa-supplicant-mini will correctly
> configure IBSS RSN, too.
>
> It looks like much thanks for getting IBSS RSN to a functional state
> on Atheros chips should go to Antonio Quartulli, who is involved with
> the BATMAN-based project http://open-mesh.org.
>
> --
> Ben West
> http://gowasabi.net
> ben at gowasabi.net
>



-- 
Ben West
me at benwest.name
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20120831/0c163b30/attachment.html>