RT-AC68U in Media Bridge Mode losing connection to main router

[Grisu]

RT-AC68U (RT-2900 = the same)

not really:

RT-AC68U = RT-AC1900

RT-AC86U = RT-AC2900

 

[Boogieman]

not really:

RT-AC68U = RT-AC1900

RT-AC86U = RT-AC2900

Oh bummer, I read the nrs in wrong direction.
Though, Im sure the same issues resides in the 86U - will change my conslusion accordingly

Thanks

 

[Boogieman]

Manually setting a channel on the main router has solved the bridge disconnections for me. If I left the channel setting (the one the bridge connects to) as “Auto” I would experience these issues. May want to try this to see if it helps.


Sent from my iPhone using Tapatalk

I tried on main router (the one You CAN set):
- Full auto = disconnects

- Control Channel 100 (best based on network enighbourhood)
+ ext ch. auto (only choice) - 80MHz fixed
+ ext ch. auto (only choice) - 20/40/80 MHz (allowing it to fall back on 40 or 20 if conflicts. Since Ch100 is used its set as continous area that allows fallback if nighbours set their channels right. Asus dont select middle channel but START channel, so its a but confusing compared to other routers)
DISCONNECTS here too.

Disable on 5Mhz that i USE for M.bridge:
(General)
Enable smart connect
(Wireless professional)
Airtime Fairness
Multi-User MIMO
802.11ac Beamforming
Universal Beamforming

 

[murky024]

I have the same issue with my AC-66U on both the standard Asus firmware and Merlin's version.

 

[EricUtah]

I have no idea if this will get any developer eyeballs or traction, but wanted to put out as much info as possible about this problem. The loss of connectivity has been occurring in all builds I've tried for a couple years, but got much worse some time after 380.68_4. Rolling back to that version makes the issue somewhat manageable for me. I've read dozens of threads about this issue and that was the only helpful item to come out of all of them

My scenario: RT68U in media bridge mode with 3 ethernet clients. Another RT68U runs as the AP. 5GHz network selected. It's a home office so I'm on it for 6 hours/day and I typically run into the issue where traffic stops forwarding about once each day.

I've found the following:

When clients behind the media bridge can no longer see the network, they're unable to ping the AP/gateway (in my case 192.168.1.1). Looking at the ARP table on the client host, they still have a valid ARP for the gateway.

Mac-Pro:$ arp -an
? (192.168.1.1) at 8:62:68:be:8d:a8 on en0 ifscope [ethernet]
Mac-Pro:$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1

The system log on the Media Bridge shows no events during that timeframe nor does the one on the AP.

If I log into the Media Bridge directly, I *can* ping the AP from there.

admin@RT-AC68U-7E88:/tmp/home/root# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=1.174 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=2.340 ms

Lights on the media bridge show Ethernet ports blinking, 2.4G not blinking, 5G blinking sporadically - but not in sync with Ethernet lights.

If I issue a 'service restart_net' on the Media Bridge, the SSH connection closes and all status lights go out for moment. When lights return the 5G traffic light blinks in sync with Ethernet lights and traffic to the clients on the bridge is restored. I'm not certain what's touched & restarted during a net restart, but that appears to be the problematic process.

So: For others dealing with this issue, a faster route than power cycling/rebooting is to log into the web page of the bridge, go the the LAN config, and change something minor (such as changing secondary DNS from 4.4.4.4 to 8.8.8.8). Saving the new config initiates a service restart_net_and_phy which will bring back the connection in about 10 seconds. Unfortunately I don't think a watchdog script on the Media Bridge can do anything since the bridge itself continues to see the gateway - only forwarding to/from the clients gets broken.

I don't know how to debug the net process any further. Ideas?

 

[snbDD]

I have the same issue with my AC-66U on both the standard Asus firmware and Merlin's version.

If you can - give a try to FreshTomato (2019.2). Can't say about AC-66U, but AC-68U is rock solid in Media Bridge mode with FT 2019.2

 

[t-nelson]

Router: RT-AC68U - 384.12
Bridge: RT-AC66U - 3.0.0.4.374.43_39E3j9527

I'm having the same experience as EricUtah. The clients seem to lose connectivity a little more frequently when resolving via service rather than a full reboot, but that could just be chance. I'm considering a power supply replacement but, without logs, am at a loss at how to proceed otherwise.

 

[digixmax]

If you can - give a try to FreshTomato (2019.2). Can't say about AC-66U, but AC-68U is rock solid in Media Bridge mode with FT 2019.2

