Bridge connects to Access Point AND Repeater in different ways

Hello, I have an issue where a device(group) connects to both the Access Point and the Repeater, but seems to connect to them differently. The result is that the connection is unusable every few mionutes for a few minutes. How can I block it from connecting to the Repeater? Or is there another solution?

Details:

My Access Point is a Turris Omnia, running the Turris version of OpenWRT.
I have a bridge (Linksys WES610N) that traditionally connects via WiFi to the Turris Access Point. My desktop computers (no Wifi) are connected via Ethernet to the bridge, which connects to the Turris Omnia via 5 GHz Wifi. So far so good.

Recently, I added a Repeater (TP-Link Archer AX23) running OpernWRT 23.05 to the network. It sits half a floor below.

Since that was added, the Linksys Bridge seems to connect to both the Access Point and the Repeater, albeit not in exactly the same way.

On my Turris device, I can see the Bridge (MAC address 98....A1) with its own IP address (192....28), and the desktop computer that sits behind the bridge (MAC address D8.....46, IP 192....49).
On the AX23 Repeater I can only see one device with the 192....49 IP address but not the MAC address of the desktop computer but the MAC address of the Bridge, except that it ends on A2 rather than A1.

What a mess.

From the point of view of the desktop user, the connection stops several times an hour for a few minutes, then works again, without the user taking any action.

How can I fix that?

Unfortunately, the Linksys Bridge has no setting to ensure that it only connects to a Wifi access point with a specific MAC address. Likewise, I have not found a setting in the OpenWRT interface where I could block specific MAC addresses from connecting to the Repeater (and I am not sure that would help, maybe the Bridge would just keep trying to connect to the repeater over and over).

It appears you are using firmware that is not from the official OpenWrt project.

When using forks/offshoots/vendor-specific builds that are "based on OpenWrt", there may be many differences compared to the official versions (hosted by OpenWrt.org). Some of these customizations may fundamentally change the way that OpenWrt works. You might need help from people with specific/specialized knowledge about the firmware you are using, so it is possible that advice you get here may not be useful.

You may find that the best options are:

  1. Install an official version of OpenWrt, if your device is supported (see https://firmware-selector.openwrt.org).
  2. Ask for help from the maintainer(s) or user community of the specific firmware that you are using.
  3. Provide the source code for the firmware so that users on this forum can understand how your firmware works (OpenWrt forum users are volunteers, so somebody might look at the code if they have time and are interested in your issue).

If you believe that this specific issue is common to generic/official OpenWrt and/or the maintainers of your build have indicated as such, please feel free to clarify.

on openwrt repeter if you have same essid as the other repeter/AP change that.

That would indeed be a solution, but then I wouldn't need the repeater in the first place. :slight_smile: It is there for seamless roaming, and it works fine, except with the Bridge.

Why would you think that?

As I said, the repeater runs on OpenWRT 23.05.

The rest worked fine, until I added that repeater. So that's where I would like to find a solution.

1 Like

No idea what you are seeing, openwrt in bridge mode is transparent to packets. What turris sends you get on desktop.

The Bridge is a Linksys WES610N and has been running with whatever Linksys propriety reduced to the max software fine for years. The Repeater (OpenWRT 23.05) is new, and now things are going awry.

Connect cable to turris where linksys is and check MAC.

I've already tried that, but the Linksys Bridge is WiFi only (for connection to a router). I can not connect it with a cable to a router/access point, only to end user devices.