Somehow I kept this around, sorry... > The mesh ID works as the SSID for mesh networks, on mesh beacons/probes > SSID is set to the wildcard value to avoid interfering with non-mesh > STAs. Right. So it's just the mesh identifier. > An MP only opens a peer link with a neighboring mesh peer if you have > the same mesh configuration. This mesh configuration is composed by the > mesh ID and path discovery protocol/metric/congestion control IDs. Once > the link is open the mesh ID is not included in the frames. Let me know > if you want more info. We don't have settings for the other control IDs yet, or did I miss them? > It might be a good idea as you suggest in another thread to refuse to > change the mesh id for running interfaces as it would make a lot of > information stale, will consider it. Ok. I think this is quite a difference to the SSID where you can roam between networks, but I guess that roaming between different mesh networks doesn't really make sense since the point is to be part of the mesh... I still think the mesh parameters could be per-interface attributes rather than require a new command, but I'm not too fixed on the idea either (although currently it breaks the get/set/new/del grouping. Another, off-topic in this thread, question: How is beaconing defined for a mesh point? Is it similar to how it works in an IBSS? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