I have the same good experience with FreshTomato 2019.2 on my RT-AC68P.

 

[Boogieman]

I have no idea if this will get any developer eyeballs or traction, but wanted to put out as much info as possible about this problem. The loss of connectivity has been occurring in all builds I've tried for a couple years, but got much worse some time after 380.68_4. Rolling back to that version makes the issue somewhat manageable for me. I've read dozens of threads about this issue and that was the only helpful item to come out of all of them

My scenario: RT68U in media bridge mode with 3 ethernet clients. Another RT68U runs as the AP. 5GHz network selected. It's a home office so I'm on it for 6 hours/day and I typically run into the issue where traffic stops forwarding about once each day.

I've found the following:

When clients behind the media bridge can no longer see the network, they're unable to ping the AP/gateway (in my case 192.168.1.1). Looking at the ARP table on the client host, they still have a valid ARP for the gateway.

Mac-Pro:$ arp -an
? (192.168.1.1) at 8:62:68:be:8d:a8 on en0 ifscope [ethernet]
Mac-Pro:$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1

The system log on the Media Bridge shows no events during that timeframe nor does the one on the AP.

If I log into the Media Bridge directly, I *can* ping the AP from there.

admin@RT-AC68U-7E88:/tmp/home/root# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: seq=0 ttl=64 time=1.174 ms
64 bytes from 192.168.1.1: seq=1 ttl=64 time=2.340 ms

Lights on the media bridge show Ethernet ports blinking, 2.4G not blinking, 5G blinking sporadically - but not in sync with Ethernet lights.

If I issue a 'service restart_net' on the Media Bridge, the SSH connection closes and all status lights go out for moment. When lights return the 5G traffic light blinks in sync with Ethernet lights and traffic to the clients on the bridge is restored. I'm not certain what's touched & restarted during a net restart, but that appears to be the problematic process.

So: For others dealing with this issue, a faster route than power cycling/rebooting is to log into the web page of the bridge, go the the LAN config, and change something minor (such as changing secondary DNS from 4.4.4.4 to 8.8.8.8). Saving the new config initiates a service restart_net_and_phy which will bring back the connection in about 10 seconds. Unfortunately I don't think a watchdog script on the Media Bridge can do anything since the bridge itself continues to see the gateway - only forwarding to/from the clients gets broken.

I don't know how to debug the net process any further. Ideas?

SOLUTION FOUND FOR MEDIA BRIDGE

To make media bridge stable, I got the solution in another thread.
USE FW 380.66 on AC66U (I used Merlins - the last one in 380.66 series - it was called 380.66_4).

Have not lost connection and required reboot for months (august 2nd i changed) since i changed over and that was the ONLY change i made.
I do notice that internet somtimes lags 1-10seconds, but never disconnects. Could be external issues (DNS or likewise) or some other issue with the FW.
Regardless I have no more issues streaming movies, file copying from my NAS and so on.
No more router reboots every 3-4hours - just 100% uptime

After that ASUS broke media bridge mode for good it seems like
Cheers
Boogie

 

[crawfish]

FWIW, after giving up on my spare RT-AC68U as a media bridge connecting to my main 68u, I'm currently using a Netgear R6700v3 in bridge mode, and it's working great (got it on sale and with further card discount for $60 at Amazon). The only strangeness was that assigning it an IP address using my main 68U's DHCP server as I do with all my devices caused it not to work at all. Allowing the 68U to hand out an IP address from its pool worked fine, and the connection's been perfectly stable and fast for the last week. It even reconnected fine when I rebooted the 68u for unrelated reasons. I also had good luck testing an old Linksys E4200 in bridge mode.

 

[collector930]

SOLUTION FOUND FOR MEDIA BRIDGE

To make media bridge stable, I got the solution in another thread.
USE FW 380.66 on AC66U (I used Merlins - the last one in 380.66 series - it was called 380.66_4).

Have not lost connection and required reboot for months (august 2nd i changed) since i changed over and that was the ONLY change i made.
I do notice that internet somtimes lags 1-10seconds, but never disconnects. Could be external issues (DNS or likewise) or some other issue with the FW.
Regardless I have no more issues streaming movies, file copying from my NAS and so on.
No more router reboots every 3-4hours - just 100% uptime

After that ASUS broke media bridge mode for good it seems like
Cheers
Boogie

