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

[Josh King]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20120103/5f5aec14/attachment.sig>