RT-AC5300 x2 Wi-Fi Bridging Issue

[KonoSuba]

Current Network Setup:

Central Router - RT-AC5300
Wi-Fi 2.4GHz Media Bridge 01 - RT-AC66U
Wi-Fi 5GHz-1 Media Bridge 02 - RT-AC87U
Wi-Fi 5GHz-2 Media Bridge 03 - RT-AC5300 <-- Issue being discussed

*Each bridge is in a different room with similar RSSI

Problem Summary:

Bridge 03 has a networking reliability issue. I'm suspecting it is something networking-related on the Router, rather than Wi-Fi signal strength, since Bridge 03's RSSI is usually around -37dBm.

Problem Description:

I will describe this from the moment Router and Bridges are powered on. Initially, all Bridges successfully connect. After precisely 2 hours, as indicated by the "Access Time" in the Router's clients list, Bridge 03 disappears as a device in that list. Subsequently, from this point on I am unable to access Bridge 03's web-configuration page.

A computer connected to Bridge 03 via Ethernet therefore also looses it's network link. Very inconvenient when transferring to / from NAS or using remote desktop software on a phone / tablet device to control computer. Bridges 01 & 02 are not affected by this issue - their "Access Time" counters continue and they remain as visible devices on the clients list.

Attempted Ineffective Solutions:

1) Reboot Router - temporary fix until Bridge 03 reaches 2 hours access time again.
2) Restore Router & Bridge 03 to factory defaults; then re-setup
3) Flashing Firmwares - Tried latest stock ASUS & Merlin firmwares on both Router & Bridge 03
4) Wi-Fi Channels - Set Auto & Manual channels on Router
5) Wi-Fi Frequency - Connected Bridge 03 to Router's 2.4GHz, 5GHz-1 & 5GHz-2 broadcasts
6) Replacement Unit - Bridge 03 formally an RT-AC88U, replaced it with a RT-AC5300 to rule out defects
7) Pro Wi-Fi Settings - Experimented with professional settings, such as turning off MU-MIMO
8) Static IP - Normally use DHCP + Manual Assignments. Tried setting manual IP on Bridge 03 itself

Other things I noticed:

1) After 2 hours "Access Time" has passed, remote desktop software 'thinks' computer attached to Bridge 03 is on a different network, as indicated by a Satellite symbol, when its not. When this happens WoL doesn't work.
2) NAS box is attached by Ethernet to Router. It has Mac & Windows sharing enabled. Works well under MacOS majority of the time, though sometimes requires a 'Finder Relaunch' to show in sidebar. However doesn't appear as a computer in "My Network" section of Windows File Explorer. Typing "\\Server-Name\" doesn't work. Have to type "\\IP.Address\" to access NAS. All Windows computers on network affected by this. Separate unrelated Router DNS issue maybe?

Preferred Outcome:

When it works, prior to the 2 hour "Access Time" issue occurring, my RT-AC5300 <-> RT-AC5300 bridge works at near 90MB/s sequential transfer rate, almost equalling the 112MB/s limit I experience when using 1GbE over Cat6a cable.

If a solution can be found to make Bridge 03 reliably remain as a detected network device on the Router, beyond this 2 hour "Access Time" 'limit', then I would prefer to continue using Wi-Fi bridging. If not, the only other option I can see is to get an Ethernet cable fitted between the two rooms I'm currently trying to wirelessly bridge, which is a less than ideal solution.

My perplexed thought:

Bridge 01 (RT-AC66U, a 2012 device) and Bridge 02 (RT-AC87U, a 2014 device) seem to work flawlessly as Media Bridges, connecting to my RT-AC5300 Router. So why would a second RT-AC5300 (Bridge 03), also acting as a Media Bridge, be so unreliable? I mean they're the same chipset generation / same product model; it just doesn't make sense that there would be any Wi-Fi Media Bridging compatibility issue going on - which makes me think there is something networking-configuration related on the Router causing my problem. Aside from using the 5GHz-2 broadcast, the way I have configured Bridge 03 is exactly the same as Bridges 01 & 02. But as of now I've personally exhausted all possible solutions I can think of to resolve this.

