Date: Sun, 3 Mar 2013 18:11:50 -0800 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org Subject: Re: [RFC] net80211 TX, take 4 (final) Message-ID: <CAJ-VmomJFoeEwt_vBSLcR7iSu2pqiDYBz3toaXASeZK%2Bb2JHuA@mail.gmail.com> In-Reply-To: <CAJ-Vmo=ezSiyyUVf%2BLnrhfb8Fz1wi_PWTPV8YizqgkeeyY-rzA@mail.gmail.com> References: <CAJ-VmomnbLh9OdpNVL1=ahkuN6Y_LGY%2BZLbW-PK=mTAZducLCA@mail.gmail.com> <CAJ-Vmo=ezSiyyUVf%2BLnrhfb8Fz1wi_PWTPV8YizqgkeeyY-rzA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, So this stuff breaks Monthadar's meshing code. The mesh forwarding stuff takes mesh frames in mesh_input() that are destined for another node and potentially stuffs them back into the parent transmit queue, bypassing the rest of the stack. This has a bunch of potential interesting implications, like how exactly sequence numbers, encryption, power save and aggregation are supposed to work. Since the forwarded packets are being forwarded direct to the driver, there's no nice place to tie in things like power save. I don't know what the right thing to do is - should the frames be de-encapsulated and then reinjected into the VAP but with an already resolved destination node? Or? I'm open to other suggestions. I'm happy to just "fix" the mesh code right now to not panic with the locking work that I'm currently doing. But we do need to fix this. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomJFoeEwt_vBSLcR7iSu2pqiDYBz3toaXASeZK%2Bb2JHuA>