Unable to use AC66_B1/AC68 U as a reliable media bridge (solved)

[Gedeon30]

Hi.

Last week the ISP upgraded the router to an AC version so I've put the AC66_B1 to work as media bridge.

I attached to it two 1Gbit nodes (Linux Nas ITX J3455 and Zidoo TV box) and two 100Mbits (receiver and Smart TV)

When there is some "serious" burst or traffic from the PC NAS, even the internet radio is cut/lost.

I tried with an older TPLink 841 (limited to 300N and 100mbit Ethernet) with zero issues. Zero. But with the Asus.... I really feel a bit stupid...

I did a clean install and tested Merlin and stock Firmware with no luck. Connections are lost, dropped, ... each few minutes ..

It seems that Asus router get some bug, issue or buffer problem with ethernet clients when more than one node/flow is in use. But no serious idea of what's the real cause.

If some one has found a reliable config / firmware to make this combination to work It'll be very welcomed.

Thanks in advance !

 

[JDB]

Media bridge is definitely broken, there are various threads reporting similar to you.
I did A LOT of deep packet inspection and wrote various scripts to try and help it recover quicker etc (as at the time I needed a media bridge). I reached the point where 99% of the time I didn’t have to intervene and stuff did work, but it was never perfect.
The problem is with Asus (not Merlin), and they don’t seem to want to fix it, I guess as media bridge mode is not widely used.
In the end I switched to using an AiMesh arrangement which solved all my issues. It’s frustrating that Asus won’t fix the media bridge mode though.


Sent from my iPhone using Tapatalk

 

[Gedeon30]

Thanks a lot for the sad confirmation.

I'll still try a few more configs but definitely out my plans to buy any ASUS product anymore.
/rant on
This isn't an ultra cheap piece of junk. I understand I can't expect the performance or features of higher priced products but at least a reliable and stable behaviour in domestic networks should be the bare minimum.
rant off/

 

[agilani]

I don't think jdb is using the features. I have been using two ac68 repeaters/bridges connected to an ac88 without problems. They both get full internet download speeds (240mb/s) without any errors.

Did you disable smart connect
disable beamforming
disable mimo
disable airtime fairness

use different ssid for 2.4 and 5ghz for the router
assign static ip address to the repeater/bridge that does not conflict with the router
use different ssid for 2.4 and 5ghz for the repeater/bridge
Setup 5ghz for 20/40/80 bandwidth (auto)
use a solid 5ghz channel for backhaul

i say repeater/bridge because the only real different between the two is repeater uses the wireless radio on the remote device where bridge is only wired. Let me know if you need more help.

 

[JDB]

Respectfully agilani I was using bridge mode exactly as the OP describes!
You are taking about repeater mode as well which works very differently as the packets never leave the wireless interface; just jump client<>server side of the equation, so the L2 route is much simpler within the device (repeaters also often spoof/mask MAC addresses of their clients making it a totally different setup).

The problem with bridge mode related to broadcast traffic, so if you only/primarily use unicast traffic you will not notice a problem. But as MANY devices (mainly media steaming type things) use multicast/broadcast traffic it’s easy to run into the problem, as I, the OP and MANY others have!

When the bridge ‘breaks’, broadcast traffic stops traversing wireless<>wired, meanwhile unicast keeps working. The solution is to bounce the wireless client of the bridge<>router and then it starts working again - but obviously this is not a proper solution!
Based on this, I’m quite sure the basic L2 switching ability of the bridge has a bug, presumably triggered by some packet type that it doesn’t like.


Sent from my iPhone using Tapatalk

 

[Gedeon30]

I've done a few more tests, not as many as JDB, obviously, but I fully agree with their conclusions. The Asus and the Ethernet clients already have fixed ip configs.

In my observations, If you only have "one" data flow… I mean, one Ethernet client making use of the wireless bridge, the Asus can work well. However just switching on another Ethernet client which demands connections making use of the wireless something inside the router level 2 bridge just breaks and connections are dropped lost.

@JDB... Could you be so kind to send/show us how did you semi-fix this issue ? Maybe latest firmware releases with your "restoring" scripts could help, at least, to get a semi-stable config. I don't mind if latency, buffers or CPU use are increased... If I could just get a slightly reliable config...

Thanks !

 

[JDB]

This post has the script I wrote in it;
https://www.snbforums.com/threads/rt-ac5300-x2-wi-fi-bridging-issue.37553/#post-363022

There are various others that have found rebooting every 24h helps; it did help a bit for me, but not much. Loads of threads in this search;
https://www.google.co.uk/search?q=a...ript&ie=UTF-8&oe=UTF-8&hl=en-gb&client=safari


Sent from my iPhone using Tapatalk

 

[Gedeon30]

Thank you very much.

I'll perform several tests in next days and I'll share my experiences in this thread.

Thanks again!

 

[agilani]

@JDB
Apologies, no disrespect intended

