Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 7 Dec 2013 21:33:20 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        Monthadar Al Jaberi <monthadar@gmail.com>
Cc:        "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org>
Subject:   Re: [802.11s] mesh_forward() and (re)-encapsulating frames
Message-ID:  <CAJ-VmomvZjxBd%2BfsbCn%2BfEi1R95gSb3xEdMV4csyKeH_RoQ96Q@mail.gmail.com>
In-Reply-To: <CAJ-Vmomp8KXgm4xAN=0Ca%2B8fx45ut3upPr5dUqDEw=eRCYV=MQ@mail.gmail.com>
References:  <CAJ-VmomJYFxPwX8wyO2vFdr2Mkk-2KALHw%2BvenWBzPOv_ski6Q@mail.gmail.com> <CA%2BsBSoKBzmRQ70EURSJ7OxeM31k%2BjzrH=TEJOY6eghR5Lxe8oQ@mail.gmail.com> <CAJ-VmokNbe5vFVNxACBnSPkgcKfF74KVqEnm1aCiKzEtYfrNvA@mail.gmail.com> <CA%2BsBSo%2BdnPq-4hxCvyVj=mzaNEVyAx3gCVR2OTQVhrisRnHP-w@mail.gmail.com> <CAJ-Vmoka6DCamHtFbh1wDgRbz6LbERYLZDhLMEzR7RiiTC45nw@mail.gmail.com> <CA%2BsBSoKQDvDkkwg%2Bh9aJ99Vt5XZsOS3r5fUxoT8vyhfGAQ542Q@mail.gmail.com> <CAJ-Vmomp8KXgm4xAN=0Ca%2B8fx45ut3upPr5dUqDEw=eRCYV=MQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi Monthadar and others,

I'm starting to tackle this again.



-a


On 29 July 2013 06:11, Adrian Chadd <adrian@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@gmail.com> wrote:
>> On Mon, Jul 29, 2013 at 5:32 AM, Adrian Chadd <adrian@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomvZjxBd%2BfsbCn%2BfEi1R95gSb3xEdMV4csyKeH_RoQ96Q>