From owner-freebsd-wireless@FreeBSD.ORG Sun Mar 10 21:33:44 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 096AD330; Sun, 10 Mar 2013 21:33:44 +0000 (UTC) (envelope-from monthadar@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by mx1.freebsd.org (Postfix) with ESMTP id 5F787157; Sun, 10 Mar 2013 21:33:43 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hq4so579052wib.17 for ; Sun, 10 Mar 2013 14:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=saFo2W2T+hy+KCGsT0sFm6nbi+o1XbJ2cJTe2qyRhoY=; b=VpO7HoOEUI12F253Ool3skyksFD095FXIyCOQRgomIq2AobwTf9VTw6UDdBvR8sGNA yR2wxxlX+5XKzTRsnCapc8yCPSLndn5Ye0FJ9qrQppDXYsE8WcnYN+J+FIXqLSh/AXFj MrehfkNX57YEYjuoJLlFPjumyvUgBluFvboPx9KKT+8uqjVliShConi8rrvnZJSgttMb FKhEOav34ACyL5yKeCRF835+Ywg3jN5AueQpxEfGw8ywXf2XxfPkHRzNNs4429zjKaGb XzOwiZVeRw36E7ybM635YZBBnAZb9mlhuriY++lhSWTcS+cL5sfYjXFm0UejjNJj8wIL XCww== MIME-Version: 1.0 X-Received: by 10.180.83.39 with SMTP id n7mr8835508wiy.8.1362951222474; Sun, 10 Mar 2013 14:33:42 -0700 (PDT) Received: by 10.227.165.9 with HTTP; Sun, 10 Mar 2013 14:33:42 -0700 (PDT) In-Reply-To: References: Date: Sun, 10 Mar 2013 22:33:42 +0100 Message-ID: Subject: Re: [RFC] net80211 TX, take 4 (final) 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: Sun, 10 Mar 2013 21:33:44 -0000 Sorry for late reply. On Mon, Mar 4, 2013 at 3:11 AM, Adrian Chadd wrote: > 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. The sequence number should be set as if the meshSTA is transmitting normal frames. Powersave, encryption and aggregation is not implemented for mesh right now. I am unsure about how it would be and how it could effect the TX-serialization issue. > > 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 don't think we can de-cap the frame at all. If you decap a mesh frame you would loose some information. Lost information could be things like mesh TTL. As it's done right now the frame is duplicated. After modifying necessary fields we call ieee80211_parent_transmit(ic, mcopy); My solutions right now: keep it as it is and create a new raw_xmit that honors the TX-serialization framework. > > 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. Do that if your unsure, I will go through it when I get some time over. > > > > Adrian > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org" -- Monthadar Al Jaberi