Re: ath client bridge

On Oct 19, 2005, at 4:26 AM, Andrew Atrens wrote:

> Andrew Thompson wrote:
>
>> On Wed, Oct 19, 2005 at 11:01:30AM +0200, Jiri Mikulas wrote:
>>
>>> Hello
>>> I have problem to setup bridging box with ath in client mode and  
>>> if_bridge
>>> When card is in AP mode, everything is ok, but if I want to run  
>>> card in
>>> client mode, bridging is not working.
>>> Here are my testing steps: (it's quite long, so I prefer put URL  
>>> there :) )
>>>
>> Bridging on the client side of a wireless connection is not supported
>> and has to do with the 801.11 frame format. The problem is that the
>> client only registers its own MAC address with the AP, so the bridged
>> clients do not get a reply (as far as I understand).
>>
>
> Yah, the 802.11 header only has room for three addresses.
>
> The AP uses them as -
>
> ssid
> src
> dest
>
> (in this case src is the *real* src of the packet hence the AP  
> itself can bridge)
>
> The client uses -
>
> ssid
> src
> dest
>
> (in this case src *must* be the client mac, hence the client can't  
> bridge packets
>  from other macs)

The use of addr1, addr2 and addr3 is dependent on the settings for  
FromDS and ToDS (two bits in the "Frame Control" bitfield in the  
header).

addr1 is always the recipient address (the station on the BSS that is  
the immediate recipient of this frame.   If ToDS is set, this is the  
address of the AP.  If ToDS is not set, then this is the address of  
the end station (can be a group (broadcast/multicate) address as well).

addr2 is always the transmitter address (the MAC address of the  
station that is physically transmitting the packet onto the wireless  
medium).  If FromDS is set, this is the address of the AP, FromDS is  
not set, this is the address of the station.

addr3 is the 'missing' address.  If FromDS is set, then addr3 is the  
original source address of the frame (may be a machine behind the  
AP).  If ToDS is set, then addr3 is the destination address

If both FromDS and ToDS are set, then you use addr4, such that you've  
got the complete set of MACs that are the transmitter and receiver on  
the wireless medium (part of this BSS) and the actual source and  
destination Ethernet addresses (which are likely both outside the BSS).

FromDS    ToDS    addr1    addr2    addr3    addr4
      0                0          DA         SA       BSSID     X
      1                0          DA      BSSID       SA        X
      0                1        BSSID     SA          DA        X
      1                1          RA          TA          DA      SA

Also, there is a (huge) difference between 802.11's BSSID and its  
ESSID, so I've not used (your) "ssid" in the above.

In an IBSS (which has no distribution system), the FromDS/ToDS bits  
aren't set because the frames are always sent from
one station to another. Management and control frames don't have the  
FromDS/ToDS bits set, either.


The actual issue is that unless you use the 4-address format, you  
either don't know one of the actual endpoints, or you don't know  
where to ACK the packet.   One of the essentially unwritten rules of  
the 802.11 MAC is that you always ACK addr2 (unless you don't ACK  
that kind of frame, of course).

Now, answer this question: Where do you send the ACKs when SA != TA?

>
> There is a four address version of the packet header, but as I  
> recall the fourth
> address is used by TKIP.

nope.

>
> So it's a problem with 802.11 standard. I think that's why they  
> came up with WDS.
> I think there's some support for WDS in MadWiFi, but not yet in the  
> BSD stack(s).

As the term is commonly used, WDS *is* the 4-address frame format.

Jim