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... )
Javier
-
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
