Release [ 384.19_Alpha Build(s) ] Testing available build(s)

[jerry6]

Not at all the end of the line: closing the 384.18 final thread just means that RMerlin thinks that discussion has run its course and any additional posts would only stray further off topic (to meandering, random topics). Development is actively under way on 384.19: this thread started with a focus on the AX builds, but there is also a separate thread covering more models but with an emphasis on some changes being made to the OpenVPN components. Ultimately, these will likely all merge into a unified Beta thread, just give it a bit more time.

thank you for the explanation

 

[kernol]

Following on from my problems with the .19 alpha in this post - I am now pleased to report that 384.19 Alpha4 was successfully dirty flashed over 384.18 on both my RT-AC86U and RT-ACX5300 - with all add-ons per my signature behaving normally.

The only thing I had to do was force re-update uiScribe - taking option "uf" from the uiScribe menu in amtm. No idea why that should have been - but the System Log page in the Webui would not display until I did that.

Looks to me like 384.19 will shortly make it to a Beta release - and will be well worth the upgrade due to significant security patches from Asus [one of which has been outstanding since 2017] ... and a huge rewrite of OpenVPN by Merlin to cap a host of other fixes. Awesome work as usual from the Maestro .

 

[Vexira]

is any one esle getting this error on an RT-AX88U im running alpha 4:
Jul 31 18:05:17 modprobe: module nf_conntrack_proto_gre not found in modules.dep
Jul 31 18:05:17 modprobe: module nf_nat_proto_gre not found in modules.dep
Jul 31 18:05:18 modprobe: module nf_conntrack_pptp not found in modules.dep
Jul 31 18:05:18 modprobe: module nf_nat_pptp not found in modules.dep

i suspect its to do with the nf_contrack script im using an the newer flex qos, but its only appeared in after beta 2, ive deleted the nf contrack script and will test to see if that fixes it.

 

[Maghook]

@RMerlin noticed SSH regression in alpha4:

1. Updated to alpha4
2. resetted NVRAM , rebooted, configured from scratch
2 a. enabled ap mode
2 b. only configured settings on system administration and enabled ssh(local), then reboot
3. AX88u reboots into nirvana

 

[RMerlin]

im having issues with alpha 3 .... says openvpn connected but only shows local ip and not public, i cant used the internet . on 384.18 same settings everything works and shows public ip , i have already cleared jffs and all what is going on and even the log doesnt show errors i have tried 5 different vpns and all same result .... just wont show public ip address for openvpns

Unable to reproduce here. If the router itself isn't able to determine it's public IP, then looks like the remote server might not be pushing the appropriate routes. Please post your system log content.

 

[RMerlin]

@RMerlin noticed SSH regression in alpha4:

1. Updated to alpha4
2. resetted NVRAM , rebooted, configured from scratch
2 a. enabled ap mode
2 b. only configured settings on system administration and enabled ssh(local), then reboot
3. AX88u reboots into nirvana

Zero change to SSH for the past month or two. Please post your system log.

 

[Maghook]

Zero change to SSH for the past month or two. Please post your system log.

Well, I fear this won't help you (cause 1. at time I only enabled notice loglevel , 2. router won't crash on reboot if I had not left ssh enabled before rebooting), but here it is (see attached)

It's most propably the same issue I first noticed on .19a1:
You only have to do a nvram reset, reboot device, then configure as ap mode (setup wizard) with IP assigned by another DHCP server, reboot again, start with system administration page and e.g. change the following:

