I am working with a test lab where I don't have ethernet-cable connectivity; I only have wifi.
The main (edge) router of the test lab is a hEX router. On the hEX's ether2 will be an AP; ether3 another AP; ether4 will be a PC.
The goal is for the:
Devices on the main wifi network to see the hEX and the devices behind the hEX; and,
The hEX and the devices behind the hEX can see all the wifi devices and have access to the Internet.
A bonus would be if the hEX could get an IP address from the wifi network's DHCP server.
My idea is to connect a cAP to Ether1 (WAN) of the hEX and use STATION mode so the cAP becomes a layer 2 bridge between the hEX router and the main wifi network.
This cAP will connect (via wifi) to SSID "guest," which is the Internet-connected main wifi provided by a Ubiquity Unify LR7 AP. I don't care whether the cAP has a static IP or gets one from the wifi network's DHCP server.
My thinking is that if the cAP can behave as a L2 bridge, then all my needs will be satified (including Winbox neighbor discovery).
It doesn't seem to me like the referenced docs give you ANY hope.
Picked up for you:
Mode station
This is standard mode that does not support L2 bridging on station - attempts to put wireless interface in bridge will not produce expected results. On the other hand this mode can be considered the most efficient and therefore should be used if L2 bridging on station is not necessary - as in case of routed or MPLS switched network. This mode is supported for all wireless protocols.
...
Mode station-bridge
This mode works only with RouterOS APs and provides support for transparent protocol-independent L2 bridging on the station device. RouterOS AP accepts clients in station-bridge mode when enabled using bridge-mode parameter. In this mode, the AP maintains a forwarding table with information on which MAC addresses are reachable over which station device.
This mode is MikroTik proprietary and cannot be used to connect to other brands of devices.
This mode is safe to use for L2 bridging and is the preferred mode unless there are specific reasons to use station-wds mode. With station-bridge mode, it is not possible to connect to CAPsMAN controlled CAP.
Simplified:
station = NO L2 bridging
station-bridge = L2 bridging BUT ONLY if devices involved are Mikrotik.
If you want an explanation, the standard (802.11) omits a way to do L2 bridging over wifi, so each and every manufacturer has developed an own protocol that is not compatible with the others.
From the wireless connection point of view, this mode is the same as standard station mode. It has limited support for L2 bridging by means of some services implemented in station:
MAC address translation for IPv4 packets - station maintains IPv4-to-MAC mapping table and replaces source MAC address with its own address when sending frame to AP (in order to be able to use 3 address frame format), and replaces destination MAC address with address from mapping table for frames received from AP. IPv4-to-MAC mappings are built also for VLAN encapsulated frames.
single MAC address translation for the rest of protocols - station learns source MAC address from first forwarded non-IPv4 frame and uses it as default for reverse translation - this MAC address is used to replace destination MAC address for frames received from AP if IPv4-to-MAC mapping can not be performed (e.g. - non-IPv4 frame or missing mapping).
This mode is limited to complete L2 bridging of data to single device connected to station (by means of single MAC address translation) and some support for IPv4 frame bridging - bridging of non-IP protocols to more than one device will not work. Also MAC address translation limits access to station device from AP side to IPv4 based access - the rest of protocols will be translated by single MAC address translation and will not be received by station itself.
This mode is available for all protocols except nv2 and should be avoided when possible. The usage of this mode can only be justified if AP does not support better mode for L2 bridging (e.g. when non-RouterOS AP is used) or if only one end-user device must be connected to network by means of station device.
Hmmm, it's not that strange or unusual as a concept.
If you want lemonade, you need some lemons to begin with.
If all you have are cucumbers, at the most you will be able to make some cucumbers juice.
You may well be happy (or pretend to be happy) drinking your fresh cucumber juice, still it won't be lemonade.
I'm not an expert at linux or ROS, but I've spent quite a while exploring/researching this and I don't see a straightforward way to create a L2 bridge with 1 wifi and 1 ethernet port.
Ok, now I lost you.
A L2 bridge between wifi and ethernet Is the most common setting/setup.
The problem is L2 bridge over wifi.
Search for posts by bpwl with the keyword "4 address" and/or "pseudobridge" he often explained how the station, station pseudobridge, etc. work, they may help you understand the matter.
You will find that in your case there Is a workaround (or a "crutch" as someone defined It) consisting in putting the bridges on both sides into a tunnel (like EOIP), example:
The main environment's AP is a Unify LR7, and I can't start messing with it.
I was hoping for a simple solutions.
Thank you for clarifying for me that the L2 bridge between the cAP's wifi and ethernet interfaces is not the problem; rather, making an L2 bridge between the cAP and the main AP (with wifi being the hardware/link level connection) being the problem.
Well, I couldn't literally translate "volo pindarico"...
Anyway, if you have TWO MikroTik peripherals, one on the other end of the AP, you can do, among other things,
an EoIP if it simulates a cable between the front of the AP and the back on the hEX, so the L2 passes...
When you have a MikroTik central router and a MikroTik device you want to connect via another manufacturer's WiFi device you can still have L2 bridge functionality when you configure one of the L2 tunneling protocols between the MikroTik devices!
Of course it will be less efficient. It will depend on the chosen protocol (and its parameters) whether you still have the full 1500 byte MTU, too.
