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

[Adrian Chadd]

Hi Monthadar and others,

I'm starting to tackle this again.



-a


On 29 July 2013 06:11, Adrian Chadd <adrian at freebsd.org> wrote:
> 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