What's new

[Beta] Asuswrt-Merlin 384.11 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!

For 86U owners if I understood correctly, the solution is to use HTTPS instead of HTTP for Webui access?

The solution for what, exactly? :)
 
Non responding webui..?
I only use https on my AC86U and it still sometimes locks up, running "/sbin/service restart_httpd" from an SSH terminal solves it. That works so well that I run a cron job to run that command a few times a day, as a preventive measure. The AC86U just has some quirks, but not every one of them. Some have zero quirks, I'm just one of the lucky ones. :) No way I would ever give this up, I like the quirky personality, keeps me on my toes.
 
Non responding webui..?

No, when it doesn't respond, it doesn't respond at all for some. The cause is not known, but restarting httpd on the router is what fixes it for most.

The 'fix' that I would recommend is to either memorize the restart command (which I haven't :) ), or simply install @Jack Yaz's excellent scMerlin script which will allow you to do so much more than just restart the web interface. ;)

https://www.snbforums.com/threads/scmerlin-service-and-script-control-menu-for-asuswrt-merlin.56277/
 
No, when it doesn't respond, it doesn't respond at all for some. The cause is not known, but restarting httpd on the router is what fixes it for most.

The 'fix' that I would recommend is to either memorize the restart command (which I haven't :) ), or simply install @Jack Yaz's excellent scMerlin script which will allow you to do so much more than just restart the web interface. ;)

https://www.snbforums.com/threads/scmerlin-service-and-script-control-menu-for-asuswrt-merlin.56277/
Put this in /jffs/scripts/services-start. :cool:
Code:
cru a restart_httpd "0 */6 * * * /sbin/service restart_httpd"
 
Good night, I'm using DOT + DNSSEC with cleanbrowsing.

I'm having small freezes and today the connection was offline.

I could see that although the internet link was active, I could not use the internet.

The WAN connection was offline.

I use AC86U in the last beta.

Anyone else with this problem?

Thanks for any help.
 
For 86U owners if I understood correctly, the solution is to use HTTPS instead of HTTP for Webui access?

I have any Asus router set to “both”, for connection type.
Never had a problem - so far.....
 
Known issues:

  • Providing a custom stubby.yml prevents the router from properly starting/setting clock at boot time. (that's because at boot time, stubby.yml must tell stubby NOT to enable TLS mode until the clock has been set. Support for stubby.yml replacement has been removed in beta2, ensuring users rely on .add or on .postconf to customize stubby)
  • Squashfs errors on some models (Beta 2 contains a kernel level fix for the root issue.)
  • Setting nvram through httpApi doesn't work for some models (Fixed in beta2).
  • Traceroute returning weird results on routers using older kernels (probably compatibility issue with either kernel 2.6.36 or uclibc. Final release will revert Network Tools back to their former implementation except for RT-AC86U and RT-AX88U)
  • QoS rule priorities (Adaptive QoS) are lost after a firmware upgrade (Bug in closed source components, already fixed upstream by Asus, have to wait for next GPL release with that fix)
  • Toggling SSH settings do not apply (sshd isn't properly restarted when settings are changed)
bETA 2 SEEMS to be working well on my ac 3200.s only computer running vpn client has trouble connecting after a router reboot have to log in several times on the routers wan page before it connects ,
not sure on the dns settings dnsecc and dot and which servers to use , that might be my problem . as of now all working , i'll keep reading and try different settings
Thanks for the FW
 
Good night, I'm using DOT + DNSSEC with cleanbrowsing.

I'm having small freezes and today the connection was offline.

I could see that although the internet link was active, I could not use the internet.

The WAN connection was offline.

I use AC86U in the last beta.

Anyone else with this problem?

Thanks for any help.
Turn off DNSSEC. CleanBrowsing and Quad9 experience intermittent connection issues with DNSSEC enabled. Cloudflare seems to work very well on DoT & DNSSEC.
 
Turn off DNSSEC. CleanBrowsing and Quad9 experience intermittent connection issues with DNSSEC enabled. Cloudflare seems to work very well on DoT & DNSSEC.

I haven't noticed any connections issues with DNSSEC+DoT going through Quad9 on three different home networks. And in my case, using Cloudflare results in occasional log messages about "Insecure DS reply received for ...". Compatibility must vary by region.
 
With both of the 384.11 BETA releases on my RT-AX88U (and Win 10 Pro x64 with all patches), I have lost all of my ipv6 connectivity... :oops:

No
problems prior to this BETA series re ipv6 (384.10* was fine WRT ipv6), and no changes on my part (still "Native", "Stateless", etc).

While I notice suggestions for custom scripts to fix/"activate" ipv6 with this BETA, was that really our benefactor's intention? To break a perfectly normal and functioning facility and start requiring customized scripts to then "fix" things? Most likely not...

When I say "no connectivity", I mean a) "https://test-ipv6.com/" tells me No IPv6 address detected and b) Windows "status" on the network adapter says IPV6 Connectivity: No Internet access

