[beta] Asuswrt-Merlin 384.17 beta is out

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.
Status
Not open for further replies.

SheikhSheikha

Regular Contributor
384.17_beta1 causes a problem with L2TP VPN Client.
On boot the L2TP VPN Client kicks in as normal. When changing the client node internet access is blocked even though the client demonstrates to be active (checkmark). Turning off the VPN client gives non-VPN access to the web (it gives non VPN traffic) but turning on the VPN Client causes all traffic to be blocked again. Only a reboot of the router will let this other Node kick in. Switching Node after this reboot causes the blocking to start all over again.
I have extensively tried several scenario's but as soon as I moved back to 384.16 the L2TP VPN client worked normal again .............
So I found what might have caused the above. On flashing 384.17_beta1 apparently the tools/settings/memory management was switched to On. (apparently a glitch while flashing) (which is always off in my settings). With a clean install I had forgotten to switch it off (a glitch from my side).
With identifying the above I think I found the cause of the problems I mentioned above and with this message I revoke my remark.
 

maghuro

Very Senior Member
@RMerlin
OVPN
Despite I have a couple of ciphers defined, I'm getting that error on logs:
Code:
WARNING: 'cipher' is used inconsistently, local='cipher [null-cipher]', remote='cipher AES-256-CBC'
Also, I think most of GUI options aren't be sent. Only if I manually write them in the box on the bottom of page.
 

Attachments

Last edited:

octopus

Very Senior Member
I can't reproduce here. I just successfully sent an email through my ISP's SMTP, using STARTTLS.

