Date: Sun, 28 Jul 2013 20:32:29 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Monthadar Al Jaberi <monthadar@gmail.com> Cc: freebsd-wireless@freebsd.org Subject: Re: [802.11s] mesh_forward() and (re)-encapsulating frames Message-ID: <CAJ-Vmoka6DCamHtFbh1wDgRbz6LbERYLZDhLMEzR7RiiTC45nw@mail.gmail.com> In-Reply-To: <CA%2BsBSo%2BdnPq-4hxCvyVj=mzaNEVyAx3gCVR2OTQVhrisRnHP-w@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 * 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 * 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? -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmoka6DCamHtFbh1wDgRbz6LbERYLZDhLMEzR7RiiTC45nw>