From owner-freebsd-wireless@FreeBSD.ORG Mon Jul 8 23:00:57 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DACD9FE0; Mon, 8 Jul 2013 23:00:57 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by mx1.freebsd.org (Postfix) with ESMTP id 510501DE5; Mon, 8 Jul 2013 23:00:57 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id n11so4162446wgh.33 for ; Mon, 08 Jul 2013 16:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FwrqXpAGZEeCTHUa3IiPR6OFlvGlU50Bahso2dL5BSU=; b=tts20Rmkc2Lyda8DBzPc8FiuXy0MxGvhpITDqarECeauIMnXO+bZVpQ4cJW6wKpCbN 91p5BKyxSHVydULgoOw4X0o5MssmJHnbyxUltc17TIAI8ZIMd63fgexrSg09LdtcANIz aD15JpSJbAAZGUhtm2kYEKlSN4fguCum21xwBJZEtn72HFl1+pkqI0C6sM4n3OqBee9Q F3OoyiUFT3ZnOgnRE8J2Er4m8vQphQqGSye8rH4Egb+aIdsJGc2wWZOBFk+JIcEH6zry Yxm6pu0qZzIC8qPAkOH1I3m1vcUlDwbk8bhs2OX4Fl58wGHbyupClLp5IwItDIVG25bw PTTA== MIME-Version: 1.0 X-Received: by 10.180.80.166 with SMTP id s6mr3610229wix.38.1373324456481; Mon, 08 Jul 2013 16:00:56 -0700 (PDT) Received: by 10.227.173.141 with HTTP; Mon, 8 Jul 2013 16:00:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Jul 2013 01:00:56 +0200 Message-ID: Subject: Re: [802.11s] mesh_forward() and (re)-encapsulating frames From: Monthadar Al Jaberi To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org 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: Mon, 08 Jul 2013 23:00:57 -0000 Hi, On Sun, Jul 7, 2013 at 10:58 PM, Adrian Chadd wrote: > 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? Basically what a meshSTA send to meshgate is an original frame, so no special case there, unless your thinking of a special case? But either way should be solved as what I have answered below. > > * What's supposed to happen to the mesh sequence number? Mesh sequence number should be decreased with 1. > * 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. > * 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. > > 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? 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 :) > > Thanks! > > > -adrian -- Monthadar Al Jaberi