I had assumed some small oversight, possibly 88U-specific, but when the 2nd BETA didn't restore ipv6, I thought I might check in here - and yes, I did searches, but as mentioned above, I didn't really see this issue addressed in quite the way I expected.
 
With both of the 384.11 BETA releases on my RT-AX88U (and Win 10 Pro x64 with all patches), I have lost all of my ipv6 connectivity... :oops:

No
problems prior to this BETA series re ipv6 (384.10* was fine WRT ipv6), and no changes on my part (still "Native", "Stateless", etc).

While I notice suggestions for custom scripts to fix/"activate" ipv6 with this BETA, was that really our benefactor's intention? To break a perfectly normal and functioning facility and start requiring customized scripts to then "fix" things? Most likely not...

When I say "no connectivity", I mean a) "https://test-ipv6.com/" tells me No IPv6 address detected and b) Windows "status" on the network adapter says IPV6 Connectivity: No Internet access

I had assumed some small oversight, possibly 88U-specific, but when the 2nd BETA didn't restore ipv6, I thought I might check in here - and yes, I did searches, but as mentioned above, I didn't really see this issue addressed in quite the way I expected.

The issue is specific to the RT-AX88U, and the fix has been posted a couple of times already. Check this thread for a user script to work around the issue. The fix will have to come from Asus with a future release, it's too intricate for me to extract it from the other models, and Ihave no way of testing it.
 
The issue is specific to the RT-AX88U, and the fix has been posted a couple of times already. Check this thread for a user script to work around the issue. The fix will have to come from Asus with a future release, it's too intricate for me to extract it from the other models, and Ihave no way of testing it.

Thanks, done deal... like I said, I had found the suggested "fix" - I just thought that couldn't be the last word on the subject, and was expecting something more "permanent".

You have now made it clear that I shouldn't hold my breath - and the "workaround" does indeed bring everything back to normal, ipv6-wise... I suppose this is why you post the BETAs for the rest of us to try.:cool:
 
Thanks again to everyone for the replies, inputs and suggestions. I've installed scMerlin through amtm, just in case I need to restart httpd again.

I don't know, it's been randomly happening to some people for months now on the RT-AC86U, and I have never been able to reproduce it.

I see. Well, it's not that big of a deal, just kind of a nuisance. Shame that it only affects the AC86U, though.

Put this in /jffs/scripts/services-start. :cool:
Code:
cru a restart_httpd "0 */6 * * * /sbin/service restart_httpd"

Is that set to 4 hours, like you mentioned before? Any way to change the interval? Also, how exactly do you "put it" in that directory?

Sorry, but I never have a problem with HTTP://...... But I have had several problems with Microsoft Edge. Chrome and Firefox are always OK.

Unfortunately, it happened to me twice in two weeks, regardless of the browser I used (tried all three you listed).

Hasn't happened again since the last time I was messing around with settings on the WebUI. Fingers crossed.
 
