If i look to this: http://wiki.mikrotik.com/wiki/Wireless_repeater
It is not clear to me
interface wireless wds add disabled=no wds-address=XX:XX:XX:XX:XX:X2 master-interface=wlan1
What should I fill in at XX: XX: XX: XX: XX: XX What Mac address ? by main gateway
I think that more people it not understand
I fully agree. It is not really easy to understand or to adapt to a slightly different setup where people just have 2 or 3 access points (which I guess is much more common than dedicated repeaters).
Zap.
Hello plisken,
I was just reading through the wiki page for HWMP+ and came across the syntax you describe.
In the example setup on the HWMP+ page, they describe the setup as follows
# a static WDS interface for each AP you want to connect to
/interface wireless wds add disabled=no master-interface=wlan1 name=<descriptive name of remote end> \
wds-address=<MAC address of remote end>
I think this will help to explain what MAC address is needed.
Thanks for your repley but i don’t understand what you mean.
The MAC addresses are the from de main repeater or so?
I’m not an expert on this but I think you need to set it up on each device. I believe the syntax shown above is just to setup a static ads link rather than a dynamic one.
Maybe you can use dynamic mesh here to make things easy.
Everything seems to be solved guys! Thanks alot for your help!
Have a look at Setup question for WLAN repeater.
Zap.
I wrote a little howto about WDS repeater configuration, which can be found here:
RouterOS WDS Repeater Configuration Guide.
Zap.
Is repeater now working ?
In general it is working but I still have the problem, that sometimes the repeater goes into some kind of loop and reports:
… disconnected, management-protection failure
… connected, is AP, wants WDS
or
… disconnected, no beacons received
… connected, is AP, wants WDS
over and over again.
As soon as I use the “Scanner” button in Wireless/Interfaces, everything goes back to normal.
I have no real idea how to fix this at the moment. 
Zap.
This is not yet well supported i think. I hope that Mikrotik comes with a solution.
I have the same behavior. I have 5 APs in a HWMP mesh. For a couple of days it’s OK and then all APs enter the same loop as you have. Reboot usually solves things.
Did you manage to find something out about this?
Hi,
I talked to MikroTik support and they advised to set the distance to “indoors”.
/interface wireless distance=indoors
and since then everything seems to be fine.
Zap.
Well Hell, that should have been obvious to everyone! The next time this critical link in our network decides to come back up and i can reach the device at the other end, I’ll be sure to give that entirely non-random incantation a try. 
How can you release software with as fundamental a feature as bridge/dynamic mesh mode simply failing whenever it feels like it, and even rebooting doesn’t clear it up?! These bogus “management protection failure” messages are really ticking me off–not to mention my customers, who don’t appreciate being offline for 20 minutes at a time until these outages decide they have had enough fun for a while. While the link is down, NOTHING that I do makes a bit of difference: running a scan, connecting as a station bridge then going back to bridge mode, disabling and enabling the interface, leaving it off for a while, rebooting the RB, even disabling management protection.. The radios simply refuse to talk to each other for a while, and then without warning they go back to working again–sometimes for several days, sometimes for only a few minutes. But if you change anything in the radio’s settings, the connection drops again, and stays dropped until the stars align themselves again.
This is supposed to be technology, not magic.
I’m running 6.7, and don’t plan to install any more “upgrades” until I hear that this one has been banished–preferably without having to change obscure settings.
BTW, who do we have to bribe to get an explanation of what the letters along the left column of the wireless “Scanner” window signify? In ROS 6.7, most of the radios in my network have “APRWB”. One has just “PRWB”. They all display the radio name, and all but one displays the ROS version.
The one that is not displaying a ROS version is the radio that is having connection problems. (In fact, at this point it is behaving as though there were no radio at the other end, despite a very good signal according to the scan). Moreover, the letters next to that radio are “ART”–it’s the only one in the scan list with a “T”.
So it this solution stable? Is it working for you? No more loops?
It did nothing for my situation. The only way I have found thus far to stabilize that link–and it is rock-solid because, when it does drop, the script that disables and re-enables the interface works the first time–is to run 5.26 at both ends. Admittedly, I haven’t tested this link with 6.13 yet–but for the moment I am enjoying a reliable connection with practically zero down-time, and so are my clients.
The only theory I have left is that it has to do with the 0-chain having a very poor signal compared to the 1-chain (dual-polarized link over water). Maybe some code was rewritten between 5.x and 6.x that no longer handles that condition gracefully?