On Tue, 2007-11-13 at 15:31 -0500, Javier Cardona wrote:
> On 11/12/07, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
