On Tue, Jul 9, 2013 at 1:33 AM, Adrian Chadd <adr...@freebsd.org> wrote: > On 8 July 2013 16:00, Monthadar Al Jaberi <montha...@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.
You are correct about TTL, my mistake. but mesh sequence number should be the same when forwarded. This is to avoid loops, so each meshSTA that receives this will remember the seq. no. and discard it if it receives it a again. > >>> * 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? Look at this picture http://tr.docdat.com/pars_docs/refs/29/28671/28671_html_m4e2b3a71.png. I am not tottally fimilar with QoS, but I think you can discard it too, and only queue frame on correct AC queue. Mesh control header is in the frame playload and it should not be discarded. > >>> * 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. Why onl per meshgate forget the meshgate for now. Really you would need a queue per meshSTA neighbour. > > See what happens when I start thinking about these things? :-) Hehe, well you have a good grip on it, and really this could be a good time to restruct net80211 for big changes because of 11n. > > Anyway - yes, we need to sort it out. mesh_forward() right now is just > plain wrong ;-) > > > > -adrian -- Monthadar Al Jaberi _______________________________________________ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
