What's new

[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

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

Well, now I am looking to see how it works after performing
Code:
#!/bin/sh
sed -i -e 's/\:\:/::1/g' ab-solution.sh
sed -i -e 's/0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/g' ab-solution.sh
And then updating the hosts and rebooting.

If this does not seem to prevent dnsmasq from dying, I will try:
Code:
#!/bin/sh
nvram unset lan_domain
nvram commit
reboot
I would recommend starting a new thread, now that it's established this is not a fork issue.
 
I've had 2 Rt-AC56U running on 380.66.2 or 380.66.0 and going back to V25E1 is one living hell?? Tried with the CFE several times it would time out , yes I had my IP address fix 192.168.1.2 reset the 56U to defaults ended up reloading V25B7 this worked every time, I've tried this several times on 4 different 56U's... Even Problems CFE back to 380.66 when it would not recover , always fairly easy geting back to to recovery mode , ASUS recovery pgm did't help either .... 380.66 or V25E1 using ASUS recovery or the CFE pgm, had no problems using the GUI updating V25B7 to 380.66 or V25E1 to 380.66 but going back from 380.66 is a bitch! A BITCH!

Scared to try My RT-AC68U's!!!
I can't think of any reason 25E1 would be different from 25B7:confused:

The only thing in general in moving between the two would be to set your http port back to '80' in the fork if you moved it to another port before going to a Merlin build. You also may need to re-enter any certs if you moved them to jffs in the fork.
 
Hi John and Merlin,
Would it be possible to relink the autochecking new firmware to your location instead of Asus's site? It would be nice to have it autoupdate with beta check box.
Thanks to both for the hard work
Merlin has an autocheck for new firmware in his latest builds. I don't have the infrastructure to support it for my fork....the fork will always just be manual update.
 
Hi John and Merlin,
Would it be possible to relink the autochecking new firmware to your location instead of Asus's site? It would be nice to have it autoupdate with beta check box.
Thanks to both for the hard work

My build has had its own update server for over 6 months already.
 
Thu May 18 09:47:58 2017 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.

Above is the message I am getting on my ovpn client but using --remote-cert-tls will never allow me to get a working connection. Anyone with this issue too?
 
Thu May 18 09:47:58 2017 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.

Above is the message I am getting on my ovpn client but using --remote-cert-tls will never allow me to get a working connection. Anyone with this issue too?
There's a parameter that goes with it.....try
remote-cert-tls server
 
Yes....in the Custom Configuration section, delete the ns-cert-type line and insert the new 'remote-cert-tls server' line....
That didn't quite work somehow. Do I need to regenerate my certs?

Thu May 18 15:03:57 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]12.34.56.78:1194
Thu May 18 15:03:57 2017 UDP link local: (not bound)
Thu May 18 15:03:57 2017 UDP link remote: [AF_INET]12.34.56.78:1194
Thu May 18 15:03:57 2017 Certificate does not have key usage extension
Thu May 18 15:03:57 2017 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Thu May 18 15:03:57 2017 TLS_ERROR: BIO read tls_read_plaintext error
Thu May 18 15:03:57 2017 TLS Error: TLS object -> incoming plaintext read error
Thu May 18 15:03:57 2017 TLS Error: TLS handshake failed
Thu May 18 15:03:57 2017 SIGUSR1[soft,tls-error] received, process restarting
 
Well, now I am looking to see how it works after performing
Code:
#!/bin/sh
sed -i -e 's/\:\:/::1/g' ab-solution.sh
sed -i -e 's/0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/g' ab-solution.sh
I really have no idea what you try to accomplish with this code. These lines are wrong in so many ways.
 
V25E1 working well on my RT-N66U.
No problems with OpenVPN here.

Thx John!
 
Upgraded from V20 on AC68U - /jffs folder was emptied and upon copying the backed up scripts into it, it hung the ssh session and couldn't reconnect.
Had to enable reformatting of /jffs at next reboot and restart the router.

Good thing I took a backup of the /jffs prior to updating - almost skipped it since the notes only reminded MIPS users to backup.

