Re: ath client bridge

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.