[Beta] Asuswrt-Merlin 384.7 Beta is now available

[Makaveli]

Testing Comcast IPv6 at: http://ipv6-test.com/
Got only 17 of 21 readiness with Beta 2 (19 of 21 with earlier version) with this message in error report:
Your router or firewall is filtering ICMPv6 messages sent to your computer. An IPv6 host that cannot receive ICMP messages may encounter problems like some web pages loading partially or not at all.

That error is not related to the firmware.

you have to allow ICMP packets through the windows firewall.

https://www.howtogeek.com/howto/win...-request-through-your-windows-vista-firewall/

 

[TheOldMan]

Testing Comcast IPv6 at: http://ipv6-test.com/
Got only 17 of 21 readiness with Beta 2 (19 of 21 with earlier version) with this message in error report:
Your router or firewall is filtering ICMPv6 messages sent to your computer. An IPv6 host that cannot receive ICMP messages may encounter problems like some web pages loading partially or not at all.

With Cox on ipv6-test.com I consistently get 19/20 on the rt-ac86u. Cox doesn't provide domain names for the ipv6.

 

[Tekneek]

I am pretty sure it has nothing to do with the firmware (or firewall on individual devices), because I saw this message and tested it also.

I am running 384.6 and getting that same Comcast Ipv6 ICMP test failure on all of my devices (Windows, MacOS, Linux, iOS). Nothing changed locally since previous successful tests. I doubt something in the firewall for every device changed.

 

[RMerlin]

Asus' ICMPv6 firewall rules follow the RFCs nearly to the letter, so it's more likely to be a firewall on the test client causing this rather than on the router itself.

 

[Alfsu]

How is your custom implemented? Were you using inadyn or some other method?

Yes, using inadyn:

/usr/sbin/inadyn -f /jffs/inadyn-changeip.conf --exec /sbin/ddns_custom_updated 1 --exec-nochg /sbin/ddns_custom_updated 1 --cache-dir=/tmp/inadyn.cache

 

[Tekneek]

Asus' ICMPv6 firewall rules follow the RFCs nearly to the letter, so it's more likely to be a firewall on the test client causing this rather than on the router itself.

I am suspecting a Comcast issue, because I tested some of my clients on a different network (non-Comcast) and they tested 19/20 as they usually did. Nothing different on my devices or router from previous 19/20 results with Comcast.

 

[ppfoong]

I am pretty sure it has nothing to do with the firmware (or firewall on individual devices), because I saw this message and tested it also.

I am running 384.6 and getting that same Comcast Ipv6 ICMP test failure on all of my devices (Windows, MacOS, Linux, iOS). Nothing changed locally since previous successful tests. I doubt something in the firewall for every device changed.

I am also running 384.6 and my ICMP is Reachable. The only 2 fails I got are hostname related, one in IPV4 and one in IPV6. Probably that website requires FQDN and will fail the test on hostname, even with DDNS working fine.

 

[Howard_inGA]

Did a warm reboot of the cable modem, router, and Win 10 PC. Now scoring 19/20. I, too, suspect a likely Comcast glitch at this point...

 

[Odkrys]

I saw multiple reports related with httpd crash in this forum.
A few months ago, I reported my solution and it never happened again really for 5 months.

https://www.snbforums.com/threads/p...5-early-test-builds.45769/page-20#post-401774

Have you considered testing it?

But I don't know why the problem has been fixed. o _o;;

 

[RMerlin]

Have you considered testing it?

I've never been able to reproduce the crash with that function, and re-reading through the code behind it a number of times I can't see anything to explain it either.

 

[dugaduga]

Dear @RMerlin, I recently updated my signatures via the browser and they had successfully updated to 2.088 from 2.066; The browser numbers reflected this... however a few hours later the browser is detecting v 2.066 once again. Checking for updates says they are up-to-date. Anyway I can determine they are in fact 2.0.88? I'm using the latest beta.

 

[Grisu]

I saw multiple reports related with httpd crash in this forum.
A few months ago, I reported my solution and it never happened again really for 5 months.

https://www.snbforums.com/threads/p...5-early-test-builds.45769/page-20#post-401774

Have you considered testing it?