The issue is specific to the RT-AX88U, and the fix has been posted a couple of times already. Check this thread for a user script to work around the issue. The fix will have to come from Asus with a future release, it's too intricate for me to extract it from the other models, and Ihave no way of testing it.

Only one line of code needs to be modified:
https://github.com/RMerl/asuswrt-merlin.ng/blob/rtax88/release/src/router/rc/wan.c
function: wan6_up
line: 2228
Code:
ipv6_sysconf(wan_ifname, "accept_ra", ipv6_ifdev_ppp && nvram_get_int(ipv6_nvname("ipv6_accept_ra")) ? 1 : 0);

change to:
Code:
ipv6_sysconf(wan_ifname, "accept_ra", ipv6_ifdev_ppp ? nvram_get_int(ipv6_nvname("ipv6_accept_ra")) : 1);

In most ISPs accept_ra (Accept Router Advertisements) must be 1, but in other ISPs like mine Infinitum Mexico (PPPoE) accept_ra must be 0
 
Is that set to 4 hours, like you mentioned before? Any way to change the interval? Also, how exactly do you "put it" in that directory?
I initially had it at 4, then changed it to every 6 hours, sorry for the confusion, I had forgotten the change.
Yes, you can change everything about cron job timing. There are two great resources I use to make sure I have the correct syntax. One is crontab guru. https://crontab.guru/every-6-hours

The other is the incredibly powerful and useful utilities from thelonelycoder, Diversion has a command accessible using the "more options (o)" named "(cj) show cron job(s)'. At the bottom is cheat sheet. :cool:
Code:
 |  |  |  |  |   |   command to run #job_name#   |
 .  .  .  .  ....... day-of-week
 .  .  .  .......... month
 .  .  ............. day-of-month
 .  ................ hour
 ................... minute     ( * = every ... )
The "services-start" is file inside the "/jffs/scripts" directory on your router. I'd suggest checking the RMerlin WikI on using scripts before doing more.
https://github.com/RMerl/asuswrt-merlin/wiki/User-scripts

Here is what mine looks like, the first three lines I added using the "nano" editor built into the Asuswrt-Merlin firmware. I turn off my router LED lights at 2200 and back on at 0700 the next morning (I live in a small apartment, nowhere to hide the router). The last two are added by Jack Yaz scripts during install.
Code:
#!/bin/sh
cru a lights_off "0 22 * * * /jffs/scripts/ledsoff.sh"
cru a lights_on "0 7 * * * /jffs/scripts/ledson.sh"
cru a restart_httpd "0 */6 * * * /sbin/service restart_httpd"
/jffs/scripts/ntpmerlin startup # ntpMerlin
/jffs/scripts/uiDivStats startup # uiDivStats
Every time the router boots, those lines are added to the active cron schedule.
 
Only one line of code needs to be modified:

The full, proper fix is more complex than that. Asus recently added an option to enable/disable router notification, with pieces of code implemented in libshared, rc, as well as the IPv6 webpage. Hardcoding that workaround runs the risk of breaking things for other ISPs, and it's too late in the 384.11 development cycle now to implement such risky changes.
 
Asus recently added an option to enable/disable router notification
Yes, in the AC86u model the option is "Accept default route" specific to the ppp interface, internally modify /proc/sys/net/ipv6/conf/ppp0/accept_ra_defrtr

and in the AX88U model on the web UI "Accept router advertisement" is specific to the ppp interface, internally modifies /proc/sys/net/ipv6/conf/ppp0/accept_ra or /proc/sys/net/ipv6/conf/eth0/accept_ra
ppp0 for WAN: PPPoE
eth0 por WAN: Automatic IP
The option is useful, the issue is the value assigned by default in the function wan6_up for the ethernet interface which is 0 and must be 1
That is why it is necessary to do it manually: https://www.snbforums.com/threads/b...ta-is-now-available.56325/page-36#post-487388

it's too late in the 384.11 development cycle now to implement such risky changes.
Yes I understand that, hopefully asus solve that issue soon, which is not complicated as it sounds :)
 

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