[Beta] Asuswrt-Merlin 380.67 Beta is now available

[RMerlin]

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.

In that case it might need to be looked into by the Dropbear author, since this is handled by dropbear itself.

 

[RMerlin]

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.

It wasn't too difficult to implement, so I went ahead with it.

 

[thelonelycoder]

It wasn't too difficult to implement, so I went ahead with it.

View attachment 9666

Is encryition the new NSA safe encryption?

 

[thelonelycoder]

In that case it might need to be looked into by the Dropbear author, since this is handled by dropbear itself.

So, before the timeout was added to nvram, was it set to "0" during compiling of dropbear in 380.66 and older?

 

[Henk59]

Flashed to 360-67B and 3 days without problems (but disabled both WiFi mostly).
OpenVPN works better with TLS=0 (also with 66.4) instead of -1, even a reboot can't resolve the -1 setting.
Thanks.

 

[john9527]

So, before the timeout was added to nvram, was it set to "0" during compiling of dropbear in 380.66 and older?

It's passed as a command line parameter when starting dropbear.....it wasn't included at all in previous versions.

 

[RMerlin]

Is encryition the new NSA safe encryption?

AES-256-GCM looks "good enough" to me

 

[thelonelycoder]

It's passed as a command line parameter when starting dropbear.....it wasn't included at all in previous versions.

Another entry to one of the start scripts to correct this for me, unless this can permanently set to 0 or dropbear behaves.

Edit, of course this only needs to be set once in nvram, no need to add it to a user script.
Silly me, sorry about that.

 

[thelonelycoder]

AES-256-GCM looks "good enough" to me

View attachment 9667

Not sure you got what I meant: The typo in the UI caught my ever wandering eyes.

 

[RMerlin]

Not sure you got what I meant: The typo in the UI caught my ever wandering eyes.

Oh. I didn't, because it's already gone from Git - my router was just running a temporary test build

 

[stambeccuccio]

Problems:
- Occasionally, devices on he 5GHz bandwidth disconnect;
- you can not adjust tx power adjustment via smartphone.

 

[Naftali Oziel]

Problems:
- Occasionally, devices on he 5GHz bandwidth disconnect;
- you can not adjust tx power adjustment via smartphone.
View attachment 9670

reset to factory, configure from scratch and see if that resolves your issue.

 

[JMB64]

Problems:
- Occasionally, devices on he 5GHz bandwidth disconnect;
- you can not adjust tx power adjustment via smartphone.
View attachment 9670

This is the issue I have been experiencing and described in an earlier post on this thread - post #54 on page 3. There is nothing that will fix it other than setting 5Ghz bandwidth to 40 Mhz. You can not use 80Mhz or 20/40/80 Mhz settings. Factory resets, clearing NVRAM, reloading firmware, doing fresh configurations, etc all have been tried by many people and do not work. Only using 40 Mhz channel widths (regardless of channel number chosen) fixes the issue.

I wish either Asus or Broadcom would acknowledge this fault and hopefully produce a version of firmware that fixes it. The older Asus 3941 code seems to be the only original Asus firmware that has stable 5Ghz WiFi but it is not Merlin code and he doesn't have a version directly based on this code. I know people on the boards have tried Merlin 380.62, 380.63, 380.64, 380.65, and 380.66 and all still have this 5Ghz problem. I too have used all of them to no avail. I have been using 380.67 Alphas and now the 380.67 Beta code and the problem still persists. I have my router on 40Mhz channel width and all is fine as it was with all other previous Merlin builds.

 

[taozhong]

Got my RT-AC66U installed with newest BETA FW crashed this early morning.
As you may see from following syslog, I've configured a SWAP, but seems useless.
https://1drv.ms/t/s!Ajpekfhmqc0SgfBIFbF-azVUBDthcQ

 

[Adamm]

In that case it might need to be looked into by the Dropbear author, since this is handled by dropbear itself.

For the time being can this timer atleast be extended (or even disabled by setting to 0). Very inconvenient having SSH time out constantly.

 

[RMerlin]

For the time being can this timer atleast be extended (or even disabled by setting to 0). Very inconvenient having SSH time out constantly.

Yeah, and since it's broken might as well make it default to 0 for the time being.

You can manually disable it by setting it to 0.

 

[coxymanne]

This is the issue I have been experiencing and described in an earlier post on this thread - post #54 on page 3. There is nothing that will fix it other than setting 5Ghz bandwidth to 40 Mhz. You can not use 80Mhz or 20/40/80 Mhz settings. Factory resets, clearing NVRAM, reloading firmware, doing fresh configurations, etc all have been tried by many people and do not work. Only using 40 Mhz channel widths (regardless of channel number chosen) fixes the issue.

I wish either Asus or Broadcom would acknowledge this fault and hopefully produce a version of firmware that fixes it. The older Asus 3941 code seems to be the only original Asus firmware that has stable 5Ghz WiFi but it is not Merlin code and he doesn't have a version directly based on this code. I know people on the boards have tried Merlin 380.62, 380.63, 380.64, 380.65, and 380.66 and all still have this 5Ghz problem. I too have used all of them to no avail. I have been using 380.67 Alphas and now the 380.67 Beta code and the problem still persists. I have my router on 40Mhz channel width and all is fine as it was with all other previous Merlin builds.

I have the same issue. Tried everything to get 5ghz stable but no luck. A lot of people say it is heat. But I think it is firmware related ! Please help !

 

[Goran]

AC-88U
Skipped all alphas and go directly from 380.66_4 to 380.67_beta1:
devices on the 5GHz bandwidth suden disconnect without any reason. (restart, clear NVRAM, changing channel - no help.)
All settings same as on .66 which works flawlessly.
Back to 380.66_6 because in my neighborhood 2.4GHz is cluttered and all my devices are 5GHz dependent.
First issue ever with my AC88U and need to rollback FW.

Using only OpenVPN client & server, DHCP with some static IP, no scripts or any "advanced stuff".

 

[RMerlin]

To those with Wifi issues, sorry to sound like a broken record at this point, but for those who didn't yet - did you disable Airtime Fairness as recommended in the changelog?

I would also disable universal beamforming and MU-MIMO, as recommended in multiple posts, as these are either non-standard or flat out broken, and will also have compatibility issues with some clients.

 

[Goran]

Yes, gone through all posts, all mentioned disabled, fixed channel ...
Never before expirienced issues with 5GHz until .67 beta and flashed every beta and final from .65.

Not complaining but just giving feedback.