ath client bridge
Andrew Atrens
atrens at nortel.com
Thu Oct 20 07:51:53 PDT 2005
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.
More information about the freebsd-current
mailing list