Scanner connected via media-bridge (RT-N66R) loosing connection to local computers

[StR]

I have a problem that my network scanner (connected via RT-N66R in media-bridge mode to RT-AC86U) is loosing connection to/visibility of the local computers.
Before it was connected via media-bridge, it was not a problem.

Here is the configuration I have:
Phaser 3300MFP is the network scanner that can scan directly to the computer on the local network. You just choose the "Network scan" from the unit control panel, and choose the desired computer (entering its access code). For this the scanner needs to "see" the computers available locally (on the same subnet). The computers (Windows) are running a small piece of software that is listening and that also allows configuring scanner defaults.

Previously, I had RT-N66R (with the last Merlin firmware on it), and the scanner connected to it via Ethernet was able to see all the computers most of the time just fine. Sometimes, I had to restart the scanner. I suspect somehow discovery is based on the Windows-based mechanisms.

Recently, I've replaced RT-N66R with RT-AC86U as the main router, and RT-N66R was reconfigured to a media bridge, - to provide the connectivity for this printer/scanner, and some desktops -all connected via ethernet.
What I've noticed is that in order for the scanner to see the computers that are not connected directly to RT-N66R, - I need to force re-establishing a connection from the computer side (there is a button "refresh device" in that resident program). - This is a bit annoying.

I am trying to figure out
1) What is causing this behavior and
2) If anything can be done in the configuration (of either RT-N66R or RT-AC86U) that would keep this connection (visibility) alive.

I do not know what allows the scanner to "see" the computers: whether it is a "keep-alive" connection of some sort, or p-n-p type of discovery. So, if someone knows the mechanism, or has some pointers, - that would be appreciated too.

 

[eibgrad]

Since no one else seems to be stepping up, I'll take a crack at it.

Short answer:

Here's my *best* pointer; use powerline or MOCA instead if that's what it takes to avoid wireless.

Long answer:

I'm assuming Media Bridge mode does NOT use WDS, but the more classic wireless ethernet bridge mode.

The problem w/ a classic wireless ethernet bridge is it's just a hack (and its true of *all* firmware, regardless of source). It's not a real bridge in the same sense that WDS is. And as such, it often suffers from connectivity issues, esp. when you want to reach a device behind the bridge from the wireless side of that bridge (which seems to be the case here). If it wasn't for that fact that WDS is NOT a wifi standard and therefore commonly suffers from compatibility issues (not unless you have nearly identical hardware and firmware), it would make more sense to embrace WDS than a wireless ethernet bridge in this instance it's far more reliable when it comes to these kinds of connectivity issues, esp. network discovery.

Case and point. I'm presently using a FT (FreshTomato) client bridge between my office PC and the primary router. And I recently placed my Chromecast TVs on a separate IOT network. Then used Avahi to proxy network discovery between that IOT network and the private network (where all the clients of those Chromecast TVs typically reside).

Avahi Tutorial: Configuring a Reflector (aka, mDNS repeater)

UPDATE (11/14/2020): Significant changes have recently been made to Entware generally, and the Avahi packages specifically, that have required me to make updates to this document. It reflects the latest information and experiences I've had installing and configuring Avahi on FT (FreshTomato)...

www.linksysinfo.org

It all works fine *except* for my office PC. Because it's behind a wireless ethernet bridge, network discovery can't reach it, despite the use of Avahi. However, if I merely change the wireless connection to WDS, now it works fine. And the lesson learned? All wireless bridges are NOT created equal!

The only reason I continue to use wireless ethernet bridge (despite this problem) is that, at least for me, the performance of WDS is abysmal (dropping from 225Mbps w/ wireless ethernet bridge to as little as 9-10Mbps w/ WDS). I have no idea why. And for all I know it's unique to my setup for some unknown reason. But for the purposes of say a printer or scanner, that probably doesn't matter. Neither requires all that much bandwidth anyway.

Truth be told, neither the classic wireless ethernet bridge nor WDS are anything to write home about. Each suffers from its own set of issues, and which makes the most sense will vary from situation to situation. In many cases, neither is up to the task.

This is just another example of why wireless, as much convenience as it adds to modern life, sucks in so many ways, and is best avoided whenever possible.

 

[StR]

Thank you for your detailed response.
It gives some food for thought.

I've never used WDS, and this is my first experience with the media bridge mode.

The reason I've chosen media bridge mode over others is that it does not seem to be wasting the useful bandwidth. In my case it is not just the MFP printer/scanner that is connected via ethernet, but also a couple of desktops, one of which is used as a local disk server (via network-shared drive). So, it would be best to avoid halving its potential bandwidth.

The drastic loss of the effective bandwidth in WDS mode in your case is frightening and discouraging!

As for network discovery, in this particular case, I do not have multiple private networks, so I was hoping that there is some setting that might be responsible for it (i.e. allowing it), - without installing any additional scripts.

 

[eibgrad]

As for network discovery, in this particular case, I do not have multiple private networks, so I was hoping that there is some setting that might be responsible for it (i.e. allowing it), - without installing any additional scripts.

The problem w/ my client bridge is NOT related to having multiple networks per se. My Chromecast-enabled TVs *are* on a separate IOT network, and I can access them from the private network thanks to Avahi. And since my client bridge is bridged to the same private network, it and any devices behind it *should* likewise have access to the Chromcast-enabled TVs. But they don't. Not when using a classic wireless ethernet bridge. Network discovery can NOT make it through the bridge, even though both sides of the bridge are on the same private network! It's only once I switch to a WDS bridge that network discovery finally gets through the bridge, and the Chromecast-enabled TVs become accessible across it.

Now whether this explains what's happening in your case, I don't know for sure. My point is, all wireless bridging solutions are problematic. Not unless you are dealing w/ a complete system from a single vendor who *guarantees* WDS compatibility across its entire product line (e.g., Ubiquiti). But once you start mixing and matching consumer grade equipment, OEM and third-party firmware, etc., things quickly get messy, and unreliable, particularly when it comes to wireless bridging. So when I hear about problems like yours, it doesn't surprise me. I've heard similar complaints for years. And I don't know of any magic bullets. And that's why my best recommend is to NOT use wireless if you can avoid it.

I wish I had better news. Maybe someone else has other ideas.