Skip site navigation (1)Skip section navigation (2)
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>