What's new

[Release] Asuswrt-Merlin 384.6 is now available

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

I already knew it, but I was hoping that you with the experience already acquired, could find the cause of that problem and fix.

Can you compare the iptables of both, because for me it is not an error of Adaptive QoS, I think the error is in the OpenVPN iptables and only in L2TP are well configured or maybe you find the problem when comparing them.
Iptables has nothing to do with routing/packet accounting.

Sent from my P027 using Tapatalk
 
Coming from an old version, the update went smooth without any problems on my AC88U. Factory reset also done.

At the moment I´m fighting with the OpenVPN Server - The iPhone App tries to connect the router but the connection will not be established.
Any idea what I´m doing wrong?

thx

From the log-file:
2018-08-14 20:18:21 EVENT: RESOLVE
2018-08-14 20:18:21 Contacting [xxxxx]:1194/UDP via UDP
2018-08-14 20:18:21 EVENT: WAIT
2018-08-14 20:18:21 Connecting to [xxxxx]:1194 (xxxxxx) via UDPv4
2018-08-14 20:18:22 EVENT: CONNECTING
2018-08-14 20:18:22 Tunnel Options:V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client
2018-08-14 20:18:22 Creds: Username/Password
2018-08-14 20:18:22 Peer Info:
IV_GUI_VER=net.openvpn.connect
.ios 1.2.9-0
IV_VER=3.2
IV_PLAT=ios
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_LZO=1

2018-08-14 20:18:23 VERIFY OK : depth=0
cert. version : 3
serial number : 01
issuer name : C=TW, ST=TW, L=Taipei, O=ASUS, CN=RT-AC88U, emailAddress=me@myhost.mydomain
subject name : C=TW, ST=TW, L=Taipei, O=ASUS, CN=RT-AC88U, emailAddress=me@myhost.mydomain
issued on : 2018-08-12 18:30:53
expires on : 2028-08-09 18:30:53
signed using : RSA with SHA-256
RSA key size : 1024 bits
basic constraints : CA=false
cert. type : SSL Server
key usage : Digital Signature, Key Encipherment
ext key usage : TLS Web Server Authentication
 
Well as you can see it returned 192.168.1.27 which is the thing that rebind protection should stop. So if you issue the same command again but this time use your router's DNS it should not return that address:
Code:
# nslookup a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network 192.168.1.1

Server:    192.168.1.1
Address 1: 192.168.1.1 router.asus.com

nslookup: can't resolve 'a.34.192.228.43.1time.192.168.1.27.forever.1343173a-5e69-4bc9-b767-2b82212c1221.rebind.network'

This works for me now I see this output when I run the command from the router.
 
So after @14 days uptime (flashed on zero day) of this build operating on my AC86U gateway router, I have lost access to the web GUI at the router's IP address of 192.168.1.1

Tried from multiple computers either IE or chrome (wired&wireless) but http://192.168.1.1 now fails to respond and times out.

Still able to ping 192.168.1.1, ssh into 192.168.1.1 and reach my full 1Gbps up/down throughput as well as the OpenVPN server tunnel(s) never lost connectivity. AC86U otherwise seems unaffected short of the web GUI is now unresponsive.

Does anyone know if there happens to be a command I could execute via ssh in order to just reset the web GUI yet leave the router uptime and other relevant stats intact?


Well, another 6 days later the web GUI has no response again while everything else functions normally.

Issued another service restart_httpd command via ssh and it immediately makes it responsive.
Seems I may be the only one experiencing this specific problem w/this build on my AC86U:rolleyes:
 
I upgraded to 384.6 on my RT-AC68U at the end of July, and then discovered a few days later that the date/time on my router was wrong. I tried some reboots and forced NTP client restarts, etc, but the time would never update. I flashed back to 384.5, and the time was immediately updated properly. I have not made any attempt to go back to 384.6 because of this issue. Not sure if others have noticed this, or if I'm a one-off for some reason, but thought I'd post here in case it warrants looking into.
 
Well, another 6 days later the web GUI has no response again while everything else functions normally.

Issued another service restart_httpd command via ssh and it immediately makes it responsive.
Seems I may be the only one experiencing this specific problem w/this build on my AC86U:rolleyes:
This only ever happens to me when I'm logged in and on the QoS statistics tab and leave it on too long.

Does this happen when you're in the GUI exclusively, or does it lock you out when you're not in it too?
 
I upgraded to 384.6 on my RT-AC68U at the end of July, and then discovered a few days later that the date/time on my router was wrong. I tried some reboots and forced NTP client restarts, etc, but the time would never update. I flashed back to 384.5, and the time was immediately updated properly. I have not made any attempt to go back to 384.6 because of this issue. Not sure if others have noticed this, or if I'm a one-off for some reason, but thought I'd post here in case it warrants looking into.
Try 384.7 alpha 1, I’ve been running it on my AC68U for a couple of weeks and it’s been solid, I do have a minimal setup though but I’ve had no problems.
 
This only ever happens to me when I'm logged in and on the QoS statistics tab and leave it on too long.

Does this happen when you're in the GUI exclusively, or does it lock you out when you're not in it too?