What happens when you enable verbose logging (by adding the -v switch)?
Hi
Tested with 384.16_0 and 384.17_beta1 and se some differences. I hope you can se what problem is........:oops:
Code:
curlsend(){
/usr/sbin/curl -s -S -4 -v --interface $INFACE \
--url smtps://$SMTP:$PORT \
--ssl-reqd \
--mail-auth $USERNAME \
--user "$USERNAME:$PASSWORD" \
--mail-from $FROM_ADDRESS \
--mail-rcpt $TO_1 \
--mail-rcpt $TO_2 \
--upload-file /tmp/mail.txt
}
384.16_0
Code:
*   Trying 64.233.165.108:465...
* TCP_NODELAY set
* Connected to smtp.gmail.com (64.233.165.108) port 465 (#0)
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [87 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2335 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [147 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=smtp.gmail.com
*  start date: Apr  1 12:57:16 2020 GMT
*  expire date: Jun 24 12:57:16 2020 GMT
*  subjectAltName: host "smtp.gmail.com" matched cert's "smtp.gmail.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.
{ [5 bytes data]
< 220 smtp.gmail.com ESMTP v7sm3751651lfq.55 - gsmtp
} [5 bytes data]
> EHLO mail.txt
{ [5 bytes data]
< 250-smtp.gmail.com at your service, [194.68.170.158]
< 250-SIZE 35882577
< 250-8BITMIME
< 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
< 250-ENHANCEDSTATUSCODES
< 250-PIPELINING
< 250-CHUNKING
< 250 SMTPUTF8
} [5 bytes data]
> AUTH PLAIN
{ [5 bytes data]
< 334
} [5 bytes data]
> AGpvaGF<<< === >>>WlsbXly
{ [5 bytes data]
< 235 2.7.0 Accepted
} [5 bytes data]
> MAIL FROM:<[email protected]> [email protected] SIZE=442
{ [5 bytes data]
< 250 2.1.0 OK v7sm3751651lfq.55 - gsmtp
} [5 bytes data]
> RCPT TO:<[email protected]>
{ [5 bytes data]
< 250 2.1.5 OK v7sm3751651lfq.55 - gsmtp
} [5 bytes data]
> RCPT TO:<[email protected]>
{ [5 bytes data]
< 250 2.1.5 OK v7sm3751651lfq.55 - gsmtp
} [5 bytes data]
> DATA
{ [5 bytes data]
< 354  Go ahead v7sm3751651lfq.55 - gsmtp
} [5 bytes data]
* We are completely uploaded and fine
} [5 bytes data]
< 250 2.0.0 OK  1587710748 v7sm3751651lfq.55 - gsmtp
* Connection #0 to host smtp.gmail.com left intact
384.17_beta1
Code:
*   Trying 64.233.161.108:465...
* Connected to smtp.gmail.com (64.233.161.108) port 465 (#0)
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [87 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2335 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [148 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES128-GCM-SHA256
* Server certificate:
*  subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=smtp.gmail.com
*  start date: Apr  1 12:57:16 2020 GMT
*  expire date: Jun 24 12:57:16 2020 GMT
*  subjectAltName: host "smtp.gmail.com" matched cert's "smtp.gmail.com"
*  issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
*  SSL certificate verify ok.
{ [5 bytes data]
< 220 smtp.gmail.com ESMTP a21sm4228414ljn.57 - gsmtp
} [5 bytes data]
> EHLO mail.txt
{ [5 bytes data]
< 250-smtp.gmail.com at your service, [194.68.170.131]
< 250-SIZE 35882577
< 250-8BITMIME
< 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
< 250-ENHANCEDSTATUSCODES
< 250-PIPELINING
< 250-CHUNKING
< 250 SMTPUTF8
} [5 bytes data]
> AUTH PLAIN
{ [5 bytes data]
< 334
} [5 bytes data]
> AGpvaGF<<< === >>>WlsbXly
{ [5 bytes data]
< 235 2.7.0 Accepted
} [5 bytes data]
> QUIT
{ [5 bytes data]
< 221 2.0.0 closing connection a21sm4228414ljn.57 - gsmtp
* Closing connection 0
} [5 bytes data]
* TLSv1.2 (OUT), TLS alert, close notify (256):
} [2 bytes data]
curl: (27) Out of memory
@RMerlin
 
Last edited:

RMerlin

Asuswrt-Merlin dev
The reworked network meter seems to stop working randomly.
A reboot solves issue, but it comes back with no warning.
Open your browser console and look for a Javascript error.
 

RMerlin

Asuswrt-Merlin dev
@RMerlin
OVPN
Despite I have a couple of ciphers defined, I'm getting that error on logs:
Code:
WARNING: 'cipher' is used inconsistently, local='cipher [null-cipher]', remote='cipher AES-256-CBC'
Also, I think most of GUI options aren't be sent. Only if I manually write them in the box on the bottom of page.
This is "normal", it's just that OpenVPN using NCP, and then complaining about config mis-matches caused by NCP itself. Just ignore it.

Also, I think most of GUI options aren't be sent. Only if I manually write them in the box on the bottom of page.
Works for me. And nothing has been changed in quite some time to the OpenVPN webui.
 

AntonK

Senior Member
There appears to be an updated beta release for the 88U. What was changed, if anything?

Anton
 

L&LD

Part of the Furniture
@AntonK the installer. The fix from the previous version suddenly didn't work on Beta 1, but now it does. :)

Just make sure you are using the unzipped file (its the latest/fixed one). :)
 

laracroftonline

Regular Contributor
Open your browser console and look for a Javascript error.
I got these errors

Code:
content.js:4 [Deprecation] chrome.loadTimes() is deprecated, instead use standardized API: nextHopProtocol in Navigation Timing 2. https://www.chromestatus.com/features/5637885046816768.
(anonymous) @ content.js:4
content.js:5 [Deprecation] chrome.loadTimes() is deprecated, instead use standardized API: nextHopProtocol in Navigation Timing 2. https://www.chromestatus.com/features/5637885046816768.
(anonymous) @ content.js:5
jquery.js:5 [Deprecation] Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/.
send @ jquery.js:5
basic.css:1 Failed to load resource: the server responded with a status of 404 (Not Found)
basic.css:1 Failed to load resource: the server responded with a status of 404 (Not Found)
 

AntonK

Senior Member
@AntonK the installer. The fix from the previous version suddenly didn't work on Beta 1, but now it does. :)

Just make sure you are using the unzipped file (its the latest/fixed one). :)
Thanks!
 

Asad Ali

Very Senior Member
@AntonK the installer. The fix from the previous version suddenly didn't work on Beta 1, but now it does. :)

Just make sure you are using the unzipped file (its the latest/fixed one). :)
Just one request which has nothing to do with Asuswrt but with general forum etiquette. If possible instead of simply mentioning the user's name kindly quote the relevant post when you reply because a third person reading your replies will have to go back all the previous replies in the thread to find out what you're talking about.
 

maghuro

Very Senior Member
This is "normal", it's just that OpenVPN using NCP, and then complaining about config mis-matches caused by NCP itself. Just ignore it.
So even if I define a cipher through Gui, it won't be asked to te server? Will I have to manually set it via custom config textbox? Weird..
 

RMerlin

Asuswrt-Merlin dev
There appears to be an updated beta release for the 88U. What was changed, if anything?

Anton
Just the firmware header, so it will be accepted by newer stock firmware.
 

RMerlin

Asuswrt-Merlin dev

RMerlin

Asuswrt-Merlin dev
So even if I define a cipher through Gui, it won't be asked to te server? Will I have to manually set it via custom config textbox? Weird..
It depends if you use NCP or not. There are two parameters that can be adjusted: the old, single cipher parameter, and a separate list of ciphers that will be offered over NCP. If the remote server also supports NCP, then the negotiation will be done based on the NCP list (first cipher available in the list on both ends will be used). If not, the fallback will be the legacy cipher parameter.

Make sure that both ends support NCP before enabling it (since it's now 2020, I would expect pretty much everything to support NCP by now).
 

RMerlin

Asuswrt-Merlin dev
Hi
Tested with 384.16_0 and 384.17_beta1 and se some differences. I hope you can se what problem is........:oops:
The issue seem to be server-specific. It works with my ISP SMTP, but fails with GMail.

I opened an issue on the Curl bug tracker, we'll see if Bagder has a quick fix, if not, I will revert back to 7.68.0 for now.
 

octopus

Very Senior Member
The issue seem to be server-specific. It works with my ISP SMTP, but fails with GMail.

I opened an issue on the Curl bug tracker, we'll see if Bagder has a quick fix, if not, I will revert back to 7.68.0 for now.
Thanks :)
 

maghuro

Very Senior Member
It depends if you use NCP or not. There are two parameters that can be adjusted: the old, single cipher parameter, and a separate list of ciphers that will be offered over NCP. If the remote server also supports NCP, then the negotiation will be done based on the NCP list (first cipher available in the list on both ends will be used). If not, the fallback will be the legacy cipher parameter.

Make sure that both ends support NCP before enabling it (since it's now 2020, I would expect pretty much everything to support NCP by now).
AirVPN, I think it supports.
However, I have the list of ciphers set and that error (no local cipher) ocurrs.
Also I have the legacy cipher set, however on the log keeps showing that error message that I haven't no cipher.
 

L&LD

Part of the Furniture
Just one request which has nothing to do with Asuswrt but with general forum etiquette. If possible instead of simply mentioning the user's name kindly quote the relevant post when you reply because a third person reading your replies will have to go back all the previous replies in the thread to find out what you're talking about.
Of course, I do when my post isn't the very next one. :)

But in cases (such as my reply here), I do quote the original when several other replies are in-between. :)
 
Status
Not open for further replies.

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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