I do have every wired port of my repeaters working at the same time along with wireless devices homed to the repeater wireless radio and then being backhauled via 5ghz wireless. Now most of my devices are unicast. I do have multicast devices working as well. IGMP snooping is enable on the router. Since the repeater is running in repeater/bridge mode. For the most part it acts as a layer 2 switch.

 

[JDB]

@JDB
Apologies, no disrespect intended

I do have every wired port of my repeaters working at the same time along with wireless devices homed to the repeater wireless radio and then being backhauled via 5ghz wireless. Now most of my devices are unicast. I do have multicast devices working as well. IGMP snooping is enable on the router. Since the repeater is running in repeater/bridge mode. For the most part it acts as a layer 2 switch.

The problems do not appear in repeater mode (even with wired devices attached), only in media bridge mode.


Sent from my iPhone using Tapatalk

 

[Gedeon30]

(I'd did some test in repeater mode and the problem was still there)

At this point I'd like to test older firmware (like 374 LTS, or even DD-WRT) however I'm unable to "downgrade" the firmware.

Not only the router blocks my intents to load older firmware but resetting it trying to trigger the emergency mode doesn't work anymore… it just enables the "first config" pages... the Asus restoring firmware utility doesn't seem to work neither...

Any idea how to load alternative firmwares ?? (AC66_B1)

Thanks !

 

[john9527]

@Gedeon30

If you are using 384.7 code, I recently did a couple of fixes for someone else using media bridge.
You could try the 384.7_2test3 code from
https://1drv.ms/f/s!Ainhp1nBLzMJghJlb7j1wnqac97q

 

[Gedeon30]

@john9527

Thanks a lot for the link and the build. I've started to testing it but sadly without luck. I've done a new reset to start a totally fresh setup and I'll try a few configs.

Like @JBD stated, it could be due to multicast traffic. It seems that my Linux, due to TeamViewer or to minidlna/upnp, just generates some multicast traffic which creates some kind of "flooding" or "broadcast storm" which just freezes the router for a few seconds or even totally so a hard reboot is needed.

Still doing tests...

 

[john9527]

Like @JBD stated, it could be due to multicast traffic. It seems that my Linux, due to TeamViewer or to minidlna/upnp, just generates some multicast traffic which creates some kind of "flooding" or "broadcast storm" which just freezes the router for a few seconds or even totally so a hard reboot is needed.

Known problem with Android 8.1 (maybe 8.0) and above. Do you have any Android phones?
Only hope is a fix from Google.

 

[Gedeon30]

No, I don't. But there have been some issues with "Sonos" (though I have HEOS and DLNA) networks and TeamViewer in other setups, with this kind of router.

Which frustrates me is that the WDS link with the old TpLink wrt841 works flawlessly…

I think some Asus driver/routine/…. just overflows or is unable to deal with multicast properly.

I'll do some tests in repeater mode before trying bride.

 

[loveleeyoungae]

Known problem with Android 8.1 (maybe 8.0) and above. Do you have any Android phones?
Only hope is a fix from Google.

Is the fix mentioned in this FAQ for the Android bug?

I feel this is a serious issue, but its strange that Asus team haven't noticed it?

 

[Gedeon30]

After a bunch tests I finally got it working using the repeater mode as @JDB and @agilani suggested.

High chances my first tests in repeater mode went bad due to some mistakes in the config.

Now I'm using @john9527 suggested firmware.

Good enough for me at this moment. Speed is pretty good and not a single issue or drop for the last 12 hours (I left two pings running all night without a single packect lost).


I used the hidden config pages (in repeater mode some pages aren't available) to "hide" the replicated SSIDs copied from the main router. So clients now only "see" the broadcasted ones from the ISP router.

Not sure if the following ones are needed, but I also set the STP on, the IGMP options on (snooping and proxy) and enabled the IPTV DHCP compatibily (Microsoft&RFC).

The only "minor" issue is that some upnp discovering packets don't seem to cross the router through the lan ports but it isn't a problem (maybe I'll try other settings: IGMP, STP.. but not today..).

To add more info.

In repeater mode the log shows how internal bridge forwarding rules are applied, however in media bridge mode usally you can see some blocks of several lines warning about: kernel: br0: received packet on eth1 with own address as source address. In repeater mode not a single one of these raises in the log.

In media bridge mode, enabling EMF stats in br0, I could see how the "flood" counter increased each time the connections were lost. Meanwhile in repeater mode the EMF stats didn't detect any multicast flood. It seems clear that some enabled mechanics in repeater mode block that multicast broadcast storms or it's the bridge mode itself which triggers those broadcast storm under certain circumstances.

In any case thanks to everyone!

 

[Bort]

I've also been having the same issues. Loaded up John's test firmware and changed to repeater mode. I see this message in the logs being generated every 30 seconds:

rc_service: watchdog 261:notify_rc start_dnsmasq

 

[Gedeon30]

You are right I get that message too. I still haven't put time trying to solve it.

 

[Bort]

It doesn't seem to affect stability so far. I have an hdhomerun wired to it. I'll let it run for a few days and see if it's stable.