Re: [PATCH 3/4] o80211s: (mac80211s) basic mesh interface support

[Dan Williams <dcbw@redhat.com>]

On Tue, 2007-11-13 at 15:31 -0500, Javier Cardona wrote:
> On 11/12/07, Johannes Berg <johannes@sipsolutions.net> wrote:
> > As far as I understand the specification, this
> > [different MAC address for the mesh interface] is not required. Since we
> > currently have no drivers supporting multi-MAC operation, this is quite
> > a severe limitation and the draft seems to allow MAP operation with a
> > single address, cf. the description of the SSID element in 7.2.3.1
> > (Beacon frame format). ("Note: the SSID is a required IE in beacon
> > frames. To avoid having non-mesh STAs [...]")
> >
> > Therefore, I think that having a separate MAP type device would be
> > beneficial because that allows hostapd to generate a beacon including an
> > SSID, respond to probe requests and still be a mesh point on the same
> > interface. The only way hostapd would have to be aware of this is that
> > it needs to create a different type of interface and include the mesh
> > information in the beacon.
> >
> > Do you see anything precluding such operation? Some more logic would
> > have to be provided to achieve the appropriate mesh broad/multicast vs.
> > AP broad/multicast behaviour, of course, as described elsewhere wrt.
> > mesh broad/multicast frames being broad/multicast to associated STAs.
> 
> The issue of mesh beacons is an open discussion at TGs right now (and
> by now I mean this week, in the IEEE 802.11 plenary in Atlanta).  It
> looks like a different mac address will be needed for the mesh
> interface if collocated with an AP.  That will be necessary for
> security and to avoid conflicts with legacy equipment.  In that case,
> the stack should generate the mesh beacons and hostapd generate the
> infrastructure beacons.
> 
> Anyway, I see no problem in renaming this IEEE80211_IF_TYPE_MESH_POINT
> (even though I just heard of a proposal to rename Mesh Points as Mesh
> Stations... )

How concrete is that?  It could obviously be changed later but best to
keep the code terminology consistent with the standards terminology
unless the standards terminology is completely wack.

Dan