[Commotion-dev] Has anyone tried running Commotion with multiple virtual AP's?

Tue Jan 3 23:04:16 UTC 2012

Hi Josh,

Thanks for detailed response. I had posted the initial query specifically
about Commotion and multiple vAP's since I am looking for a platform to
migrate ~50 ath5k-based radios off of the current psuedo-stable ROBIN r3xxx
firmware.

Eliding over a long story: ROBIN works well present at present running OLSR
0.5.6-based  mesh on single-radio ath5k devices, but only on ath5k chipset
and with the madwifi driver packaged into OpenWRT Kamikaze.  It also has a
hard dependency on the ah-demo mode (as opposed to adhoc), and in
particular on running ah-demo + 2 other vAPs in managed mode.

There is an unstable version of ROBIN v2 based on Backfire (and thus with
ath9k support), but its developer community is tied up with other
priorities.

I'm presently looking at a couple options for migrating away from ROBIN
r3xxx:

1. Fix the broken stuff in ROBIN v2, so that it is suitable for production
use
2. Add ROBIN-like features to Commotion

Ideally, a combination of #1 and #2 would yield mutual benefits for both
user bases, especially since the current roadmap w/ ROBIN may end up
abandoning a large fraction of its user base.

The "ROBIN-like" features would be:

1. Centralized config mgmt via mesh dashboards like Cloudtrax, robin-dash,
wifi-mesh.
2. Related to #1, reporting of mesh health and live operational stats back
to dashboard (i.e. uptime, RSSI, # connected clients)
3. Support for CoovaChilli v1.2 captive portals
4. Auto-configuration of newly flashed nodes

ROBIN v2 does support all four, but it has stability problems with the
r28xxx generation Backfire it was last tested on in Sept. `11.

On Tue, Jan 3, 2012 at 8:27 AM, Josh King <josh at chambana.net> wrote:

> Hi Ben,
>
> Actually most development on CommotionWRT has been done on quite the
> opposite (devices w/ one radio, but multiple VAPs). There is some
> configuration done w/ hardware interfaces, but those interface names are
> retrieved as much as possible from the OpenWRT config files, and each
> VAP when it's created has an actual interface name (like wlan0), so it's
> all VAPs that it's operating on. I'm typing from my phone right now, but
> as far as I recall boot-up order goes like this:
>
> * OpenWRT by default starts without an /etc/config/wireless file. On
> first boot, /etc/init.d/network checks for that file and if it doesn't
> find it, detects the wireless cards and creates a default config (using
> code in /lib/wifi/mac80211.sh), with the radios marked disabled. This is
> hijacked by the /etc/init.d/meshconfig script, which runs first and does
> the detection process to generate /etc/config/wireless. It then parses
> /etc/config/network, and makes sure that for each network interface,
> there's a VAP in /etc/config/wireless (it tries to distribute them
> somewhat intelligently; if there are multiple physical radios, it puts
> the ad-hoc mesh interface on the first one and then distributes the AP
> interfaces across the other radios).
>
> * Then the regular OpenWRT network initialization runs, which calls the
> coldplug_* functions for each Commotion interface. These functions
> configure the wireless VAPs created in the last step (setting SSIDs,
> etc). The wireless is then brought up.
>
> * Finally, the setup_interface_* functions are called, which configure
> the IPs, firewall, etc for each interface. They also make a series of
> hotplug calls, which run scripts in /etc/hotplug.d/ to configure various
> services, like OLSRd.
>
> There are definitely things that could be done better. For instance,
> there are default interface names in /etc/config/network. This is done
> to avoid complexity, as OpenWRT seems to assume that if you're building
> a hardware-specific image you at least know what the hardware looks like
> ;-) However, this falls apart when building, say, an x86 iso. It's also
> a bit of a problem in that it seems that most drivers want to have the
> ad-hoc interface on the highest numbered interface (i.e., if you have an
> AP on wlan0, and an ad-hoc on wlan1, and then you add another AP, the
> ad-hoc becomes wlan2, and the second AP becomes wlan1, rather than just
> incrementing interfaces like you'd expect). There's also the fact that
> the whole IP address selection scheme from converting MAC addresses is
> rather naive, and we should support several replacements as well.
> Ideally, these would include hashing the MAC address to create the IP, a
> la the IPv4LL or whatever it's called standard that gets you 169.254.*
> addresses, along with the option of randomizing the MAC address, or
> using just IPv6 addresses, or generating this all from a UUID that's
> created at boot. I'm hoping to address all this for a forthcoming PR2.x
> point release, but not all of it is solidified so patches, commits, and
> suggestions welcome.
>
>
>
> Ben West <me at benwest.name> wrote:
>
> >I just cloned & compiled the most recent repo contents for Commotion,
> >and I
> >am wandering thru its default config files.
> >
> >I notice the functions setup_interface_meshif() and
> >setup_interface_apif()
> >will operate on the hardware names of the mesh and AP interfaces,
> >respectively.
> >https://tech.chambana.net/documents/1
> >
> >Has all testing/operation for Commotion to date been done on devices
> >with
> >multiple physical radios (or just one radio and only the mesh
> >interface)?
> >Has anyone yet tried running mesh + AP on multiple virtual APs (VAPs)
> >with
> >either ath5k or ath9k?
> >
> >--
> >Ben West
> >me at benwest.name
> >_______________________________________________
> >Commotion-dev mailing list
> >Commotion-dev at lists.chambana.net
> >http://lists.chambana.net/mailman/listinfo/commotion-dev
>
>

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