Date: Mon, 8 Jul 2013 16:33:04 -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-VmokNbe5vFVNxACBnSPkgcKfF74KVqEnm1aCiKzEtYfrNvA@mail.gmail.com> In-Reply-To: <CA%2BsBSoKBzmRQ70EURSJ7OxeM31k%2BjzrH=TEJOY6eghR5Lxe8oQ@mail.gmail.com> References: <CAJ-VmomJYFxPwX8wyO2vFdr2Mkk-2KALHw%2BvenWBzPOv_ski6Q@mail.gmail.com> <CA%2BsBSoKBzmRQ70EURSJ7OxeM31k%2BjzrH=TEJOY6eghR5Lxe8oQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 8 July 2013 16:00, Monthadar Al Jaberi <monthadar@gmail.com> wrote: >> >> * What's supposed to happen to the mesh sequence number? > > Mesh sequence number should be decreased with 1. Decreased or increased by one? I can see the mesh TTL being decremented by one. >> * 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. The mesh header comes _after_ the QoS header, right? So there's both? >> * 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. Right. That's a bit sucky from a security perspective, but sure. It makes it much easier to do hardware encryption and such. >> 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? That's the real question, isn't it? Same with AMSDU/fast-frames support, etc. > 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 :) Well, the evil adrian here thinks we could just decap the 802.11 bit and store it as a frame that has mesh + 802.3. But then we'll have to special case things again, and I'm not really interested in having three cases in the code (802.3, 802.11, 802.11s.) It'll make things difficult to juggle. That's why I'm thinking we can just store the mesh information in an mbuf tag and reuse it when we need to. But what I really need to understand is all of the crazy logic and use-cases for the meshgate stuff. I don't have a clear picture of it in my head - admittedly I haven't sat down and _done_ the hard work to get a clear picture in my head. But I'll get there. Thus far: * When it's time to transmit it in ath(4) (ie, software queued in the driver, for A-MPDU or otherwise) then it's 802.11 + 802.11s + 802.3. That's easy, I don't have to care about it. * If it's coming in from if_transmit (ie, someone's queued an ethernet frame) then it'll be encapsulated as per normal. I don't have to care; that case is already taken care of. * If it's coming in from the receive path and we're retransmitting - it's already an 802.11 + 802.11s + 802.3 frame. We absolutely need to re-encapsulate the 802.11 bit before we queue it (because that's needed for the encryption handling, aggregation, etc.) We (at least now) won't have to deal with getting an 802.11s + 802.3 only frame this way. So, if we assume we _always_ get an 802.11+802.11s+802.3 frame, we can just do this: + re-encapsulate the 802.11 part + then if we need to do ampdu/amsdu/powersave staging, stage it as an 802.11 frame, rather than an 802.3 frame. .. but, the fast-frames code assumes it's getting two un-encapsulated 802.3 frames to assemble. And I think the amsdu support I'm going to write will assume the same thing. So the inefficient-but-sane thing to do may be this: + store the mesh control header as an mbuf tag - it's not that big, so I don't mind + strip the 802.11 bits + store the frame as an 802.3 frame - this then gets queued in the staging / powersave queues as per normal + then, when we pass it again through ieee80211_encap() to send it out, we restore the mesh control header and push it out. HOWEVER - this is why things are hairy - if we're going to encapsulate a frame for say, AMSDU or fast-frames support, we need to ensure that all the frames actually end up going to the same meshnode destination, as we only get one 802.11 header here. (ie, the AMSDU/FF support stores multiple 802.3 frames, not multiple 802.11 frames.) So we have to be careful when aggregating things. I don't know the right thing to do there except to be really paranoid and don't aggregate if there's a mesh header. (And thus for 11n we just do A-MPDU, no FF or AMSDU.) It'd be nice if we had a staging queue for AMSDU/FF aggregation per meshgate but .. that's messy. And let's ignore it for now. See what happens when I start thinking about these things? :-) Anyway - yes, we need to sort it out. mesh_forward() right now is just plain wrong ;-) -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmokNbe5vFVNxACBnSPkgcKfF74KVqEnm1aCiKzEtYfrNvA>