Given is an Apple Airport Express as the sweet solution (which needs a replacement because Apple has decided to kill this division). Sweet solution because it’s the only solution I know of that is capable of bridging Ethernet to Wifi independent from the chipset vendor.
The Airport is connected as a wireless client. It’s not using WDS in this mode. It’s possible to connect ethernet devices to it’s ethernet ports and you can connect a switch with even more ethernet devices connected to it. The whole constellation works transparent, it’s no addition hop in a trace. Devices on the ETH Ports of the Airport reach every device connected to the Wifi/Router and every network device can reach devices connected to the Airport.
Devices connected to the ethernet port receive their addresses via DHCP from the DHCP server of the existing Wifi. And I repeat: no WDS. The only limitation is: max 4-5 DHCP requesting devices retrieve an answer, every additional request is blocked. Setting static IPs allows much more devices.
Regarding MAC… The devices keep their addresses, they are not overwritten with the Airports MAC.
Apple calls this function ProxySTA (“Proxy Station”). I did not find any information about this outside the Apple universe – so I’m still curious what kind of Magic Apple is doing there.
And now comes the tricky part… Given is a wAP ac because this MikroTik stuff seems to be the most flexible in terms of configuration and is the only option left, I think (I would consider openwrt not as an option). I tried some configuration but all to no avail…
Apple sold ten thousands of these Airport boxes to people who had to solve exactly this problem. Apple killed the Airports and there is need for an alternative solution.
There are other devices which do the same thing. Basically, the way it works is by doing “NAT” on the MAC addresses of the wired ethernet devices so that they all appear to be the wireless station’s MAC address. I’m pretty sure that configuring a Mikrotik’s wireless interface as a pseudobridge is the way to do this, although others on the forum with more experience in this regard might have more to say on the subject.
I just know that Mikrotik devices can do the same thing as your Apple Airport. I use this tech at my own home to link in my wife’s desktop workstation, but the difference is that I’m using a pure-Mikrotik solution, so I can’t say that my own config would work “regardless of the chipset” of the wAP.
Worst case, if it didn’t, you could always configure a Mikrotik’s wireless interface as a NAT interface and put a private LAN behind it. (sort of an “upside-down” wireless router).
The equivalent mode on MIkrotik devices is called “station-pseudobridge”. It is basically a form address translation- MAC address translation in this case. No magic at all.
MikroTik can do that too, but it requires a MikroTik Access point. Or maybe it will work with some others too.
This mode is not in the 802.11 standard, it requires some extension.
Did you verify that or is it only what you experienced when using it on your own AP?
It may be that the Apple product has support for a couple of widely used AP types.
But it is not a generic function of 802.11 APs, if not operating in WDS mode.
So… Back to the topic… There seems to be nobody with an idea on how to solve this. It is what it is.
My next idea was… Why not use the wAP for all the Networks where it’s possible to do some changes to the routing to access devices connected to it.
But… That seems to be impossible… And – don’t get me wrong – this is a major problem when using cheap stuff. It always gets ya.
There is a Wiki-Page https://wiki.mikrotik.com/wiki/Connect_to_an_Available_Wireless_Network on how to connect a MikroTik-Device to a WiFi-Network. It’s from – attention! – 2012. Guess what? Yep. Not working – I can not see why this should have worked at all because there’s nothing said about bridging and no routing from ethernet to wlan. There are other manuals in the wiki which all have one important thing in common: outdated and not working.
Do you know of any working Wiki page on how to – first step – connect to an existing WiFi and allow devices connected to it’s ethernet port to access the uplink? The routing stuff is the second step.
That functionality was not available in 2012 but now it is.
In the Wireless screen there is a wizard “setup repeater” that will make a client and access point and connect them with a bridge.
In the dialog you enter the MAC address OR the SSID and the password of your existing access point.
I’ve just checked that page out. Guess what? It’s still perfectly valid! It does not talk about bridging because it describes how to setup an AP for routing (i.e. pretty standard CPE setup). It does not explicitly talk about routing either because IP forwarding is enabled by default (I guess not that many people are actually aware that you can turn that off; and, obviously, disabling IP forwarding on a router is a pretty exotic thing to do).
I can only guess why that didn’t work for you. One guess is that you simply omitted some essential parts of that how-to that you thought does not apply to your use-case- like setting up NAT on the wireless interface.
Let’s get to your original question. You were asking about setting up bridging, not routing, right? That page, while perfectly valid, won’t help you. If you are fine with routing- just follow that how-to again, making sure you don’t skip anything.
If you still insist on using bridging, you have to understand that there’s only two options available: WDS and station-pseudobridge. And that’s not a limitation of Mikrotik wireless implementation, but rather a fundamental limitation of the whole WiFi protocol stack.
Nobody seems to know what kind of magic Apple were using in their ProxySPA-capable devices. One possibility is what pe1chl suspected above- they developed several WDS implementation each compatible with some popular vendor implementation. Another possibility is that they implicitly initiated several virtual client connections from a single physical radio (one connection per connected ethernet device). In this case the number of connections they were capable of handling should have been limited, hence the limitation on the number of DHCP clients you mentioned.