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

[Adrian Chadd]

So what's the specific difference between normal station and meshSTA?



-adrian

On 29 July 2013 03:24, Monthadar Al Jaberi <monthadar at gmail.com> wrote:
> 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