It has happened 2x now when I am not logged in and have left no browser opened to http://192.168.1.1/
Seems completely random and never occurred when I was operating on the previous test build since the beginning of July prior to updating to this final release.
 
Well, another 6 days later the web GUI has no response again while everything else functions normally.

Issued another service restart_httpd command via ssh and it immediately makes it responsive.
Seems I may be the only one experiencing this specific problem w/this build on my AC86U:rolleyes:

OK, I'm wading in here without reading the entire thread, so I might have to take a light beating, but I found that I'm having Web GUI problems in Firefox lately, that I never had before. But Internet Explorer continues to work just fine! (Windows 10 with current updates and Firefox Quantum 60+)
 
OK, I'm wading in here without reading the entire thread, so I might have to take a light beating, but I found that I'm having Web GUI problems in Firefox lately, that I never had before. But Internet Explorer continues to work just fine! (Windows 10 with current updates and Firefox Quantum 60+)

That is not the issue I have been experiencing under 384.6

All browsers including ie, chrome, firefox, ect can no longer access web gui from multiple computers x4 I have tried but issue is resolved immediately upon executing service restart_httpd
 
That is not the issue I have been experiencing under 384.6

All browsers including ie, chrome, firefox, ect can no longer access web gui from multiple computers x4 I have tried but issue is resolved immediately upon executing service restart_httpd
Seen this a lot on mine and there are some threads about it. But I think I never saw it again with last 384.32683 on my 86U, so let us hope they solved it in future releases.
 
Hi,
Installed 384.6 on my Japanese AC86U. Interestingly, the interface switched back to Japanese (although it was set to English with the previous release), and I cannot switch it back to English anymore (when I click the language button, no menu drops down).
Also, the web GUI crashes quite often, but it restarts automatically. I.e. I frequently just lose GUI for several seconds, and then it works again...
 
Hi,
Installed 384.6 on my Japanese AC86U. Interestingly, the interface switched back to Japanese (although it was set to English with the previous release), and I cannot switch it back to English anymore (when I click the language button, no menu drops down).
Also, the web GUI crashes quite often, but it restarts automatically. I.e. I frequently just lose GUI for several seconds, and then it works again...
There seems to be no more language selection on Japanese model, my Chinese one lost all languages too except Chinese and English with last stock firmware (nothing related to Merlin).
For other problems make a factory reset and intialize. Maybe you'd better take 384.7-alpha1 from August, seems to be more stable: https://onedrive.live.com/?authkey=!AGY2taGX02nVmWA&id=CCE5625ED3599CE0!1427&cid=CCE5625ED3599CE0
 
There seems to be no more language selection on Japanese model, my Chinese one lost all languages too except Chinese and English with last stock firmware (nothing related to Merlin).
For other problems make a factory reset and intialize. Maybe you'd better take 384.7-alpha1 from August, seems to be more stable: https://onedrive.live.com/?authkey=!AGY2taGX02nVmWA&id=CCE5625ED3599CE0!1427&cid=CCE5625ED3599CE0

Oh, thanks, I'll try the alpha version. This is curious - I know that there's no language selection in the Japanese stock firmware, but it's really surprising that it also doesn't work with the latest Merlin's one. I rolled back to 384.5, and English is still there...
 
This is curious - I know that there's no language selection in the Japanese stock firmware, but it's really surprising that it also doesn't work with the latest Merlin's one. I rolled back to 384.5, and English is still there...

Merlin wont touch this part of AsusWRT.
 
Merlin wont touch this part of AsusWRT.

More like I can't touch it any longer. I used to, but now Asus has moved that code to a closed source component specifically to prevent bypassing it...
 
I added an option to toggle dnssec's strict mode. To be honest, the more I think about it (and the more I discuss it with others), the more I think this option makes little sense. Disabling strict mode makes DNSSEC pretty much useless, since to bypass it one would simply need to craft a reply without any signature, which then would not be validated by dnsmasq.

I'll give it some more time to think about it, but I'm still considering going back on this.
 
I added an option to toggle dnssec's strict mode. To be honest, the more I think about it (and the more I discuss it with others), the more I think this option makes little sense. Disabling strict mode makes DNSSEC pretty much useless, since to bypass it one would simply need to craft a reply without any signature, which then would not be validated by dnsmasq.

I'll give it some more time to think about it, but I'm still considering going back on this.
I originally added it on my fork to be able to 'set' the option, exactly for the reasons you said. Now I consider it more of a diagnostic tool that should not be left disabled. (i.e. you can disable it, run a check on a DNSSEC test site to make sure DNSSEC is working, and it is indeed just a specific site or sites that are failing).
 
I added an option to toggle dnssec's strict mode. To be honest, the more I think about it (and the more I discuss it with others), the more I think this option makes little sense. Disabling strict mode makes DNSSEC pretty much useless, since to bypass it one would simply need to craft a reply without any signature, which then would not be validated by dnsmasq.

I'll give it some more time to think about it, but I'm still considering going back on this.

I agree, DNSSEC support should surely be transparently ‘on’, or ‘off’.
Catering for various resolvers apparent inability to implement DNSSEC properly can only end in tears.
Just my 10 cents worth....
 

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