On Sun, Dec 1, 2024 at 2:32 PM Ted Mittelstaedt <[email protected]> wrote: > > > Until recent kernels, Broadcom has supported client-bridging in it's wifi > binary blob drivers. THAT is why historically dd-wrt has been so solid with > client bridging - since it happens in the driver layer, not in the kernel or > userspace. I can understand why, if you only have used OpenWRT, that you are > so down on client wifi bridges. [...]
Normal infrastructure mode wifi (AP and clients) only uses three mac addresses in the frame header. When a client sends a frame, there is a MAC address for the AP and the MAC address for the destination, and the source and station MAC are conflated. When the AP sends back to the station, it ONLY knows that conflated MAC address. If the destination is really somewhere behind the station, it never gets there. That is fundamentally why client bridging is a hack. WDS uses 4 MAC addresses in the frame and works, but the AP needs to be "in on it". That is all baked into the 802.11 standard. So, client bridging involves playing tricks with MAC addresses, A frame arrives on the client wifi MAC address, but ... what is its real destination? The client bridge doesn't really know. The hacks involve guessing, and that guessing ultimately breaks something. -- Russell Senior [email protected]
