Re: ath client bridge

Jim Thompson wrote:
> 
> 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.

Right, I ran into problems here when porting if_bridge to DragonFly. Needed
to make a small tweak in ieee80211_encap as it was using the eth_header to
populate the addr2 field, instead of using my_addr.

> 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).

Agreed.

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

SA I'm guessing. (Only one second of thought though :)). You'd  treat
SA like a layer2 gateway.

I'm porting ETHERIP from OpenBSD (appears to be working, sort of, not well tested),
and have that tied in to gif, and have gif support tied into my hacked if_bridge.

That sort of does what I want. I set up a gif tunnel between my AP and my client.
Then on the client, bridge the gif with the local 100bt nic. Only niggly thing is
the extra packet overhead required by ETHERIP.


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

Thanks. My answer was based on just snoopinig around in the net80211 source
code - the only usages I found of ieee80211_frame_addr4 were in crypto_ccmp and
crypto_tkip.

> 
>>
>> 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.

Makes sense. Thought there might be more to it than that, for instance AP's
tracking/coordinating with other AP's with the same ssid and channel. But
I really haven't looked at it, to be completely honest. :)

I know that when I put my laptop in AP mode (same channel and ssid as my master
AP), on the laptop, I stop hearing packets coming from my master AP.


Andrew.