the last time I posted this comment (I saved it so I didn’t have to write it again), the post was deleted…
RE: bridging station to ethernet…
…you can’t do it due to limitations of 802.11, yet I can go buy a dozen other products that can do it, and they are all 802.11. so Im forced to use WDS and bridge traffic at the AP, which means that all clients on the AP see each other, regardless of the default forward option’s setting. This also means that any broadcast traffic on the AP, goes out to all clients connected. this increases un-necessary traffic as well as a reduction in security, MT has been very clear that this is because of the limitation of 802.11 that every other CPE manufacturer has figured out how to overcome besides MT , despite numerous requests from countless users, they still ignore those requests
i know how, they mac-nat it. if you’re looking for a real bridge for many machines then no, that isn’t a good solution, but if you’re only looking for a simple CPE that will give a user the ability to connect via PPPoE then a mac-nat solution is actually a better choice then a WDS bridge. all I want is the option to select WDS or MAC-NAT based on my specific needs at the time of installation. we don’t have that choice right now, we’re forced to use a full WDS bridge, which esposes customers to each other’s broadcast traffic.
Why don’t you assign out the customers /32s statically framed against radius? That plus PPPoE means even if the devices could see each other they are not particturally ‘vulnerable’ to broadcast packets.
bridge-filter on the CPE and pass on only the ethernet packet types that are relevant for PPPoE, then.
The simple fact is that WDS is the correct solution to the problem and it is already fully supported by RouterOS. So why would there be any need to implement a second, stripped-down workaround and have that linger in the code in parallel to the existing, correct WDS solution.
i understand your motivation. have you ever considered having the cpe doing the pppoe connections? that way you could potentially avoid path mtu issues and avoid wds. maybe there is something that speaks against this?
for about a nanosecond and then I rememebrd why we didn’t do it that way to begin with… the customer gets a public IP on their router or firewall… if I did the PPPoE on the CPE, then the customer would be NAT’d with a private IP, and then unable to manage their connection (port forwarding, firewall rules, etc) themselves.
bridge filters are a work around, and yes, I already use them, but it’s an extra step that can be messed up or forgotten by the installer, we can’t fully use them tower side because then we cant’t get into the CPE (it gets a private IP from DHCP on the tower which we use to connect to it for updates and troubleshooting)
the reality is that a full bridge is not the best solution in this case, a more restrictive less capable, and simpler system is actually better. WDS is wasting CPU overhead and is functionalaty overkill.
I’ve always felt the KISS (Keep It Simple Stupid) principle is a smart thing to follow. Using WDS with bridge filters for PPPoE traffic seems like the Rube Goldberg way of doing things. if you don’t know who that is…
Inspired by cartoonist Rube Goldberg, college students nationwide compete to design a machine that uses the most complex process to complete a simple task - put a stamp on an envelope, screw in a light bulb, make a cup of coffee - in 20 or more steps.