What's new

Issues with 384.6 - RT-AC68R in bridge mode

  • 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!

Hunterx

Occasional Visitor
just for background info, I had this similar issue earlier this year with all of the early 384.x builds. I have been unable to get the Bridge mode stable past 380.X.

What is happening so far on 384.6 is being disconnected from the internet while being wired into the bridge. This happens randomly, but seems to happen every couple hours. Most of the time I can reboot the bridge, and the connection will be fixed (for a while).

Once so far, the bridge changed its IP from its DHCP assigned static IP to the default 192.168.1.1 address. It can only be connected to via http on 192.168.1.1 and will not respond on its preferred DHPC server assigned IP. It seemed to be connected to the 5ghz connection, but no connection at all is coming through the wire to my PC. This is the same type of behavior I experienced in the early 384.x builds.

I avoided 384.x until now, and I am hoping this can be fixed soon.
 
I have just flashed the Merlin LTS fork onto the bridge (RT-AC68U_374.43_33E7j9527), and so far it is performing well. I am hoping Merlin will also maintain a LTS on 380.X. I need stability and security updates over new features. The forked version appears to be the only option out there that offers these updates.
 
The LTS fork disconnected twice in a different way. I just flashed back to 380.70. This is extremely frustrating. I may abandon ASUS as a result. I have lost all confidence in the product line.
 
The LTS fork disconnected twice in a different way.
The "E" builds contain the same wireless driver that the latest Asus/Merlin uses. Try using the legacy "L" build that uses the old 2014 driver.

Also, make sure your 5GHz radio is not using any of the DFS channels.
 
The "E" builds contain the same wireless driver that the latest Asus/Merlin uses. Try using the legacy "L" build that uses the old 2014 driver.

Also, make sure your 5GHz radio is not using any of the DFS channels.
@Hunterx - what Colin said about double checking to not use DFS channels (50 through 144)

Also, remember that my 'L' builds do not have the KRACK fix which affects Media Bridge mode. Might be a good way to see if the KRACK fix is somehow not playing nice with Media Bridge.
 
@Hunterx - what Colin said about double checking to not use DFS channels (50 through 144)

Also, remember that my 'L' builds do not have the KRACK fix which affects Media Bridge mode. Might be a good way to see if the KRACK fix is somehow not playing nice with Media Bridge.

My AP (RT-AC3200) currently has that 5ghz connection (5GHZ-1) on Auto channel (currently 36), and operating on 80mhz.

I may have made a mistake when flashing. I used the recovery mode GUI to flash the firmware (hold reset button 10 seconds after power on). After successful flash, I reset settings with WPS button and power on method. When I returned to 380.70, the settings I had for the custom certificate was remembered, but non functional. I re-uploaded my key and crt and that fixed it, but it raises some questions about bad info on the older firmware being retained after reset.
 
My AP (RT-AC3200) currently has that 5ghz connection (5GHZ-1) on Auto channel (currently 36), and operating on 80mhz.
I would definitely set it to 'fixed' mode. It's weak, but I've seen the routers on auto change channels. If it happens to pick a DFS channel, it can block things for several minutes while it scans for radar.
I also seem to remember there was a checkbox option to ignore DFS channels in auto mode. Do you have that set? What region are you in?
 
but it raises some questions about bad info on the older firmware being retained after reset.

You probably didn't hold the wps button long enough. I have reset this way 100's of times and it has never failed to completely reset the router back to factory.
 
You probably didn't hold the wps button long enough. I have reset this way 100's of times and it has never failed to completely reset the router back to factory.
That may be correct, but I did hold for about 10 full seconds. The lights did not flash or reset until after I released the button. It seemed to reboot after that so I thought I did it correctly. It was reset enough to make me go through the manual setup again.

I have set the AP to fixed 36 now. I do not see the ignore DFS checkbox in the AP settings. My region is NW USA.
 
When I returned to 380.70, the settings I had for the custom certificate was remembered, but non functional. I re-uploaded my key and crt and that fixed it, but it raises some questions about bad info on the older firmware being retained after reset.
Moving back and forth between my fork and Merlin can be problematic with respect to certs/keys because they are stored in jffs (Merlin) and not nvram (default on my fork). The certs are still there, but may not always be properly recognized.
 
I have set the AP to fixed 36 now. I do not see the ignore DFS checkbox in the AP settings. My region is NW USA.
Probably not DFS related then unless you've changed regions on the router or MB (DFS channels are not available in US in the default wireless regs)
 

Similar threads

Sign Up For SNBForums Daily Digest

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