What's new

[Beta] Asuswrt-Merlin 384.14 Beta is now available

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

Status
Not open for further replies.
RT-AC86U running 384.14B1.
I have a mesh network which includes a hard-wired RT-AC68U and a wireless DSL-AC68U. (both on latest stock)
For the last couple of weeks the mesh network has been unstable and cannot maintain a reliable connection to both nodes. I've also been having issues in the last day in being able to see all of my Chromecast devices. If I reset the wireless on my phone, some devices become visible, and others remain invisible, despite all of them being connected to the Internet and are able to respond to voice commands independently.

I gave all of the routers a full power cycle prior to going to bed last night and woke to find that the RT-AC86U had dropped its config completely (presented with the initial setup Wizard).

Anyway, not much in the way of diagnostic information to provide other than that vague sequence of events. I've never had the config drop itself like that before.
 
My wife has a Google Nexus 10 tablet running Android 5.1.1 that refuses to connect to 384.14B1. I have switched back and forth between that and 384.13, with no luck on 384.14B1. In fact, after the router has been updated to 384.14B1, it won't connect to it once it is running 384.13, again. I have to do a complete factory reset and set my network up again in order to get the Nexus 10 to connect.

Finally, I discovered that after I switch back to 384.13 and then set up a specific guest channel for the tablet, it will connect without resetting the network.

It's probably something simple that I am missing...

I also have a Verizon Ellipsis 10 tablet on the same version of Android, and it has no issues, whatsoever (other than being a Verizon Ellipsis 10, of course).

Does anyone have any idea what could be causing this?
 
My wife has a Google Nexus 10 tablet running Android 5.1.1 that refuses to connect to 384.14B1. I have switched back and forth between that and 384.13, with no luck on 384.14B1. In fact, after the router has been updated to 384.14B1, it won't connect to it once it is running 384.13, again. I have to do a complete factory reset and set my network up again in order to get the Nexus 10 to connect.

Finally, I discovered that after I switch back to 384.13 and then set up a specific guest channel for the tablet, it will connect without resetting the network.

It's probably something simple that I am missing...

I also have a Verizon Ellipsis 10 tablet on the same version of Android, and it has no issues, whatsoever (other than being a Verizon Ellipsis 10, of course).

Does anyone have any idea what could be causing this?
Are you using different SSID's for 2.4 and 5 GHZ radios?
 
Yes. They are the same name, but the 5G adds the suffix -5G

The guest network has a completely different name.
If you have the -5g suffix the SSID's are in fact different. Insure the 2.4 GHZ band is using only 20 MHZ bandwidth on a fixed channel (1-6-11) and the 5 GHZ is on a fixed channel (try 36 -r 149). Also try turning off beamforming.
 
If you have the -5g suffix the SSID's are in fact different. Insure the 2.4 GHZ band is using only 20 MHZ bandwidth on a fixed channel (1-6-11) and the 5 GHZ is on a fixed channel (try 36 -r 149). Also try turning off beamforming.

I have done the first two, so I will turn off beamforming tomorrow and see if that does the trick.

Thanks!
 
Beta 2

- UPDATED: RT-AX88U to GPL 384_6436 (with Let's Encrypt fixes backported from 384_81351)

- UPDATED: RT-AC68U, RT-AC86U to GPL 384_81351

- UPDATED: RT-AC88U, RT-AC3100 to GPL 384_81351 and binary blobs from 384_81116

- FIXED: Asus DDNS failing to update due to an expired certificate on Asus's server (inadyn will now ignore that certificate error for Asus DDNS).

- FIXED: Let's Encrypt support would sometime fail when using Asus DDNS (fixed DNS publishing of validation record) (in addition to general failure fixed by GPL 81351)

- UPDATED: dnsmasq 2.80-74-gdefd6b1 (themiron)
 
If you are having JFFS2 or dnsmasq issues with the RT-AX88U, please try the beta1-g02edc51d7e test build available here:

https://www.asuswrt-merlin.net/test-builds

JFFS2: after booting, check if the partition is mounted. If not, please post the output of the following commands:

Code:
cat /tmp/jffs2.log
nvram show | grep jffs2_

RMerlin,
This is what I get, hoping that it is useful input

Code:
cat /tmp/jffs2.log

(Factory reset with 834.14 beta1-g02edc51d7e)
About to mount it
start_jffs2
ready to mount getting info
Got partition info starting
Checking size
Failed unlocking

(Factory reset with 834.13)
cat: can't open '/tmp/jffs2.log': No such file or directory

(Factory rest with 834.13, setup successfully, dirty flash 834.14 beta1-g02edc51d7e)
About to mount it
start_jffs2
ready to mount getting info
Got partition info starting
Checking size
Prepare filesystem
HND init jffs_nvram
check_asus_jffs
Exiting start_Jffs2

nvram show | grep jffs2_

(Factory reset with 834.14 beta1-g02edc51d7e)
jffs2_clean_fs=1
jffs2_enable=1
jffs2_format=0
jffs2_on=1
jffs2_scripts=1
jffs2_size=66060288

(Factory reset with 834.13)
jffs2_enable=1
jffs2_format=0
jffs2_on=1
jffs2_scripts=1
jffs2_size=66060288

(Factory rest with 834.13, setup successfully, dirty flash 834.14 beta1-g02edc51d7e)
jffs2_enable=1
jffs2_format=0
jffs2_on=1
jffs2_scripts=1
jffs2_size=66060288
 
RMerlin,
This is what I get, hoping that it is useful input

Code:
Failed unlocking

Thank you. Looks like Asus broke things with 384_6436. If the router is set to erase the JFFS content, it will unlock the JFS partition for writing, however it now incorrectly checks whether this was successful or not. I'll fix it, please give it another try once beta 2 is released.[/code]
 
Last edited:
Interesting... 384.14 beta 2 on my rt-ac86u seems to use much less memory then before . 82% vs 74% on beta 2. Is there an explanation RMerlin , did you see also drop in memory usage (which is great of course) :? (and also the 74% with swap file at 0 mb)
 
Last edited:
Interesting... 384.12 beta 2 on my rt-ac86u seems to use much less memory then before . 82% vs 74% on beta 2. Is there an explanation RMerlin , did you see also drop in memory usage (which is great of course) :? (and also the 74% with swap file at 0 mb)
There was an Asus timezone (TZ) fix in httpd that says it’s related to a memory leak. Could be part of the reason.
 
I have been on the Beta for more than a week and so far encountered no issues (still having AX, 160Mhz and DFS disabled).

Can I ask if the Wireless Site Survey section is working well for everyone? It is showing no measurements at all in my case.
 
Interesting... 384.12 beta 2 on my rt-ac86u seems to use much less memory then before . 82% vs 74% on beta 2. Is there an explanation RMerlin , did you see also drop in memory usage (which is great of course) :? (and also the 74% with swap file at 0 mb)

384.12 beta 2. Typo?
 
I have been on the Beta for more than a week and so far encountered no issues (still having AX, 160Mhz and DFS disabled).

Can I ask if the Wireless Site Survey section is working well for everyone? It is showing no measurements at all in my case.

I have found that sometimes (If you change a channel for one of the radios for one instance ) the only way I can get the site survey to work again is reboot the router.
 
Status
Not open for further replies.

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