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