Release Asuswrt-Merlin 386.10 is now available for AC models

[D_Day]

Check your system log, it will tell you what the problem is.

I cannot troubleshoot anything without that information. Most likely is you have a custom parameter that's no longer valid with OpenVPN 2.6. The system log will tell you what it is.

Problem solved.
My providers config file needed 'keysize 256' removing.
All works perfectly now

 

[roundaway]

RT-AC66U_B1. Dirty flash from beta to release w/o issue. FYI. Pop-up saying something like "Waiting to Apply System Settings" during flashing to Alpha, Beta, and release versions stayed on the screen for at least 1 minute 15 seconds after selecting the file to Upload. Made it appear nothing was happening. Just had to wait. Don't remember seeing a delay flashing other versions. Thank you RMerlin.

 

[Igor]

NVRAM usage

move those IP address reservations to /jffs/configs/dnsmasq.conf.add

How can I do that? I now have "NVRAM usage 63776 / 65536 bytes", "JFFS 2.41 / 62.75 MB". Launched OpenVPN server. I'm afraid to update the firmware...

# nvram show | awk '{print length(), $0 | "sort -n -r"}' | cut -d"=" -f 1 | head -n 20

size: 63707 bytes (1829 left)
1154 sshd_authkeys
931 nc_setting_conf
847 custom_clientlist
723 dhcp_staticlist
573 rc_support
266 wl0_maclist_x
265 wl_maclist_x
263 wl0_maclist
262 wl_maclist
262 filter_lwlist
248 wl1_maclist_x
245 wl1_maclist
241 vpn_server1_ccd_val
240 vpn_server_ccd_val
205 wl1_chansps
176 vpn_serverx_clientlist
164 subnet_rulelist
120 qos_rulelist
112 vlan_rulelist
92 1:pa5ga2

But 1154 + 931 + 847 + 723 + 573 + 266 + 265 + 263 + 262 + 262 + 248 + 245 + 241 + 240 + 205 + 176 + 164 + 120 + 112 + 92 = 7389‬ != 63707

 

[Tech9]

IMHO, I don't like that.

If someone wants 5x VPN Clients on a router - AC68U is not the right model. For most users this option only takes resources and has no value.

 

[RMerlin]

The high nvram doesn't have any effect on me now

You are just one single sample. The fact is, filling up nvram can lead to major consequences such as routers getting their settings corrupted and causing the loss of the entire configuration. I find that more important than adding functionality that only a very small number of users use (the need of having more than 2 OpenVPN clients running on a slow CPU such as the RT-AC68U).

or you can store variable of nvram on jffs?

Moving settings to JFFS always carries a downside: its content doesn't get backed up along side settings. When Asus moves a setting to nvram like they did on the HND platform, they can integrate it within libnvram so the settings is transparently handled by saving/restoring settings. I do not have that option, I cannot modify the "large_nvram" table that they implemented with HND models. Moving OpenVPN-specific settings to JFFS might be an option since the certificates already reside there, but it would require major code changes throughout the entire firmware to handle that change. Not the level of development I am willing to invest specifically just for a 10 years old model that's probably on its way of being phased out. The amount of work + testing + debugging would require multiple weeks of work just for that.

The RT-AC68U is the only supported model that still has 64 KB of nvram.

ovpn-client3[4438]: Options error: Unrecognized option or missing or extra parameter(s) in config.ovpn:43: keysize (2.6.0)

Remove that "keysize" parameter, it was deprecated with OpenVPN 2.6.0.

https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--keysizeStatus:RemovedinOpenVPNv2.6

That parameter makes no sense in a modern OpenVPN configuration anyway, it was used by very old ciphers that nobody is using anymore (like BF-CBC). Any modern cipher likes AES-* has a fixed keysize.

 

[MysticGold04]

Updated all my devices to 386.10 from the beta - all running well for the past two hours…

Thanks Merlin!

 

[dudeThedude]

AC88U, dirty upgrade from 386.10alpha to 386.10 ...

and the log file is reporting constant fatal errors with dig

---

