Date: Thu, 20 Oct 2005 10:51:16 -0400 From: "Andrew Atrens" <atrens@nortel.com> To: Jim Thompson <jim@netgate.com> Cc: freebsd-current@freebsd.org, Jiri Mikulas <konfer@mikulas.com>, Andrew Thompson <thompsa@freebsd.org> Subject: Re: ath client bridge Message-ID: <4357AEE4.7050503@nortel.com> In-Reply-To: <7B0B2AA4-5178-4C0F-BB7B-869CB7FC29AC@netgate.com> References: <43560B6A.4070505@mikulas.com> <20051019091559.GA45009@heff.fud.org.nz> <43565782.8080706@nortel.com> <D89799D0-71A2-45FC-8AF5-9C1902FFF5F1@netgate.com> <7B0B2AA4-5178-4C0F-BB7B-869CB7FC29AC@netgate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4357AEE4.7050503>