Request:

Can anyone assist me in fixing this issue before I'm forced to return my second RT-AC5300 within the 30-day period as "no longer needed / wanted" and have to go the Ethernet cable fitting route instead?

Thanks ~

 

[JDB]

I am also having a problem with the AC5300 in Media Bridge mode.

I have an AC88U as my main router, and AC5300 using its 5Ghz-2 band as a Media Bridge.

As you say, after a while it and all Ethernet devices hanging off it are not reachable anymore. I don’t have the 2 hour access limit though, it seems random to me, anything from 1-24 hours.

The 88U is running Merlin 382.1, the AC5399 Merlin 380.68_4.
Long term I plan to swap the AC5300 into router mode and run the AC88U with the new AiMesh mode, however I’d really like it to work as is for now, save me reconfiguring everything unnecessarily!

Any solution ever found!?

 

[sfx2000]

Using RT-AC5300 as a media bridge is not the best use of this hardware, and as noted, the complexity around Broadcom's "Smart Connect" feature can complicate things there.

 

[JDB]

Using RT-AC5300 as a media bridge is not the best use of this hardware, and as noted, the complexity around Broadcom's "Smart Connect" feature can complicate things there.

Yea I’m thinking just bite the bullet and swap them around for now and the 88U become the bridge.
In theory smart connect has no impact, the 2 other bands show disabled on the AC5300, and the signal is plenty strong enough for the 88U to not try and steer it to the 2.4Ghz (which it should ignore anyway).

The Wi-fi association actually stays up the whole time. It’s like the WLAN<>LAN L2 Bridge just gives up on the AC5300 and you have the cycle the Wi-fi link to get it to allow traffic again.


Sent from my iPhone using Tapatalk

 

[JDB]

So I switched the devices round, so now AC5300 is Router running 380.68_4, AC88U is Media Bridge running 382.1_2. I now have much more similar to the OP.

After 2 hours of the bridge being connected, my Sky Q box (ethernet off the bridge) is no longer able to be found by its companion iOS app (5Ghz to Router). So it's like IGMP/Multicast is failing to work between router and bridge after 2 hours. I can still tx/rx normal IPv4 packets to the box.
It's worth noting I can still see my Apple TV for AirPlay as well (also eth off the bridge), but with all the possibilities of broadcasting availability (Bonjour/mDNS etc) it's likely the Sky Q box is using one the router/bridge doesn't like and Apple use one it does.

I am yet to see the total drop out I was having before (and the OP reported).

Right now I have all IGMP/Snooping/Proxy/Multicast options I can find enabled on the router and disabled on the bridge. I've tried a few variants (without any real logic) but nothing seems to make any difference, and with the long test window I'm losing patience!

One thing I have found which seems to kick it back into action is to do a 'wl -i eth3 deauthenticate 00:11:22:33:44:55' on the router for the Sky Q's Mac. So I've set cru to do this once every 2 hours - downside is if you happen to be streaming TV from the Sky Q box>iOS App at the time it kills the session, but I think I can live with that for now. When you do this the bridge prints to the log, I'm presuming the bridge is the issue (as I never saw this when everything was direct WiFi to the router) and this is resetting the problem;