Mar 12 16:50:01 kernel: dig/31600: potentially unexpected fatal signal 11.
Mar 12 16:50:01 kernel: Pid: 31600, comm:                  dig
Mar 12 16:50:01 kernel: CPU: 0    Tainted: P             (2.6.36.4brcmarm #1)
Mar 12 16:50:01 kernel: PC is at 0x2ab50a5c
Mar 12 16:50:01 kernel: LR is at 0x2ab50a04
Mar 12 16:50:01 kernel: pc : [<2ab50a5c>]    lr : [<2ab50a04>]    psr: 200b0010
Mar 12 16:50:01 kernel: sp : 7e8edaf8  ip : 2b15c184  fp : 2b19543f
Mar 12 16:50:01 kernel: r10: 7e8edb5c  r9 : 00000004  r8 : 7e8edb58
Mar 12 16:50:01 kernel: r7 : c2d6e28d  r6 : 2b17cb20  r5 : 2b17cb20  r4 : 2abf9000
Mar 12 16:50:01 kernel: r3 : 2b17cb20  r2 : 2b15c7f4  r1 : 7e8edb58  r0 : 7e8edb5c
Mar 12 16:50:01 kernel: Flags: nzCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Mar 12 16:50:01 kernel: Control: 10c53c7d  Table: 5143004a  DAC: 00000015
Mar 12 16:50:22 kernel: dig/450: potentially unexpected fatal signal 11.
Mar 12 16:50:22 kernel: Pid: 450, comm:                  dig
Mar 12 16:50:22 kernel: CPU: 0    Tainted: P             (2.6.36.4brcmarm #1)
Mar 12 16:50:22 kernel: PC is at 0x2ab9ba5c
Mar 12 16:50:22 kernel: LR is at 0x2ab9ba04
Mar 12 16:50:22 kernel: pc : [<2ab9ba5c>]    lr : [<2ab9ba04>]    psr: 200b0010
Mar 12 16:50:22 kernel: sp : 7e845af8  ip : 2ac11184  fp : 2b17343f
Mar 12 16:50:22 kernel: r10: 7e845b5c  r9 : 00000004  r8 : 7e845b58
Mar 12 16:50:22 kernel: r7 : c2d6e28d  r6 : 2ac31b20  r5 : 2ac31b20  r4 : 2ab1c000
Mar 12 16:50:22 kernel: r3 : 2ac31b20  r2 : 2ac117f4  r1 : 7e845b58  r0 : 7e845b5c
Mar 12 16:50:22 kernel: Flags: nzCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
Mar 12 16:50:22 kernel: Control: 10c53c7d  Table: 527e804a  DAC: 00000015

---

AMTM installed, with Diversion, Skynet and YazFi.

Reboot, factory wipe (WPS method) - it remains.

Running dig from the command line just returns "Segmentation Fault"

Ideas?

 

[Yota]

Moving settings to JFFS always carries a downside: its content doesn't get backed up along side settings. When Asus moves a setting to nvram like they did on the HND platform, they can integrate it within libnvram so the settings is transparently handled by saving/restoring settings. I do not have that option, I cannot modify the "large_nvram" table that they implemented with HND models. Moving OpenVPN-specific settings to JFFS might be an option since the certificates already reside there, but it would require major code changes throughout the entire firmware to handle that change. Not the level of development I am willing to invest specifically just for a 10 years old model that's probably on its way of being phased out. The amount of work + testing + debugging would require multiple weeks of work just for that.

The RT-AC68U is the only supported model that still has 64 KB of nvram.

Before nvram is committed nvram commit there allow almost infinite number of nvram values, because those nvram variables are only in RAM before committing, but can still be used by the system, so maybe allow all openvpn variables to just exist in RAM, load from jffs into RAM after each boot?

It sounds like moving to jffs, but not exactly, it might be a shortcut.

But the premise is to remove the nvram variables of openvpn, and once they are set, they will be ready at any time.


I mean, maybe you can remove the variable about openvpn.

But allow to configure them when needed, this will restore the functionality of 5 clients.
then someone who needs 5 clients can do a custom script to feed the needed variables into the RAM (uncommitted) nvram.





I've never thought doing subtraction was a good option for existing functionality. unless it's replaced with something better.

 

[Yota]

If someone wants 5x VPN Clients on a router - AC68U is not the right model. For most users this option only takes resources and has no value.

Just because someone has 5 doesn't mean they'll be running 5 at the same time, I'll save clients with different locations so I don't have to re-upload a new ovpn when I need to switch.

 

[Yota]

Running dig from the command line just returns "Segmentation Fault"

This usually means the binary is corrupted, delete it and reinstall.

or you are using a non-armv7 binary.

 

[Tech9]

I'll save clients with different locations

Removing features very few users benefit from is the way to go when the hardware is limited. Folks with special requirements have to find their own solution or upgrade to better hardware. This router is 10 years old and the options are: 1) new firmware that fits the limitations; 2) no new firmware.

 

