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
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
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?
* What's supposed to happen to the mesh sequence number?
* What's supposed to happen to the QoS header sequence number? (ie,
the sequence number space between the two peers)
* What's supposed to happen for encryption? is it end-to-end
encryption, or hop-by-hop encryption?
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"