From owner-freebsd-wireless@FreeBSD.ORG Sun Jul 7 20:58:44 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 56394E1 for ; Sun, 7 Jul 2013 20:58:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 1D767166B for ; Sun, 7 Jul 2013 20:58:44 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id u12so1935013qcx.26 for ; Sun, 07 Jul 2013 13:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=LL8696QImmPG1CQzzxLBw9wI7J9cklODie7lVc7NFNs=; b=tazYH0yrMr8co3bNrvPbc2vUeAVlBRs5dsE7SNc1Bu+q7XyhjmjKgl6/BcbeDAwsB0 Fd97sKdUHPgKcMs0kfcGpIXEihpDn+PKXXaPI/GC0xLfwClZyc9MxLIzsrdqu9vPiC7m qEmsna75BbtCV2veJ1cODJrqssKmxhH7P57j2tYa9BkODV8lDOH097ouPfVyGf/aXGfR EQ+g/RLicCnYzJUF/lG/RDhUgzulJwm0VP5d/S2eTAMP7LD3NDoWsqmCWz3zrkHhoiDH a6lYTKFWzztEvMwXADVUMZYFY0y749/fqnzJbORcaGbK4ceT83e0sf9sSzx6eCW2gIhV Vb1g== MIME-Version: 1.0 X-Received: by 10.224.5.199 with SMTP id 7mr1275860qaw.87.1373230722697; Sun, 07 Jul 2013 13:58:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.195.72 with HTTP; Sun, 7 Jul 2013 13:58:42 -0700 (PDT) Date: Sun, 7 Jul 2013 13:58:42 -0700 X-Google-Sender-Auth: dMM6uHHgVP9c6SX0OhOx1AIwZTM Message-ID: Subject: [802.11s] mesh_forward() and (re)-encapsulating frames From: Adrian Chadd To: freebsd-wireless@freebsd.org, Monthadar Al Jaberi Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jul 2013 20:58:44 -0000 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