Dec  3 00:37:03 kernel: dhd_bus_flow_ring_delete_request :Delete Pending
Dec  3 00:37:03 kernel: dhd_bus_flow_ring_delete_request :Delete Pending
Dec  3 00:37:03 kernel: deleting interface 'wl1.3' idx 3
Dec  3 00:37:03 kernel: CONSOLE: 046611.814 wl1: link down (wl1.3)
Dec  3 00:37:03 kernel: CONSOLE: 046611.826 dngl_finddev: slave 3 not found
Dec  3 00:37:03 kernel: CONSOLE: 046611.827 dngl_finddev: slave 3 not found
Dec  3 00:37:03 kernel: CONSOLE: 046612.093 pciedev_send_ltr:Giving up:0x302
Dec  3 00:37:06 kernel: Register interface [wl1.3]  MAC: 00:11:22:33:44:55
Dec  3 00:37:06 kernel: CONSOLE: 046615.093 pciedev_send_ltr:Giving up:0x302
Dec  3 00:37:07 kernel: CONSOLE: 046615.177 wl1: link up (wl1.3)
Dec  3 00:37:07 kernel: CONSOLE: 046615.182 flow_create : bitmap_size=512  maxitems=512
Dec  3 00:37:07 kernel: CONSOLE: 046615.183 wl1.3: wlc_send_bar: seq 0x1 tid 0

I'm going to run like this for a day and if everything remains accessible I'll park the issue, if not I'll go to enable every IGMP etc option I can find!! I guess I may also look at manually running 'snooper' on the bridge if I can't make it do so from the Web UI in Media Bridge mode. Failing that it'll be time to break out the tcpdumps!

Given it seems to happen bang on 2 hours, anyone (@RMerlin ?) have any idea what timer might be triggering it? I looked at all the timers in the Web GUI but none were 7200 seconds.

 

[JDB]

Right - I am slowly tracking this issue down!

It manifests itself in various ways, but it all boils down to broadcast messages not working. This includes basic ARP requests. What I don't understand is it seems like an issue with the router not forwarding them to the media bridge, but if that were true I'd have had this issue with any/all clients... So I can only assume the media bridge is dropping them before tcpdump can see them (really not sure how!).

Per my last, doing a deauthenticate on the Sky Q Box MAC Address will (sometimes) fix it. What seems far more reliable is deauthenticate on the Media Bridge's 2x MAC's (you see it's WiFi eth and br0 MAC associated).

I've also disabled IGMP Snooping/Proxy everywhere, and that has helped A LOT. The problem occurs far less often and appears to now be an 'all or nothing' whereas before I would lose multicast connectivity only to the Sky box regularly (and unicast to everything occasionally). I may take a hit on some extra multicast traffic in the network but I don't have enough for it to be performance affecting.

So, I've written a script which runs via cru on alternate minutes, odd for WiFi MAC of the bridge and even for the br0 MAC.
It clears the ARP table, check's if the MAC is currently associated, if it is it sends a test ping, if that fails then deauthenticate the mac, re-tests the ping after 30 seconds and then reports the outcome via email (assuming the first ping failed).

It's a proper hack but if this works the advantages outweigh this annoyance!

Anyway, I'm really hoping this fixes it! If it does I'll post the script in case it can help anyone else.

 

[JDB]

So this morning so far so good, and an interesting pattern. I got an email precisely every 2 hours, 9.47pm, 11.47pm, 01.47am etc saying it detected an outage and successfully fixed it. I didn't get one at 7.47am, but I suspect that is because I started streaming Peppa Pig from the Sky Q box to my phone (joy's of having a 2 yr old!) at about that time.

So as per the OP, there is DEFINITELY some 2 hour related issue with Router+Media Bridge setups - and it exists between the AC88U and AC5300 regardless of which way around they are in that setup, it also seems present in 380 and 382 branch.

I'm not going to sign it off just yet, give it another 24 hours, but I'm feeling positive this time!!

 

[JDB]

Ha - as I submitted the previous post I got an email, 8.47am, outage detected and fixed again. So it's switched to even hours - odd! Everything is still working though

 

[JDB]

So the script is working perfectly, not one dropout of connection to Sky or Apple TV

I had 1 incident of 9 minute outage to the bridge itself, no idea why but it didn't affect the connection to the ethernet devices hanging off it.

This solution is of no use if you want to run any services on the bridge itself (SAMBA shares etc). As every 2 minutes it'll get kicked for a second or two.