• Format JFFS partition at next boot: yes
• Enable HDD Hibernation: yes (5min)
• DST time zone change: (doesn't matter)
• Disable LEDs: yes
• Enable SSH: LAN only
• Enable SSH Brute Force Protection: yes (don't know anymore if I had this one enabled or not; perhaps this is the cause of my trouble, malfunctioning?)

Afterwards I had set some nvram settings (disabled NAT filters, upnp, WPS, STP, WRS, set loglevel and client customlist) via SSH, but from my POV these settings I changed doesn't matter at all. Then force a reboot, leaving ssh enabled and for sure - you won't get access to the device anymore (even not responding to icmp echo requests anymore; totally unaccessible by IP anymore even if you turn power off and back on) - all in all if I had left SSH enabled before rebooting. Otherwise: If I had disabled SSH after pushing nvram settings and then forcing a reboot everything is good: successful reboot, normal operation.

Maybe I've to submit you my config in order to be able to reproduce this issue?

HTH

 

[RAH-66]

@RMerlin, Fix CallStranger vulnerability (CVE-2020-12695) is planned for this 384.19 version?

 

[RMerlin]

@RMerlin, Fix CallStranger vulnerability (CVE-2020-12695) is planned for this 384.19 version?

There is nothing to fix. Asuswrt-Merlin uses miniupnpd, which is not vulnerable.

 

[jerry6]

orking well on my ac5300 Alpha 384-19 nothing strange in the logs all radios working fine . one thing in wireless log if i click on the mac for the one device on that channel it reports it as being on the 2.4 ghz radio not 5.2 everything works just odd it reports the wrong radio
Thank you once again for another FW release

 

[RMerlin]

Well, I fear this won't help you (cause 1. at time I only enabled notice loglevel , 2. router won't crash on reboot if I had not left ssh enabled before rebooting), but here it is (see attached)

It's most propably the same issue I first noticed on .19a1:
You only have to do a nvram reset, reboot device, then configure as ap mode (setup wizard) with IP assigned by another DHCP server, reboot again, start with system administration page and e.g. change the following:

• Format JFFS partition at next boot: yes
• Enable HDD Hibernation: yes (5min)
• DST time zone change: (doesn't matter)
• Disable LEDs: yes
• Enable SSH: LAN only
• Enable SSH Brute Force Protection: yes (don't know anymore if I had this one enabled or not; perhaps this is the cause of my trouble, malfunctioning?)

Afterwards I had set some nvram settings (disabled NAT filters, upnp, WPS, STP, WRS, set loglevel and client customlist) via SSH, but from my POV these settings I changed doesn't matter at all. Then force a reboot, leaving ssh enabled and for sure - you won't get access to the device anymore (even not responding to icmp echo requests anymore; totally unaccessible by IP anymore even if you turn power off and back on) - all in all if I had left SSH enabled before rebooting. Otherwise: If I had disabled SSH after pushing nvram settings and then forcing a reboot everything is good: successful reboot, normal operation.

Maybe I've to submit you my config in order to be able to reproduce this issue?

HTH

Tested both on an RT-AX88U and RT-AX58U, cannot reproduce. I was connecting back to the AP, accessing the webui and SSH without any problem.

I have to ask tho... Why do you set it to erase the JFFS on reboot (which shows a warning that this will wipe out various settings), configure various things, and then reboot, causing the settings stored to JFFS (like the sshd host key) to be erased?

 

[Maghook]

I have to ask tho... Why do you set it to erase the JFFS on reboot (which shows a warning that this will wipe out various settings), configure various things, and then reboot, causing the settings stored to JFFS (like the sshd host key) to be erased?

I set up my AX88 again a few minutes ago, and this time I omitted deleting the JFFS. Result: You are absolutely right that deleting JFFS is a bad choice in this case. I must apologize.

This is was just my form of standard resetting procedure over the years everytime I want to setup from scratch.
Interesting enough, it had never been a problem over the years (up to .19a now). So, seems to me that something must have changed lately. But don't care.

Thanks for telling me about nonsensical traditions

 

[Adam Williamson]

alpha4 is amazing thanks no issues yet

 

[octopus]

384.19.Beta1 is out, and we can close this thread.
https://www.snbforums.com/threads/beta-asuswrt-merlin-384-19-beta-is-now-available.65581/
@RMerlin