From owner-freebsd-wireless@FreeBSD.ORG Mon Mar 4 02:11:57 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 B170055C for ; Mon, 4 Mar 2013 02:11:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by mx1.freebsd.org (Postfix) with ESMTP id 52B5E34E for ; Mon, 4 Mar 2013 02:11:57 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id ez12so1397380wid.12 for ; Sun, 03 Mar 2013 18:11:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=GScJAg4KCEq9LWOIxXrelEhuzBAJj5/m/SdgTZHU/SY=; b=ul9h43EB0J48QzDLTFLntOt45h4JnwvRtiH5Bk1Yt5af1TlHWoWFxHPUtNLh0ssaRq +5m8VUE3K9Ogc6bcUThr/Dam/0YDxxOP0AsXkiQc0uCyD0qsxpLH3CZpAmVhcm8w28bZ RFUUw+7bvvc6hTBHnh0NbajOo+yf5s29sF26RvmXoiRPPY1i5hBCNpN49krdiZuWjrmZ LtAfImzNNOA0tpa3nSDYW08b4USgH6gSq9XkDADavvwTMOW6KCJBKTRTIzyR0T9b8CDk KYvnfdA9nAwviBQUmkfrUHLGNMGiNu409U90YjIciT6M56GLRQZKPRZG/0Thq8jf6HG4 4xiA== MIME-Version: 1.0 X-Received: by 10.194.20.40 with SMTP id k8mr28962757wje.16.1362363110485; Sun, 03 Mar 2013 18:11:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.114.201 with HTTP; Sun, 3 Mar 2013 18:11:50 -0800 (PST) In-Reply-To: References: Date: Sun, 3 Mar 2013 18:11:50 -0800 X-Google-Sender-Auth: eDc9RWQWiEe9wbkHCrj9f0x8e9w Message-ID: Subject: Re: [RFC] net80211 TX, take 4 (final) From: Adrian Chadd To: freebsd-wireless@freebsd.org 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: Mon, 04 Mar 2013 02:11:57 -0000 Hi, So this stuff breaks Monthadar's meshing code. The mesh forwarding stuff takes mesh frames in mesh_input() that are destined for another node and potentially stuffs them back into the parent transmit queue, bypassing the rest of the stack. This has a bunch of potential interesting implications, like how exactly sequence numbers, encryption, power save and aggregation are supposed to work. Since the forwarded packets are being forwarded direct to the driver, there's no nice place to tie in things like power save. I don't know what the right thing to do is - should the frames be de-encapsulated and then reinjected into the VAP but with an already resolved destination node? Or? I'm open to other suggestions. I'm happy to just "fix" the mesh code right now to not panic with the locking work that I'm currently doing. But we do need to fix this. Adrian