But I don't know why the problem has been fixed. o _o;;

I've never been able to reproduce the crash with that function, and re-reading through the code behind it a number of times I can't see anything to explain it either.

Had this httpd crash last night again on 86U, in the morning could not connect, ssh service restart_httpd and in the moment page refreshed, same for download-master page.

 

[cristobal07]

getting this error message :

Sep 27 16:14:36 start_ddns: update WWW.TUNNELBROKER.NET default@tunnelbroker.net, wan_unit 0
Sep 27 16:14:37 inadyn[1206]: In-a-dyn version 2.4 -- Dynamic DNS update client.
Sep 27 16:14:37 inadyn[1206]: Failed resolving hostname xxxxxx (tunnel id): Name or service not known
Sep 27 16:14:37 inadyn[1206]: Update forced for alias xxxxxx (tunnel id), new IP# xx.xx.xx.xx
Sep 27 16:14:39 inadyn[1206]: Updating cache for xxxxxx (tunnel id)

but everything seems to be working fine though, DDNS registered successfully.

thanks Merlin.

 

[Alfsu]

getting this error message :

Sep 27 16:14:37 inadyn[1206]: Failed resolving hostname xxxxxx (tunnel id): Name or service not known

Try updating IP over http by adding this option to your conf file:

checkip-ssl= false

 

[skeal]

@RMerlin or anyone else. Why won't DNSSEC stop working even when it is shut off? I have had mine shut off since yesterday and it still tests as working on the DNSSEC test sites.

 

[RMerlin]

Anyway I can determine they are in fact 2.0.88?

I don't know, sorry.

@RMerlin or anyone else. Why won't DNSSEC stop working even when it is shut off? I have had mine shut off since yesterday and it still tests as working on the DNSSEC test sites.

Depends on how your network is setup most likely. That option only controls dnsmasq itself, it won't have any effect if your resolver directly connects to a remote DNS and bypasses dnsmasq.

What do you have in /etc/dnsmasq.conf? Make sure you don't have something else enabling dnssec in it.

 

[skeal]

I don't know, sorry.



Depends on how your network is setup most likely. That option only controls dnsmasq itself, it won't have any effect if your resolver directly connects to a remote DNS and bypasses dnsmasq.

What do you have in /etc/dnsmasq.conf? Make sure you don't have something else enabling dnssec in it.

I have no special settings. No dnscrypt or anything else. Just using 1.1.1.1 in the WAN DNS settings, with no DNSSEC stuff enabled. I go to https://dnssec.vs.uni-due.de/ and DNSSEC is reported as still working. Sorry @RMerlin but I ask again maybe for a simpler answer as I'm daft, why does this happen even after a reboot?

 

[john9527]

Remember, there are 3 levels of caching of DNS....
- the router (to clear, reboot)
- your browser (to clear, generally closing and re-opening your browser will clear it)
- your client (to clear, need to disconnect/reconnect the client or reboot, or for windows ipconfig /flushdns, for linux, the command would depend on your distro)

Make sure you clear all three if you are testing.

EDIT: Note that the windows ipconfig /flushdns command only affects IPv4 DNS. If you have IPv6 active you need to disconnect or reboot the client to clear the IPv6 DNS entries.

 

[RMerlin]

Sorry @RMerlin but I ask again maybe for a simpler answer as I'm daft, why does this happen even after a reboot?

Post the content of /etc/dnsmasq.conf.

 

[Treadler]

I have no special settings. No dnscrypt or anything else. Just using 1.1.1.1 in the WAN DNS settings, with no DNSSEC stuff enabled. I go to https://dnssec.vs.uni-due.de/ and DNSSEC is reported as still working. Sorry @RMerlin but I ask again maybe for a simpler answer as I'm daft, why does this happen even after a reboot?

As I understand it, those sites are only confirming that the resolver you’re using implements DNSSEC.
Whether you enable/disable DNSSEC within your router, is a seperate, local issue, with no influence on what the resolver is doing.
Enabling DNSSEC within your router just enforces/confirms that what your resolver is supplying is what is being received. The ‘last mile’ if you like.
Disclaimer: I am no expert, but this is how I think it works.....