Looks like backing up of /jffs may be mandatory if upgrading from older builds.
 
Upgraded from V20 on AC68U - /jffs folder was emptied and upon copying the backed up scripts into it, it hung the ssh session and couldn't reconnect.
Had to enable reformatting of /jffs at next reboot and restart the router.

Good thing I took a backup of the /jffs prior to updating - almost skipped it since the notes only reminded MIPS users to backup.

Looks like backing up of /jffs may be mandatory if upgrading from older builds.
Hmm, probably related to this:

https://www.snbforums.com/threads/f...lts-releases-v25e1.18914/page-266#post-305538

Update-23B8 Highlights

CHANGED: build: expand jffs for ARM from 32MB to 64MB
(ARM users, do like MIPS users and make a JFFS backup for safety just in case)


 
The only way I could recovery was to use V25B7 no way could I recover after loading 380.66 using the CFE or ASUS recovery pgm...... didn't move any ports

It acted like it does with the problem 32K and 64K change..... Appeared to me, that's why I first loaded V23-V25B7 then went up from their..
Don't know what to say....I made two passes on my AC68 updating to 380.66 then downgrading to V25E1 via the restoration tool without problems.

One thing for everyone who may be doing this downgrade.....afterwards, make sure you do a factory reset. There is over 12K of nvram space taken up by variables in the latest Merlin that have no meaning on the fork.
 
Upgraded from V20 on AC68U - /jffs folder was emptied and upon copying the backed up scripts into it, it hung the ssh session and couldn't reconnect.
Had to enable reformatting of /jffs at next reboot and restart the router.

Good thing I took a backup of the /jffs prior to updating - almost skipped it since the notes only reminded MIPS users to backup.

Looks like backing up of /jffs may be mandatory if upgrading from older builds.
Starting with V23, the jffs space on the ARM routers was expanded from 32M to 64M. Usually this will not cause any problems, but it's possible that if there was an error in the previously unused space something may go awry. I can only remember one other person who reported a problem and had to reformat.
 
@octopus @dopefish

I tracked down the reason that the 'Auto use DFS channels' option wasn't sticking when trying to enable the DFS channels. If you would like to try an early V26beta with the fix, drop me a PM.

As far as the support for the AC56, I'd expect that the additional channels would still be visible in the channel selection dropdown, even with the above problem. It just may not be possible for the AC56. Has anyone with an AC56 tried on the latest Merlin? Are they available there?
 
Yes....in the Custom Configuration section, delete the ns-cert-type line and insert the new 'remote-cert-tls server' line....
There's no such line in the server side (AC68) but this line is in my client's (PC) OVPN file . When setting it, I am getting the errors below :

Thu May 18 15:03:57 2017 TCP/UDP: Preserving recently used remote address: [AF_INET]12.34.56.78:1194
Thu May 18 15:03:57 2017 UDP link local: (not bound)
Thu May 18 15:03:57 2017 UDP link remote: [AF_INET]12.34.56.78:1194
Thu May 18 15:03:57 2017 Certificate does not have key usage extension
Thu May 18 15:03:57 2017 OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
Thu May 18 15:03:57 2017 TLS_ERROR: BIO read tls_read_plaintext error
Thu May 18 15:03:57 2017 TLS Error: TLS object -> incoming plaintext read error
Thu May 18 15:03:57 2017 TLS Error: TLS handshake failed
Thu May 18 15:03:57 2017 SIGUSR1[soft,tls-error] received, process restarting
 
There's no such line in the server side (AC68) but this line is in my client's (PC) OVPN file . When setting it, I am getting the errors below :
Ahh....I misunderstood your config.....you are using a PC OpenVPN client to attach to an AC68 set up as an OpenVPN server running the fork.

First thing to confirm is that none of the options on the VPN Details page for the server have the warning message that the exported configuration requires OpenVPN 2.4.0 or later.

Second, what client are you using on the PC? My sense is that clients based on PolarSSL vs OpenSSL can be finicky.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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

Members online

Top