Setting up the mesh device

[Dan Williams]

On Wed, 2008-06-25 at 02:34 +0100, Sjoerd Simons wrote:
> On Tue, Jun 24, 2008 at 06:09:58PM -0400, Polychronis Ypodimatopoulos wrote:
> > Sjoerd Simons wrote:
> >> I'm setting the ESSID on the msh0 interface indeed. But i never get an
> >> association event on it.. While i even get an association event on eth0 when
> >> it's not up (but with msh0 being up obviously) :) Seems i've got some more
> >> bugs to file
> 
> >
> > Why would you set an ESSID on the mshX interface in the first place? I
> > understand that, from a solid layering perspective, you should be able
> > to set essids on mshX since it's treated as a wireless interface, but it
> > would logically separate network users. It's hard enough as it is to
> > discover nodes in different channels (although different channels do
> > have a radio scaling advantage).
> 
> Because we can? Seriously it's not for NetworkManager to decide this kind of
> policy, some higher layer needs to tell it what to do. If that's the same essid
> for all machine that's fine (most likely the update sugar NM bits will just
> have one essid hardcoded). The current wireless firmware might not even
> actually bother with checking essid's on traffic all.

The firmware's mesh functionality doesn't care what the SSID is.  The
only thing that distinguishes one mesh from another is the tuple of
(channel, encryption).  I don't even think BSSID matters (which it does
in ad-hoc and infrastructure networks).  Thus, the only policy that
upper layers can or need to apply is the channel and encryption that the
connection might use; hence why we eventually exposed the separate
channels in Sugar.

Dan

> The more important part, like Dan explained, is that this is the way
> to tell wireless drivers in linux to go and configure what's needed and tell us
> when they're ready for actual traffic (by means of an association event). So we
> can start doing things like dhcp and/or autoip.
> 
>   Sjoerd