I have been using FW 380.7743 for a year to get stable Media Bridge connections, but found that FreshTomato 2019.3 is even better, on my AC66U_B1 (which 2019.3 supports).

With FW 380.7743, and scheduled rebooting daily, I still encountered two problems: 1. losing connection about once a week or once a month, and more importantly 2. laggy internet browsing, with Chrome or Firefox frequently hanging for a few seconds (sometimes more), saying "Resolving Host...", i.e, looking up hostname using DNS (I tried different DNS servers but no improvement).

With FreshTomato 2019.3, there's been no need to reboot daily and no slow web browsing so far. Granted it's only been about a week, but usually when I try new firmware from Asus or Merlin, the Media Bridge will lose connection within an hour or so, especially when I step away from the computer for a while.

Thanks to snbDD and digixmax for the tip on FreshTomato. The setup process is very different from Asus FW so it took me about 20 minutes to figure out, but it's been worth it. I was just about to finally give up and buy a Netgear router, after encountering another lost connection on FW 380.7743.

Update: It's been 2 months and FreshTomato has been rock steady, without any daily reboot, lost connection or slow browsing. I think I finally found the solution to my Asus Media Bridge problem.

 

[crawfish]

I looked into FreshTomato, and I believe they say KRACK is not fixed. While I was using old Tomato on my E4200v1 for my brief test I mentioned in my Nov 25 post, I flashed a recent DD WRT onto my E4200v1, and it's been great for a couple weeks now. The Netgear R6700v3 has also been great with stock firmware for almost a month. These two routers with their firmware should be KRACK-free.

 

[RMerlin]

Krack is a client-side issue. A router running in router or AP mode is not vulnerable to it.

 

[crawfish]

Krack is a client-side issue. A router running in router or AP mode is not vulnerable to it.

Yes, but we're talking about bridge mode.

 

[collector930]

According to FreshTomato-ARM Changelog KRACK was fixed in version 2018.1 - 2018.04.14 a while back. Since the Asus AC66U and AC68 use the ARM command set the current version should be ok for these routers.

The problem may still be there for the MIPS command set though, according to this article:
https://macandegg.com/2019/04/freshtomato-beautiful-open-source-router-firmware/

 

[crawfish]

Oh, OK. I only researched Fresh Tomato WRT my E4200v1, and the forum posts I found stated it isn't fixed for MIPS, which is what that router is. Didn't know it was fixed on the ARM side.

 

[goggleeyes]

I feel your pain. I have been having the strangest problems since moving to 384.14. I have the main router in the lounge RT-AC86U and RT-AC68U in the kitchen as a repeater. My network went really bad a few days after the firmware install, wifi was atrocious. So I suspected the AC68U in the kitchen. I tried to get it working as best I could as it refused to reset itself to factory defaults using the buttons on the router itself e.g. press and hold reset, plugin power and hold for 5 secs, also tried WPS for 5 secs too. Whenever I did manage to get to any kind of setup webpage, it just didn't want to work i.e. connect to 86u in the lounge. So I decided to attack the AC86u. After much messing, I believe it maybe at fault. I'm not sure it's the firmware but I think my main AC86u router is just conked out. I have ordered a new one and it arrives today to replace it. In the meantime I have, after much pain, just setup an AImesh between the two routers which again is flaky as hell ....I just hope it is the ac86u at fault as I've ordered a new one and not the 68u

When I receive the new router today I will shove 384.14 and see how it behaves. Fingers crossed.

 

[Val D.]

I have been having the strangest problems since moving to 384.14.

See this thread for possible solutions:
https://www.snbforums.com/threads/r...-384-14-and-384-13_2-are-now-available.60585/

 

[goggleeyes]

When I receive the new router today I will shove 384.14 and see how it behaves. Fingers crossed.

Oh dear - so it seems I bought a replacement router for no reason as the new one had the exact same problem using the latest ASUS firmware, not WRT merlin. After reading some of the forums I changed the 2.4GHz channel bandwidth to 20MHz and Channel 11 and things seem to be working. So I have bought this router for no reason at all

Not sure I can return it

 

[Val D.]

After reading some of the forums

Well, this is why the forum exists. It's always better to read it before you spend extra money. Anyway, replace the older RT-AC68U with the new router. RT-AC86U has better WiFi throughput and coverage and you may find two identical routers working better in AiMesh setup. Don't take it as a loss, take it as an opportunity for improvement. Keep the old router for a while until you stabilize the new setup. Happy New Year!