To get the email notifications to work I had already followed the Gmail instructions here https://github.com/RMerl/asuswrt-merlin/wiki/Sending-Email and then stole/edited that solution and functionised it in my script. If you want to use an alternate email solution from that link you can just replace the content of the sendEmail() function and edit it as required.

On the Router this is the script I added to /jffs/bin/

#! /bin/sh

# Usage: ./con_check <interface> <host> <mac>
# Will ping test the host if no response deauthenticate the mac from the interface

int=$1
host=$2
mac=$3

sendEmail()
{
FROM="<your@email"
AUTH="your@email"
PASS="your@password"
FROMNAME="your@routername"
TO="your@email"


echo "Subject: $FROMNAME Con Check for $host notification - $1" >/tmp/mail.txt
echo "From: <$FROM>" >> /tmp/mail.txt
echo "Date: `date -R`" >>/tmp/mail.txt
echo "" >>/tmp/mail.txt
echo "I have detected that $host ($mac) is not pingable" >>/tmp/mail.txt
echo "" >>/tmp/mail.txt
echo "Attempts to restore the connection have $1" >>/tmp/mail.txt
echo "" >>/tmp/mail.txt
echo "---- " >>/tmp/mail.txt
echo "Your friendly router." >>/tmp/mail.txt
echo "" >>/tmp/mail.txt

cat /tmp/mail.txt | sendmail -H"exec openssl s_client -quiet \
-CAfile /jffs/configs/Equifax_Secure_Certificate_Authority.pem \
-connect smtp.gmail.com:587 -tls1 -starttls smtp" \
-f"$FROM" \
-au"$AUTH" -ap"$PASS" $TO > /dev/null 2>&1

rm /tmp/mail.txt

}



if [ -z $int ] || [ -z $host ] || [ -z $mac ]; then
    echo "Usage: ./con_check <interface> <host> <mac>"
    echo "Will ping test the host if no response deauthenticate the mac from the interface"
    exit
fi

#Debug line to check it's running and with what ARG's
#echo "$0 $1 $2 $3 `date`" >> /tmp/conCheck.log

#Clear ARP table before we start
ip -s -s neigh flush all > /dev/null 2>&1

#Check if our target mac is even connected and give up if not
wl -i $int assoclist | grep -c $mac > /dev/null 2>&1

if [ $? -eq 0 ]; then
    #Can we ping the host? If we can do nothing!
    ping -c 1 -W 1 $host > /dev/null 2>&1

    if [ $? -ne 0 ]; then
        #Ping failed so kick the mac
        wl -i $int deauthenticate $mac > /dev/null 2>&1
        #Wait for it to re-connect
        sleep 50
        #See if it's now pingable? If it is report success, if not report failure
        ping -c 1 -W 1 $host > /dev/null 2>&1
        if [ $? -ne 0 ]; then
            echo "Connection Not Restored"
            sendEmail failed
        else
            echo "Connection Restored"
            #####sendEmail succeeded
        fi
    fi
fi

I originally had it emailing on connected success and fail, but now I know it's working have commented the succeed one out.

I then add these 2 lines to /jffs/scripts/services-start

cru a conCheck "*/2 * * * * /jffs/bin/con_check eth3 jdb2 F8:32:E4:51:54:08"
cru a conCheck2 "1-59/2 * * * * /jffs/bin/con_check eth3 jdb2 F8:32:E4:51:54:0C"

eth3 is the 5Ghz-2 interface, jdb2 is the hostname of the bridge, and the 2 MACs are the 5Ghz and br0 interfaces on the bridge.

As I said before I know it's a hack, but hopefully it might help someone else! Now that I have a clearer idea of what is happening and the 2 hour pattern, traces of broadcast messages failing to propagate etc I'm going to report it to Asus so maybe we'll get a fix to this 10+ month old bug!

 

