Date: Tue, 9 Jul 2013 01:00:56 +0200 From: Monthadar Al Jaberi <monthadar@gmail.com> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-wireless@freebsd.org Subject: Re: [802.11s] mesh_forward() and (re)-encapsulating frames Message-ID: <CA%2BsBSoKBzmRQ70EURSJ7OxeM31k%2BjzrH=TEJOY6eghR5Lxe8oQ@mail.gmail.com> In-Reply-To: <CAJ-VmomJYFxPwX8wyO2vFdr2Mkk-2KALHw%2BvenWBzPOv_ski6Q@mail.gmail.com> References: <CAJ-VmomJYFxPwX8wyO2vFdr2Mkk-2KALHw%2BvenWBzPOv_ski6Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Sun, Jul 7, 2013 at 10:58 PM, Adrian Chadd <adrian@freebsd.org> wrote: > Hi monthadar (and others), > > I'm tidying up the 802.11s TX path in preparation to support 802.11n, > encryption, power-save handling, aggregation/fast-frames and other > such loveliness. > > In order to do this, the 802.11s TX path needs to use the existing VAP > methods to encapsulate and queue frames rather than directly queuing > to the parent device (ie, the physical device itself.) Because it > bypasses the normal encap path, it doesn't give the transmit path the > opportunity to do all the above handling. > > I've fixed this for all but the mesh_forward() path. In this case it > just fiddles with the mesh header, selects a new destination and sends > it to the physical interface. This assumes the frame is already > encapsulated from the receive path and it _completely_ uses the > contents of the existing frame before doing this. It bypasses all > processing. > > I've talked with monthadar about this in the past but we didn't come > up with an easy, satisfactory change to make this feasible. I'm now at > the point where I'd like to implement this. > > I'd like to take the existing frame, store the mesh header somewhere, > de-encapsulate it, then re-encapsulate it with the correct mesh > information. But I don't know how the mesh forwarding is supposed to > work. So, Monthadar (and others), what's supposed to happen with a > mesh frame being forwarded to another gateway? Basically what a meshSTA send to meshgate is an original frame, so no special case there, unless your thinking of a special case? But either way should be solved as what I have answered below. > > * What's supposed to happen to the mesh sequence number? Mesh sequence number should be decreased with 1. > * What's supposed to happen to the QoS header sequence number? (ie, > the sequence number space between the two peers) This is as if the frame is being sent originally from source mesh. As any other frame. > * What's supposed to happen for encryption? is it end-to-end > encryption, or hop-by-hop encryption? I havn't worked with encryption, others could have better knowldge. But to my knowldge it is hop-by-hop. > > Can I just get away with extending ieee80211_encap() to take a > meshcntl header and if I provide it, just use that instead of > calculating the contents in ieee80211_encap()? I think that'll be good > enough to get around the data path requirements and we can get back on > track getting this stuff ready for 802.11n and encryption. That is good enough, but how do you intend to save the mesh ctrl header to be associated with correct frame when it is in powersave? Mesh ctrl header is part the frame payload, so why not keep it there? That way you only decap the 802.11 header. The header could be either 3 or 4 address frames. But lets get something done first, and your solution is good enough for now :) > > Thanks! > > > -adrian -- Monthadar Al Jaberi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BsBSoKBzmRQ70EURSJ7OxeM31k%2BjzrH=TEJOY6eghR5Lxe8oQ>