Date: Sun, 7 Jul 2013 13:58:42 -0700 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org, Monthadar Al Jaberi <monthadar@gmail.com> Subject: [802.11s] mesh_forward() and (re)-encapsulating frames Message-ID: <CAJ-VmomJYFxPwX8wyO2vFdr2Mkk-2KALHw%2BvenWBzPOv_ski6Q@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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? * 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. Thanks! -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomJYFxPwX8wyO2vFdr2Mkk-2KALHw%2BvenWBzPOv_ski6Q>