From owner-freebsd-current@FreeBSD.ORG Thu Oct 20 14:51:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6518B16A41F; Thu, 20 Oct 2005 14:51:53 +0000 (GMT) (envelope-from atrens@nortel.com) Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEA6243D5A; Thu, 20 Oct 2005 14:51:52 +0000 (GMT) (envelope-from atrens@nortel.com) Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j9KEpkF10575; Thu, 20 Oct 2005 10:51:46 -0400 (EDT) Received: from [10.0.5.2] ([47.128.22.25] RDNS failed) by zcarhxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Oct 2005 10:51:44 -0400 Message-ID: <4357AEE4.7050503@nortel.com> Date: Thu, 20 Oct 2005 10:51:16 -0400 From: "Andrew Atrens" User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Thompson References: <43560B6A.4070505@mikulas.com> <20051019091559.GA45009@heff.fud.org.nz> <43565782.8080706@nortel.com> <7B0B2AA4-5178-4C0F-BB7B-869CB7FC29AC@netgate.com> In-Reply-To: <7B0B2AA4-5178-4C0F-BB7B-869CB7FC29AC@netgate.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2005 14:51:44.0079 (UTC) FILETIME=[C9AC0DF0:01C5D585] X-Mailman-Approved-At: Fri, 21 Oct 2005 12:33:50 +0000 Cc: freebsd-current@freebsd.org, Jiri Mikulas , Andrew Thompson Subject: Re: ath client bridge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2005 14:51:53 -0000 Jim Thompson wrote: > > On Oct 20, 2005, at 3:24 AM, Jim Thompson wrote: > > > 1 0 DA BSSID SA X > > more importantly, when a device "behind" the AP sends a packet for and > SA that is behind your "client bridge", how does the AP know where to > send the frame on the wireless medium? Aha. I had SA confused with TA. Please replace SA with TA on my last response. :) The kludge I see my deliberant 'wireless' bridges use is some kind of 'mac nat', so SA gets replaced by TA when the client bridges the packet out to the AP. > > Or, in this case: > > 0 1 BSSID SA DA X > > When a device "behind" your client bridge sends a frame through your > client bridge, and "SA" is this "device behind", how can the AP > possibly accept the frame. It doesn't (appear) to come from an > associated STA (SA isn't the address for the device that sent the > packet), and the AP certainly can't ACK the frame, (so why would it > forward it?) The deliberants replace SA by TA, do mac 'nat' and proxy-arp. The fact that I need a solution next week is what pushed me down the road of bridging gif interfaces, because ETHERIP encaps the entire bridged packet. Incidentally, I'm hoping with some more tweaking I can put the gif interface through an ipsec tunnel. So then I have a 'tunneled' encrypted bridge. OpenBSD does this already, though their stacks are different, but so far it looks doable. > > This is why the "4 address" frame type (with FromDS and ToDS both set) > exists. > > 1 1 RA TA DA SA > > RA = device on wireless media "receiving" the frame > TA = device on the wireless media "transmitting the frame" > SA = original source of the packet > DA = original (and ultimate) destination of the packet Thanks I had TA and SA mixed up. :) Andrew.