> A mesh AP would have two interfaces, each with a different MAC
> address. One IF_TYPE_MESH, the other IF_TYPE_AP. Support for MAP, as
> you suggested, would be implemented in hostapd.
As far as I understand the specification, this 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.
johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