[bennor]

How can I do that?

For static/manual IP reservations the easiest is to just use YazDHCP. The downside to YazDHCP is it currently doesn't save custom icons for clients. On the plus side it makes restoring static IP assignments much eaiser after doing a hard factory restore. Export the YazDHCP file, do a hard factory restore, reinstall YazDHCP, then import the saved YazDHCP file to restore all static IP addresses. See the following links for more on YazDHCP:
https://www.snbforums.com/threads/y...mit-on-the-number-of-dhcp-reservations.69247/
https://github.com/jackyaz/YazDHCP

 

[Faw]

Question: Will the firmware for the AC88U ever get the Wireguard GUI like the AX88U has, or it will never be supported?

 

[RMerlin]

Question: Will the firmware for the AC88U ever get the Wireguard GUI like the AX88U has, or it will never be supported?

No.

 

[RMerlin]

Before nvram is committed nvram commit there allow almost infinite number of nvram values, because those nvram variables are only in RAM before committing, but can still be used by the system, so maybe allow all openvpn variables to just exist in RAM, load from jffs into RAM after each boot?

You don't hand pick what's buffered in RAM and what's commited back to the flash partition. Anytime you change a setting, if you want that setting to survive a reboot, you have to commit nvram to flash, at which point the entire nvram buffer is written back.

I've never thought doing subtraction was a good option for existing functionality. unless it's replaced with something better.

The fact is that router simply got pushed farther than it should have been allowed to. I can either tell people "Use a two years old version that's less nvram-stressed, and forget about any future update to that model", or find a way to at least stabilize it as it is now. If my second solution doesn't match your needs and you want to keep using that old router, you're free to go with the first solution then.

This isn't the first time this has happened. The RT-AC3200 had to be limited to 2 OpenVPN clients, and only got the full 5 clients support after Asus increased nvram to 128 KB for that model.

 

[Jcquantum]

I've downloaded the 386.10 firmware and tried manually uploading. However, it's not updating saying u successful due to inappropriate firmware? I don't seem to understand why. I've even downloaded twice from to different devices to make sure it's not a download corrupt. Can anyone help? Thanks.

 

[dave14305]

I've downloaded the 386.10 firmware and tried manually uploading. However, it's not updating saying u successful due to inappropriate firmware? I don't seem to understand why. I've even downloaded twice from to different devices to make sure it's not a download corrupt. Can anyone help? Thanks.

You probably downloaded the wrong model. Check the 6s and 8s, Cs and Xs carefully.

 

[Tech9]

However, it's not updating saying u successful due to inappropriate firmware?

Do you still have AX88U main + 2x AC86U nodes?

If yes - there is nothing to update for you here. Keep the nodes on stock Asuswrt and update your main router to 388.2 when available.

 

[Jcquantum]

You probably downloaded the wrong model. Check the 6s and 8s, Cs and Xs carefully.

I'm downloading the firmware for my AP mode AC86U. I dont think I'm that dumb to be downloading for a different model router firmware. My current firmware is 386.9 on this device and is running as needed. Thanks foe helping AND assuming I'm an idiot.

 

[Tech9]

Thanks foe helping AND assuming I'm an idiot.

You got it wrong, buddy. What @dave14305 is talking about is a very common mistake due to similar model numbers.