From owner-freebsd-wireless@FreeBSD.ORG Mon Jul 29 10:24:05 2013 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4CA0F4B9; Mon, 29 Jul 2013 10:24:05 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B0F8D2BCA; Mon, 29 Jul 2013 10:24:04 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id hq12so2197234wib.4 for ; Mon, 29 Jul 2013 03:24:03 -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=sMYvmg/kVaoRLepsjmxgZZPRwbyoMirtQyu0+0TqfK0=; b=ksEyGDNa354m7N7Imj5RfIT8aUtUBdARqPXrH1NL0d6QEMofOiz0luowARPBeP6M7g fxJQVSCX3hfcx54M018BvdAgiVtQirWf+qbw5AUl7jRI8h9EnA4cPHYME0Oa5x6mVtnO EPtpiEK0eY+mE7SvWZp8/v7GaKQEssK+lc7GVrkKVJNliBJcEuRJlzQI8yB8mEpWdxQI RKbEhThvrHdMOKQEBt7oiDf1hGKWdytAkdYR1JlSfUfqs/qp8hnAz8itqma7jS2Tc5ZK bh5AamvaH1rSiiW85KF9PJlfpJnqS3iNFUGfTdoi5f/sBG11lLGSmler/i8lzVi5cRba BY1A== MIME-Version: 1.0 X-Received: by 10.194.77.99 with SMTP id r3mr42708473wjw.5.1375093442950; Mon, 29 Jul 2013 03:24:02 -0700 (PDT) Received: by 10.227.212.133 with HTTP; Mon, 29 Jul 2013 03:24:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Jul 2013 12:24:02 +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, 29 Jul 2013 10:24:05 -0000 On Mon, Jul 29, 2013 at 5:32 AM, Adrian Chadd wrote: > Hi, > > * I think we can get away with one queue per mesh STA neighbor for > now. Which is effectively what we have in ath(4) and we will have in > net80211 soon Yupp, the 80211 queue per meshSTA neighbour part is important if we want to queue in net80211, and that what Linux have. > * THanks for the clarification for mesh sequence number. So we: > + Increment it if we're generating a frame into the mesh network; > + Keep it the same if we're forwarding a frame to a mesh peer / mesh gate Correct. > * If we store the mesh control header in the mbuf, and de-encapsulate > the frame, then re-inject into the VAP path with the correct > destination node, we could then teach the VAP path to check for that > tag and if it's there, populate the mesh header from _that_. If it's > not there, we create a new mesh tag and continue the encapsulation > phase. > > How's that sound? Sounds music to my ears =) Let's go for it! > > > > -adrian -- Monthadar Al Jaberi