[Jonas Petersson]

Hi! Thanks for your perfect discription. Not really sure but I guess I have a similar or the same problem with my new RT 5300. Running Merlin 380.69 but in Wireless Mode. When I connect to the 2.4Ghz wifi everything works great and I can RDP to my servers connected via cable. After a while (I'll have to time it now when you claimed 2hrs) the connectivity stop and all bridges between Wireless and Cable is gone. No ping replies or similar at all! I can release my IP on my laptop and renew and then the connectivity comes back up. Is this the same issue?

As a side note, ever since I started my RT 5300 chromecasts in the house stopped working. It's like IGMP and multicast just isn't playin ball at all.. Any ideas how I can troubleshoot? Can't find many others with similar issues..

Would rather not use a workaround

 

[JDB]

I've wasted a LOT of time trying to troubleshoot this. With my script it's all now perfect. I've not had a problem in over a month.
All I can say is to give it a go...

If/When Merlin adds AiMesh to his firmware I will revisit this as I'll be wanting to use AiMesh rather than Media Bridge mode. Maybe the problem will go away!

 

[Jonas Petersson]

Yeah I could tell, good job. Do you think I have the same problem though? I just timed it and connectivity was lost within 10 min, seems also related to transmitting packets. If I'm idle for a while and try again it seems to stop working. I'll find out if a ping keeps it alive!

Changing to 5ghz and then back to 2,4ghz solves the issue.

Is this only software related? No problmes with HW?

 

[JDB]

If it's happening within 10 mins that's definitely not quite the same. Shortest period I've seen is 2 hours.
In my research 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 would suggest it is definitely a S/W issue and not H/W yes.

 

[Jonas Petersson]

Alright, but I'm not running in bridge mode - this is in wireless mode. And yes, it seems a ping keeps it all alive. Strange!

Ok, know anything about old firmwares that works?

 

[JDB]

No, but I did find reference to similar issues dating back some time.
I’m amazed it hasn’t been properly identified and fixed yet.
I’m presuming there is some environmental factor that triggers it (maybe a certai level/type of multicast traffic) so not everyone experiences it.


Sent from my iPhone using Tapatalk

 

[Jonas Petersson]

Alright! Some more testing now (just installed my 5300 two days ago). It even seems it related from point-to-point and feels like a routing issue. If I keep a ping up from my host to one of my servers it keeps connectivity up (obviously) and I can RDP to it everything. But it still drops connectivity to other servers on the same server.

As an example, I host two servers connected with cable - say:
192.168.1.100
192.168.1.101

I join my 2,4wifi with my laptop and I can RDP and ping both servers. If I disconnect all traffic to the servers for about 10 min and try again I can't route to any of the again, not ping or RDP or similar (the route is still in my routing table though with correct gw for 192.168.1.*). If I do keep a ping up to one of the servers say *.100 then I can still RDP to it as long as the ping is up BUT connectivity to the server that isn't pinged continuously is still lost. I can't ever reach it again without renewing IP or rejoining the network. So this indicates it's not even bridging related right?

Any ideas appreciated

Update: I did some wiresharking trying to find out what happend with traffick to the server to which I "lost" connectivity. And then suddenly after 20 mins of no replies, without changing anything it just started working again Guess it will stop if I leave it alone for a while again but still it's interesting.

 

[winb83]

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.

 

[winb83]

I find it funny that I went out and bought the Netgear Nighthawk X10 router and set it up with the same info as my 88U and my second 88U works flawlessly with it. I've had the Netgear over a week and the Asus router in bridge mode has never dropped connection once. With the 2 Asus routers it dropped daily and with heavy use multiple times a day.

 

[JDB]

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


Sent from my iPhone using Tapatalk

 

[Dannkke]

Hello guys!

Have have this problem to with a ac88 as a router and a ac66 as a bridge.

Randomly the bridge disapears from the clientlist and is not reachable.

Have you found any solutions yet?