Known issue as indicated earlier, you will need to retest that after I apply the latest DDNS patches from Asus.Ok, When IPv6 is enabled, I will not be able to register DDNS
Contacting Asus about this won't do anything. It's currently a technical issue, and both Asus and Broadcom are involved. Until they resolve this, nothing that can be done.@RMerlin What's the best forum/email to write to Asus that what's holding me (and others I know) from upgrading to AXE11000 is the lack of your support?
The only change is how this is stored in nvram. Functionality is 100% identical to 386.3.could you please clarify what the new hostname implementation means,
Dec 20 09:40:00 lldpd[2173]: removal request for address of 10.8.0.1%107, but no knowledge of it
Those are normal messages. It just means that lldpd has noticed that interface 10.8.0.1 has disappeared, probably because the WAN interface has gone down. 10.8.0.1 is usually a VPN interface.Several times lost internet connectivity on wired and wireless devices in the last 24 hours
No idea whether it is related, but I see this in the system log:
Code:Dec 20 09:40:00 lldpd[2173]: removal request for address of 10.8.0.1%107, but no knowledge of it
What does this mean?
Note: I use 192.168.x.y (not 10.a.b.c) locally...
This range is used by the OVPN Server on your router at least it is on mine.Dec 20 09:40:00 lldpd[2173]: removal request for address of 10.8.0.1%107, but no knowledge of it
Did all of those things:FYI. the disconnected bug due to the dns query stuff. you only need to enable it and add the dns info back into the entry box (or commit to nvram in shell) , reboot, then you can turn dns query back off and it still works correctly. at least in my case. dirty flashed from alpha2 to beta1
hosts
file into dnsmasq.conf
the router will not resolve any of these names if they are unqualified unless the device has already obtained its lease via DHCP.nslookup nuc
) the command will fail because the hosts
file doesn't contain a matching unqualified entry. fprintf(fp, "%s %s.%s\n", ip, hostname, lan_domain);
fprintf(fp, "%s %s %s.%s\n", ip, hostname, hostname, lan_domain);
FYI. the disconnected bug due to the dns query stuff. you only need to enable it and add the dns info back into the entry box (or commit to nvram in shell) , reboot, then you can turn dns query back off and it still works correctly. at least in my case. dirty flashed from alpha2 to beta1
Reported on this in the 386.4 alpha tread with these lines:Did all of those things:
View attachment 37914
dns.msftnci.com probes:
To permanently disable the probing enter this into the terminal, probing will stop immediately:
Code:
nvram set dns_probe=0;nvram set dns_probe_content=;nvram commit
To restore it, enter this:
Code:
nvram set dns_probe=0;nvram set dns_probe_content='131.107.255.255 112.4.20.71 fd3e:4f5a:5b81::1';nvram commit
Okay, it's back, and thanks! Did this, per your instruction:Reported on this in the 386.4 alpha tread with these lines:
The first line disable the probes and you will get internet status : disconnected in router gui Network Map tab but internet is still workning..Code:dns.msftnci.com probes: To permanently disable the probing enter this into the terminal, probing will stop immediately: Code: nvram set dns_probe=0;nvram set dns_probe_content=;nvram commit To restore it, enter this: Code: nvram set dns_probe=0;nvram set dns_probe_content='131.107.255.255 112.4.20.71 fd3e:4f5a:5b81::1';nvram commit
(Think the dns.msftnci.com probes is now needed for displaying internet status: connected from now on)
Did some more testing in the router gui in administration/system tab "Network Monitoring" unchecking the DNS Query box does not disable the probes when i check dnsmasq.log (same after rebooting the router also)
Thank you so much, I think a custom script may be able to achieve my needs.You can override what Ip address detection methods gets used to register your ddns using custom scripts. Unfortunately certain environments may require users to do such. Where asuswrt may not be flexible in this regards, asuswrt-merlin branch is. Inadyn is very flexible in this regards. I suggest you take a look at the custom scripts wiki specifically sections that talk about ddns services. As for registering two addresses at the same time, it really all depends on your ddns service and whether inadyn will send them both in the same configuration segment. For dynv6, I have to do two separate instances, one for ipv4 and one for ipv6 to assure both get properly registered. I tried to do both at the same instance, but what would happen is only the first request would get sent, -i.e. if ipv4 was sent to go first, it would be the only one that got registered because inadyn saw it as successful ( or not needed if it didn't change) and did not finish the operation by updating the ipv6..
Since so many users seem to have messed with that parameter and are now flooding both this beta thread and the official Asuswrt threads about non-working notification, and that monitoring can no longer be disabled, I am considering hardcoding a default server to be used whenever that nvram is missing or empty.Reported on this in the 386.4 alpha tread with these lines:
The first line disable the probes and you will get internet status : disconnected in router gui Network Map tab but internet is still workning..Code:dns.msftnci.com probes: To permanently disable the probing enter this into the terminal, probing will stop immediately: Code: nvram set dns_probe=0;nvram set dns_probe_content=;nvram commit To restore it, enter this: Code: nvram set dns_probe=0;nvram set dns_probe_content='131.107.255.255 112.4.20.71 fd3e:4f5a:5b81::1';nvram commit
(Think the dns.msftnci.com probes is now needed for displaying internet status: connected from now on)
Did some more testing in the router gui in administration/system tab "Network Monitoring" unchecking the DNS Query box does not disable the probes when i check dnsmasq.log (same after rebooting the router also)
19:43:27 dnsmasq[6768]: query[A] dns.msftncsi.com from 127.0.0.1
19:43:27 dnsmasq[6768]: cached dns.msftncsi.com is 131.107.255.255
19:43:42 dnsmasq[6768]: query[A] dns.msftncsi.com from 127.0.0.1
19:43:42 dnsmasq[6768]: cached dns.msftncsi.com is 131.107.255.255
19:43:47 dnsmasq[6768]: query[A] dns.msftncsi.com from 127.0.0.1
19:43:47 dnsmasq[6768]: cached dns.msftncsi.com is 131.107.255.255
I think Asus is now starting to support IPv6 [1]. Of course, we may need to wait for beta 2 to know, because I can confirm that 386.3_2 and previous firmware does not support it. 386.4 beta 1 cannot use this feature due to some problems.no IPv6 / DDNS with Asus.
nslookup www.asuscomm.com
, this is Asus's own url, and you can see that their server has IPv6.Have you ever tried another DDNS provider on your 386.3_2 firmware? EG No IP? That would rule out one area of concern / suspicion wouldn't it? That setup works for me i.e. FTTH and IPv4 / IPv6 from my ISP but no CGNAT remember and then DDNS IPv4 / IPv6 from No IP not Asus. I think we're using the same router too FWIW
expect to have a working routable ipv6 internet connection coming from your openvpn tunnel
You are right, please forgive me, this thread is full of noise from me. so sorry. I won't do this anymore, I will test it in next beta version.Can I respectfully suggest that you refrain from posting speculations in this thread and just report actual issues/bugs discovered with this beta. That way RMerlin can see the wood for the trees.
Can I respectfully suggest that you refrain from posting speculations in this thread and just report actual issues/bugs discovered with this beta. That way RMerlin can see the wood for the trees.Another hypothesis waiting to be tested:
If I connect to my home network through an IPv6 tunnel, will it IPv6 to IPv4 locally? For example, can I ping 192.168.50.0/24 through the OpenVPN tunnel?
And, if the OpenVPN server does not route IPv6, will it route IPv4? So I can make a 6to4 internet connection through this IPv6 tunnel?
octopus@RT-AX86U-EA08:/tmp/home/root# cat /jffs/nmp_vc_json.js
{"04:8C:9A:xx:xx:xx":{"mac":"04:8C:9A:xx:xx:xx","vendorclass":"HUAWEI:android:VOG"},"88:3D:24:xx:xx:xxx":{"mac":"88:3D:24:xx:xx:xx","vendorclass":"dhcpcd-6.8.2:Linux-3.8.13+:armv7l:Marvell"},"A08:07:xx:xx:xx":{"mac":"A08:07:xx:xx:xx","vendorclass":"HUAWEI:android:VOG"},"38:0B:40:xx:xx:xx":{"mac":"38:0B:40:xx:xx:xx","vendorclass":"dhcpcd-5.5.6"},"D4:5D:64:xx:xx:xx":{"mac":"D4:5D:64:xx:xx:xx","vendorclass":"MSFT 5.0"}}octopus@RT-AX86U-EA08:/tmp/home/root#
What I'm struggling to understand is why the Network Monitoring > DNS Query check box even exists if un-checking it doesn't actually stop it (because its function is now mandatory). Maybe the checkbox should be removed and the Resolve Hostname/IP Addresses fields left permanently enabled (similar to the NTP Server field), and those fields cannot be null. Just a thought.Since so many users seem to have messed with that parameter and are now flooding both this beta thread and the official Asuswrt threads about non-working notification, and that monitoring can no longer be disabled, I am considering hardcoding a default server to be used whenever that nvram is missing or empty.
I noticed the same message after doing a factory reset + initialise, because that deletes the file. By the time I logged into the router the file had been recreated and I never saw the message again.After a couple of days i dicivered this, same in all Alpha builds. This is Beta1
Dec 20 19:50:04 dnsmasq-script[3270]: json_object_from_file: error opening file /jffs/nmp_vc_json.js: No such file or directory
But it's there:
I saw that after I rebooted after I have messed with Aimesh. File is there but dnsmasq seem not catch it.I noticed the same message after doing a factory reset + initialise, because that deletes the file. By the time I logged into the router the file had been recreated and I never saw the message again.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!