What's new

RT-AC5300 x2 Wi-Fi Bridging Issue

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I use 2 88Us in wireless bridge mode and the bridge router drops out all the time and requires a physical reset to work again. Meanwhile the normal router works fine and never drops out. I know when it happens because if I go to the bridge router's IP address it's no longer accessible. Has been a problem for me for a few years now. It's probably just an issue with Asus routers in bridge mode.

This is closer to my experiences with media bridge mode as well.


I did find a ping keep-alive did help, but only one of the presented MAC's has an IP address (the br0 does not) so it only makes it 50% better...

I'm not sure what this means. What's "presented MAC"?

Definitely adds weight to my theory that the router was misbehaving and not just a simple ‘Media Bridge mode is naff’ equation.

I'm not sure how you came to this conclusion.


Though obviously I appreciate the time you've put into investigating this @JDB. I came from another thread where you linked to this one, and am intrigued because I have had some problems with media bridge mode.

My setup: AC3200 AP 5Ghz <-> AC68U MB 5Ghz (2.4Ghz off)

My connectivity dropouts are more like what @winb83 have described, at no regular intervals, so I'm not even sure if I'm seeing what you're seeing.
The symptoms:
  • on console, several hotplug events as if the wireless interface were disconnected then reconnected
  • all interfaces are up but none has an IP assigned
  • requires a soft reboot (from console), restarting just the wireless leads to all kinds of weird and still doesn't fix the issue
  • happens on an irregular schedule, could be several times a day or couple days without issue
I don't think an active background ping helps since I've had this dropout half-way through streaming a movie. I don't necessarily need to use this bridge as I only use it for testing purposes so I haven't really been trying to track this down. Let me know if you think of something or want me to try something to replicate your 2hr dropouts.
 
Can you provide more details on the SSID settings for each router. 2.4 and 5ghz. What are you using to backhaul the traffic? What happens if you run a continuous ping from the bridge router console to the internet default router?

Have you looked at the wireless settings? For some reason the routers leave roaming assistant enabled and will disconnect if the RSSI is lower than a certain threshold. If you are sharing the SSID between router and repeater/bridge. It could be disconnecting and reconnecting to the other repeater if you are sharing SSID's between your devices.

A sample configuration has been pretty stable in my setup:

ac88 with 2.4 SSID wifi1
ac88 with 5ghz SSID wifi2

ac68 repeater one connects back to ac88 on wifi2
ac68 repeater two connects back to ac88 on wifi2

Ac68 repeater one broadcasts wifi3 for 2.4ghz
ac68 repeater one broadcasts wifi4 for 5 ghz

ac68 repeater two broadcasts wifi 5 for 2.4 ghz
ac68 repeater two broadcast wifi 6 for 5ghz

Wired ports on all devices are used similar to bridge mode.

each an every single router is directly accessible via ssh and SSID and they all have their own static ip addresses that don't conflict.

Also set the channel on the core router manually so it does not conflict with anything.
And since these are repeaters, i set the 2.4ghz channels manually and disabled roaming assistant.
 
Last edited:
@kfp

2 hours is the minimum. I’m working on the theory that is the max ARP cache time.

All of your symptoms are the same as mine (before I put my script in). A ping helps a lot but is not a complete fix. I also have had it drop whilst streaming Netflix etc. I still get this once or twice a week even with my script rather than a couple of times a day.

The present MACs on the bridge are of the internal bridge (br0) which has no IP, and of the wireless interface it uses to connect to the router (ethX) which has the management IP assigned to it.

If you go on the router and look at the active wireless associations you’ll see them both appearing.


I’m moving house in July and not sure what setup I’m going to need there yet. But I’m certainly going to attempt to use Ethernet to connect any range extending router!


Sent from my iPhone using Tapatalk
 
Last edited:
I only experienced the problems over 2.4ghz wifi. Surprisingly wired connections and 5ghz were pretty solid. Over 2.4ghz wifi all i could describe it is a layer 2 meltdown. TCP reset, duplicate ack, slow throughput, dropped packets... I thought maybe it was a dhcp and/or arp issue and have spent countless hours looking at it. A reboot of the router would fix the problem, until it happened again.

Once i did the network capture and saw basic arp requests and replies weren't happening over 2.4ghz i looked at channel conflict and moved the channels around manually. Its been running pretty solid since then. I also found many of my amazon firestick devices are also broadcasting hidden ssid's on the same channel as what they connect to the router with so i moved all of those to a separate 2.4ghz ssid as well.

My current theory is that the new firmware does not calculate wireless interference or do any channel change after the router is rebooted.

You can always look at and the clear the arp cache via ssh if you want to test it out. Just bear in mind that the arp table should show the mac address of the repeater for the devices/ip addresses behind the repeater/bridge. Or even create a static arp entry for a short time while you are testing.
 
2 hours is the minimum. I’m working on the theory that is the max ARP cache time.

ARP cache doesn't live that long, you can check these values:

Code:
/proc/sys/net/ipv4/neigh/default/gc_interval
/proc/sys/net/ipv4/neigh/default/gc_stale_time
/proc/sys/net/ipv4/route/gc_interval
/proc/sys/net/ipv4/route/gc_timeout

The only value that is 2 hours (7200 seconds) is
Code:
/proc/sys/net/ipv4/tcp_keepalive_time

Though I'm not sure how that relates to the problems we're seeing yet.
Hope the move goes well! The more ethernet ports you can spread around your house the better :)


My current theory is that the new firmware does not calculate wireless interference or do any channel change after the router is rebooted.

If it's convenient for you you can try attaching a serial cable and see if you see the 'acsd' process doing channel scans and changes to the console, that's the process responsible for changing the channels automatically as you can see in its name 'Auto Channel Selection Daemon'.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top