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.
>> * 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.
* 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 ;-)
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"