WDS links not routing properly....

I am constructing my first WDS network, linking four total routers in a repeater-like chain, as shown in the following illustration:
Station-WDS — AP-bridge — AP-bridge — Station-WDS

I have set both interior APs as AP-bridge, and enabled dynamic mesh WDS on them, pointing to the local bridge interface (bridging wlan1 and ether ports). Similarly, the two end stations are set to Station-WDS, with same/similar settings. Bridge interfaces on all routers are on the same subnet.

Dynamic WDS links do get established automatically, but I cannot ping one bridge interface from one router to the other reliably. However, when I add a specific route for the next gateway (redundant with the subnet route) on a specific router (as shown in this review of the first link), it will work.

Attached are screen snapshots of the first link in this network, showing when I get no ping connection, and when I do after adding the gateway-specific route. We are looking at the first link in the chain.

Here, in this image of the first router, you can see packets leaving the router R1 for the ping target R2 But nothing coming back. Note the static route to the R2 bridge interface is disabled, and the dynamic route to the .88. subnet is active. On R2, no ping packets arrive from R1 (as seen via Firewall Log rules).

In image of the second router R2 pinging R1, you see a similar result - no ping connection.

But, when you look at R1 while being pinged by R2, you see that ping packets arrive and leave with the destination of R2 - but obviously don’t get there!

Here, I have enabled the ‘redundant’ gateway specif route on R1 to the bridge interface on R2 (tried the same trick on R2, but no effect), and you can see that now ping works from both directions. Here’s the view from R1:

… and here pinging from R2:




As I understand the manual and the illustrations of WDS networks there, I should be able to ping from any router to another to bridge interfaces on this common subnet (.88.), without having to ‘monkey’ with the routes. Clearly, something is amiss, and I have little confidence in this network until I get this resolved.

What do I have wrong here? The other links in this WDS repeater chain have similar issues…

Thanks in advance for the input…

“dynamic-mesh” is usually for use with mesh interfaces (/interface mesh) and HWMP+ configured inside the mesh interface itself.
If you use a normal bridge (/interface bridge), then try setting WDS mode to “dynamic”, and use (R)STP on the bridge.

You have “dynamic-mesh” but for default bridge you have a “/interface bridge” interface. Try switching your WDS mode to “dynamic” and see if that works.

Thanks you for taking the time to review this, Tomaskir.

In using ‘dynamic mesh’ I was following the Wiki example:
http://wiki.mikrotik.com/wiki/Wireless_WDS_Mesh
…which in Model 2 shows this use.

However, a different Wiki example uses the ‘dynamic’ mode, as you suggest:
http://wiki.mikrotik.com/wiki/Mesh_wds

One thing I did discover, is that the WDS function would/will create dynamic instances of the proper wireless port in each bridge (‘wlan1’ on the Station-WDS, and ‘wds1’ on the AP-bridge). And, when I removed the static ‘wlan1’ port from each bridge, the routers would ‘ping’ properly. Both of the examples I reference above use the static port assignment of the local ‘wlan1’ interface to the bridge - but it appears redundant with the router’s dynamic assignment in both cases (dynamic, and dynamic-mesh).

In particular, on the Station-WDS, the router’s attempts to create a dynamic port assignment of ‘wlan1’ would generate wireless debug log entries “failed to set bridge port for wlan1, reason: device already added as bridge port (60).” By the way, this happens in both ‘dynamic’ and ‘dynamic-mesh’ modes.

I do not know, but I assume some sort of bridge or WDS link tagging failed to properly associate (layman speculation).

On the AP-Bridge, the WDS function would create the dynamic bridge port ‘wds1’ as the ‘root port’ (and, of course, the dynamic interface as well). So, even though the static port ‘wlan1’ was assigned, there was apparently no conflict.

Tomaskir, I have changed the type to ‘dynamic’ as I agree with your assessment. However, I have now tested it both ways, and it appears to work either way.

Here’s the most frustrating part - I have ‘recreated’ both original configurations (no, I was not awake enough to generate a backup for restore), and now they route properly, without the ‘redundant’ route on R1!!! I did several reboots while I was originally working on this, so I would hope tables were rebuilt, but who knows…

I have no idea why it now works, but I concur with your ‘dynamic’ mode recommendation, and am also deleting the static ‘wlan1’ port assignment, as it appears redundant at best with the dynamic assignment of the WDS function, at at worse, is causing potential tag/route issues. Let me know if you think this is problematic.

I did not use Wireshark to look for tag and route details - not exactly sure how to use this or even if it’s possible on the wireless link between these routers - but that would probably have been of insightful if not conclusive use in resolving this ‘mystery.’

Tomaskir, if I can, here’s some Karma for your efforts. Thanks.

You should have the wlan1 and ether1 interfaces manually added to the “/interface bridge”, or “/interface mesh”. Dynamic WDS mode should then add the WDS interfaces themselves into the bridges. WDS itself should not assign the wlan1 interface to a bridge, only the WDS interfaces that get created by the WDS connections.
I personally would stick with just dynamic WDS mode. If it generates no issues, keep it like that. But you can create them statically and I dont personally see why it would cause issues. As you mention, its very strange that you cant replicate the problem.
But since WDS implementations are “propietary” to each vendor, looking what is actually in the wireless frames would be quite hard :slight_smile: