[Beta] Asuswrt-Merlin 380.67 Beta is now available

[GoNz0]

Exactly what I meant, but it came out wrong, so thanks for clarifying. And thanks for sharing your script.

Sooooooo, am I staring at something old and need to do some modifications or am I ok?

totally lost now

I have this "Samba: Enable SMB2 protocol (default: No)" listed in the other settings page.

 

[GoNz0]

@kvic's NTPD TAB will always appear fine after any firmware upgrade as httpd is using the custom /www files on the entware drive.

I went for ages without seeing @RMerlin's GUI tweaks until the penny dropped.

So I now always manually run my short script after every Firmware upgrade to ensure that any undisclosed GUI tweaks by Asus are always shown!
(@RMerlin would never move a few GUI pixels without formally announcing it? - except for the infamous April Fool's prank! )

/jffs/scripts/RefreshWWW.sh

https://pastebin.com/tbw0LgnL

Hosted on pastebin as life is too short to tediously identify why posting the script in-line triggers the forum blocker

Just ran your script now I have caught up on this post and SMB2 has indeed vanished off to it's new home.

As always i'm oblivious to most things

 

[MacG32]

380.67 Beta 1 running smoothly here. Reporting no problems with OpenVPN and PIA. Thank you @RMerlin !

 

[bobiii]

Came back from Asus 7743 (which was working ok) to Merlin's beta 1 on my 5300. Everything is working great. All my wireless channels are working and I'm a happy camper! Missed the extra features!!!

 

[TheOldMan]

Install automake 1.11. If using the officially supported Ubuntu distro:

sudo apt install automake1.11

I already had automake1.11 installed. I made a ln -s to 1.15 which works, albeit incorrectly, fixed by removing the link and reinstalled 1.11. The brcm build environment needs to be posted to /etc/environment and not .profile IMHO.

 

[RMerlin]

The brcm build environment needs to be posted to /etc/environment and not .profile IMHO.

The whole build environment in Asuswrt needs a thorough cleanup. Some bits come with pre-generated automake files, others will generate them for your target system. It varies depending on whether a specific component came from Tomato, old Asus code, newer Asus code, or someone else.

This is one thing that OpenWRT mostly got right, tho personally I prefer working with patched sources than having patches applied on top of the vanilla tarball - makes it hard to follow up on these patches.

 

[john9527]

I already had automake1.11 installed. I made a ln -s to 1.15 which works, albeit incorrectly, fixed by removing the link and reinstalled 1.11. The brcm build environment needs to be posted to /etc/environment and not .profile IMHO.

Look into 'update-alternatives' if you are using a non-standard environment. It's been a while since I worked through the setup, but remember it wasn't too hard once I stumbled on the solution. Here's my current settings for automake.

update-alternatives --display automake

automake - auto mode
link currently points to /usr/bin/automake-1.15
/usr/bin/automake-1.11 - priority 29
slave aclocal: /usr/bin/aclocal-1.11
slave aclocal.1.gz: /usr/share/man/man1/aclocal-1.11.1.gz
slave automake.1.gz: /usr/share/man/man1/automake-1.11.1.gz
/usr/bin/automake-1.15 - priority 33
slave aclocal: /usr/bin/aclocal-1.15
slave aclocal.1.gz: /usr/share/man/man1/aclocal-1.15.1.gz
slave automake.1.gz: /usr/share/man/man1/automake-1.15.1.gz
Current 'best' version is '/usr/bin/automake-1.15'.

 

[MacG32]

Just found a possible issue with OpenVPN. The client failed to re-authenticate after timing out. Normally, if not used for a 6-8 hour period, it would ping timeout and re-authenticate. I'm not sure if this was a one time thing or an actual reoccurring issue. I'll post if it happens again. This is the first time I've seen these in the log: openvpn[1246]: AUTH: Received control message: AUTH_FAILED and openvpn[1246]: SIGTERM[soft,auth-failure] received, process exiting

 

[RMerlin]

Just found a possible issue with OpenVPN. The client failed to re-authenticate after timing out. Normally, if not used for a 6-8 hour period, it would ping timeout and re-authenticate. I'm not sure if this was a one time thing or an actual reoccurring issue. I'll post if it happens again. This is the first time I've seen these in the log: openvpn[1246]: AUTH: Received control message: AUTH_FAILED and openvpn[1246]: SIGTERM[soft,auth-failure] received, process exiting

Add "auth no-cache" to your configuration. I don't know yet if it's a bug with OpenVPN or PIA (or could be an OpenVPN bug but PIA hasn't updated yet). That's the solution that PIA came up with when I talked to them about it.

 

[taozhong]

Just found out RT-AC66U with OpenVPN server configured, if client connected and downloading files via this connection, CPU loading will keep very high (over 90%).
This might be as design, right?

 

[thelonelycoder]

I've had 380.67_beta installed on two routers, ARM and MIPS.
As I work a lot with SSH (Xshell 5) and SCP (WinSCP), I noticed dropbear timeouts/disconnects whenever I used one of these routers.
Changing the keep-alive settings in the SSH and SCP settings did not help.
What did help is downgrade to the latest stable 380.66_6. Then it stopped disconnecting.

I have never seen this behavior before, on any of the stable/beta/alpha versions.
Unfortunately, I did not save the Syslog with these entries, but it is dropbear reporting a timeout and closing the connection.

 

[TheUntouchable]

I've had 380.67_beta installed on two routers, ARM and MIPS.
As I work a lot with SSH (Xshell 5) and SCP (WinSCP), I noticed dropbear timeouts/disconnects whenever I used one of these routers.
Changing the keep-alive settings in the SSH and SCP settings did not help.
What did help is downgrade to the latest stable 380.66_6. Then it stopped disconnecting.

I have never seen this behavior before, on any of the stable/beta/alpha versions.
Unfortunately, I did not save the Syslog with these entries, but it is dropbear reporting a timeout and closing the connection.

Had the same the last days, thought it was my vpn connection.

 

[Adamm]

I've had 380.67_beta installed on two routers, ARM and MIPS.
As I work a lot with SSH (Xshell 5) and SCP (WinSCP), I noticed dropbear timeouts/disconnects whenever I used one of these routers.
Changing the keep-alive settings in the SSH and SCP settings did not help.
What did help is downgrade to the latest stable 380.66_6. Then it stopped disconnecting.

I have never seen this behavior before, on any of the stable/beta/alpha versions.
Unfortunately, I did not save the Syslog with these entries, but it is dropbear reporting a timeout and closing the connection.

Can confirm this too, the keep-alive setting is definitely not working after this update

I do see reference to a new "sshd_timeout" nvram var in the GPL 380_7723 merge which I believe is the cause of the issue, but I find it silly for keepalive requests to be ignored.

 

[Martineau]

Had the same the last days, thought it was my vpn connection.

Nope same here.

P.S. Do you have any VPN Client issues? I'm having a torrid time on this beta getting four concurrent VPN Clients to selectively to use the target VPN DNS. (Still debugging as I came from 380.66_4 so skipping 380.66_6 may not have helped).

 

[RMerlin]

Can confirm this too, the keep-alive setting is definitely not working after this update

I do see reference to a new "sshd_timeout" nvram var in the GPL 380_7723 merge which I believe is the cause of the issue, but I find it silly for keepalive requests to be ignored.

Default value is 20 mins. Try disabling the timeout:

nvram set sshd_timeout=0
nvram commit
service restart_sshd

I didn't notice any issue myself so far, fairly sure I did stay connected for longer than 20 mins during some of my recent tests.

 

[TheUntouchable]

P.S. Do you have any VPN Client issues? I'm having a torrid time on this beta getting four concurrent VPN Clients to selectively to use the target VPN DNS. (Still debugging as I came from 380.66_4 so skipping 380.66_6 may not have helped).

Yes, I have DNS problems over VPN too. Sometimes my laptop is using the dns from my router and I can open router.asus.com without problems, sometimes later it completly forgets about it and uses the dns servers from the hotspot @ work.. The dns leaktest shows the dns server from my router and in addition all the others from my hotspot at work..

 

[thelonelycoder]

Default value is 20 mins. Try disabling the timeout:

I didn't notice any issue myself so far, fairly sure I did stay connected for longer than 20 mins during some of my recent tests.

As the sshd_timeout is a new NVRAM setting in .67 and some more code is required to make it work, my guess is that the client's keep alive ping is ignored and the 20 min setting comes into effect.
The timeout happened without fail if I left it idle on my RT-AC1900P and RT-AC66U routers.

 

[thelonelycoder]

Default value is 20 mins. Try disabling the timeout:

Reinstalled this beta and set the timeout to 2 minutes.
Same thing: Jun 29 17:00:19 dropbear[2933]: Exit (user-name): Idle timeout

Now for the good news: In WinSCP, if you set the Keepalive setting to "Executing dummy protocol commands" then there's no timeout.
With the standard "Sending of null SSH packets" the timeout happens.
I have to verify it but I'm sure dropbear is drop dead in it's detection of SSH usage...
Also, since this timeout is new, could there be a setting in the UI for it?

Edit: I can confirm the WinSCP Keepalive setting "Executing dummy protocol commands" prevents the timeout.
I have not found a solution for Xshell 5, which has an option to send a string when network is idle. You have to enter the string. I tested it with \r which is an enter command and it keeps the connection alive. But of course the string is wrong, there must be a silent command to add.

 

[Marc66]

I don't want to devote too much effort toward the FTP service, as personally I consider it to be a "distraction" rather than an important feature. It would depend on how much effort would be involved in adding such support.

I use the FTP server to copy John's backup utility to my router flashdrive and copy back the backup files to my NAS. I only enable it during this operation, so I don't use it very often, but I find it is an interesting feature to have. The simplest FTP server is fine enough for me, no need to have lots of features.

 

[TheOldMan]

Look into 'update-alternatives' if you are using a non-standard environment. It's been a while since I worked through the setup, but remember it wasn't too hard once I stumbled on the solution. Here's my current settings for automake.

update-alternatives --display automake

automake - auto mode
link currently points to /usr/bin/automake-1.15
/usr/bin/automake-1.11 - priority 29
slave aclocal: /usr/bin/aclocal-1.11
slave aclocal.1.gz: /usr/share/man/man1/aclocal-1.11.1.gz
slave automake.1.gz: /usr/share/man/man1/automake-1.11.1.gz
/usr/bin/automake-1.15 - priority 33
slave aclocal: /usr/bin/aclocal-1.15
slave aclocal.1.gz: /usr/share/man/man1/aclocal-1.15.1.gz
slave automake.1.gz: /usr/share/man/man1/automake-1.15.1.gz
Current 'best' version is '/usr/bin/automake-1.15'.

My display automake is the same. My opinion is adding /opt/brcm to /etc/enviornment works better than /home/user/.profile ...