[802.11s] mesh_forward() and (re)-encapsulating frames

[Monthadar Al Jaberi]

On Mon, Jul 29, 2013 at 5:32 AM, Adrian Chadd <adrian at freebsd.org> wrote:
> Hi,
>
> * I think we can get away with one queue per mesh STA neighbor for
> now. Which is effectively what we have in ath(4) and we will have in
> net80211 soon

Yupp, the 80211 queue per meshSTA neighbour part is important if we
want to queue in net80211, and that what Linux have.

> * THanks for the clarification for mesh sequence number. So we:
>   + Increment it if we're generating a frame into the mesh network;
>   + Keep it the same if we're forwarding a frame to a mesh peer / mesh gate

Correct.

> * If we store the mesh control header in the mbuf, and de-encapsulate
> the frame, then re-inject into the VAP path with the correct
> destination node, we could then teach the VAP path to check for that
> tag and if it's there, populate the mesh header from _that_. If it's
> not there, we create a new mesh tag and continue the encapsulation
> phase.
>
> How's that sound?

Sounds music to my ears =)

Let's go for it!

>
>
>
> -adrian



-- 
Monthadar Al Jaberi