[Release] Asuswrt-Merlin 384.7 is now available

[D34DC3N73R]

Depends how you are configuring it. If it's configured through the webui, then it's all transparent. Only people using custom scripts will need to adapt them.

I'm using the AC88U and have held off on the update after seeing the ddns bits in the changelog. I currently use cloudflare and my script is fairly close to the example with the exception of getting my wan ip with IP="$(nvram get wan0_ipaddr)" Will that continue to work or will I have to adapt that part?

I'm also a dnscrypt user and saw mention of dns over tls being implemented in this thread. Is that the case? And if so, is there any reason to continue running dnscrypt?

 

[Skeptical.me]

AsusDDNS doesn't log anything beside your IP address, which is the same for every single DDNS service (otherwise, how else are they supposed to be able to associate your IP address with your hostname).

I see, of course, showing my inexperience again. Its taking time to learn but I'm enjoying it. Thanks for the replies. I appreciate it.

 

[JIPG]

Installed in a RT AC87U without problems (rebooted, installed everything from scratch and switched off and on). Everything seems to work OK.
I had no problem with the ntp server as someone reported (time is acquired normally).

So thank you RMerlin for a new piece of 1st class software ...

 

[IT Guy]

After I updated to 384.7 I reseted all setting and put in everything manually.

I see that I get "kernel: nvram: consolidating space!" when that happends internet dies for like 1min.
I did remove USB when I flashed the new firmware. Any ideas on what cause it?

NVRAM usage 51619 / 65536 bytes
JFFS 1.69 / 62.75 MB

Also what is this??

Oct 13 06:10:58 kernel: SKIPPED false Type 4 Radar Detection. min_pw=297 pw_delta=0 pri=15970 fm_min=1030 fm_max=0 nconsecq_pulses=5. Time from last detection = 96891, = 1614min 51sec. Detected pulse index: 0

Oct 13 06:10:58 kernel: Type 0 Radar Detection. Detected pulse index=0 fm_min=1030 fm_max=0 nconsecq_pulses=5. Time from last detection = 0, = 0min 0sec

Oct 13 06:11:16 kernel: Type 5 Radar Detection. Detected pulse index=0 fm_min=0 fm_max=0 nconsecq_pulses=6. Time from last detection = 18, = 0min 18sec

 

[ViRUS2k]

I will post my Problem again as it was clearly missed;

Im getting a log full of these entry like a billion of them flooding my log file im using the latest Beta or Final 384.7 with my RT AC88U
The issue i have is that i have IPV6 dissabled so i have no idea why im getting flooded....

----- LOG

Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:24 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:25 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:25 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:25 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:25 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address
Oct 13 14:29:25 miniupnpd[28772]: Failed to convert hostname 'fe80::290:a9ff:fed3:9ed2' to ip address

-----

Please fix this, as i have no idea how to i might have to revert back to previous version firmware.

 

[sbsnb]

Having DDNS problems with freedns.afraid.org. When I set it up on the DDNS tab I get "Registration successful" prompt, but the system log shows:

Oct 13 06:45:37 inadyn[12392]: In-a-dyn version 2.5 -- Dynamic DNS update client.
Oct 13 06:45:37 inadyn[12392]: Update forced for alias xxxxxxxx.mooo.com, new IP# x.x.x.x
Oct 13 06:45:38 inadyn[12392]: HTTP(S) Transaction failed, error 36: Temporary network error (HTTPS send)

Further up in the logs I see:

Oct 13 06:43:54 inadyn[12294]: Failed resolving hostname freedns.afraid.org: Name or service not known

But I have no problems when I nslookup freedns.afraid.org or navigate there with my browser.

EDIT - Also, my custom DDNS script to update freedns.afraid.org works fine. There's definitely an issue with inadyn.

 

[sbsnb]

May or may not be relevant that I'm running dnscrypt-proxy v2 and have all DNS requests on the LAN forced to use the router. Maybe inadyn has a hard-coded resolver and expecting some response that it's not getting from the dnscrypt servers.

 

[hervon]

@ViRUS2k : No issue with miniupnp deamon on my side. I guess you'll have to look what's wrong on yours that you clealy missed. Might be a good idea to do a clean reset.

 

[ViRUS2k]

@ViRUS2k : No issue with miniupnp deamon on my side. I guess you'll have to look what's wrong on yours that you clealy missed. Might be a good idea to do a clean reset.

I dont use IPV6 its disabled so i have no idea why the log is showing clearly a IPV6 address that obviously cant be converted to a ip address as my broadband talktalk does not do IPV6 yet.

 

[RMerlin]

I'm using the AC88U and have held off on the update after seeing the ddns bits in the changelog. I currently use cloudflare and my script is fairly close to the example with the exception of getting my wan ip with IP="$(nvram get wan0_ipaddr)" Will that continue to work or will I have to adapt that part?

I'm also a dnscrypt user and saw mention of dns over tls being implemented in this thread. Is that the case? And if so, is there any reason to continue running dnscrypt?

That script should work just as before, since it relies on curl to trigger the update.

Oct 13 06:10:58 kernel: SKIPPED false Type 4 Radar Detection. min_pw=297 pw_delta=0 pri=15970 fm_min=1030 fm_max=0 nconsecq_pulses=5. Time from last detection = 96891, = 1614min 51sec. Detected pulse index: 0

DFS channels require active radar monitoring. You are in a region that supports DFS channel, so ideally just try to avoid using these channels.

I will post my Problem again as it was clearly missed;

Typically caused by some WD network devices that don't supply proper information. Sometimes rebooting the WD device will fix it.

Further up in the logs I see:

If you have DNSSEC enabled try disabling it, in case it's a problem with your WAN DNS server not properly supporting it.

 

[ViRUS2k]

Typically caused by some WD network devices that don't supply proper information. Sometimes rebooting the WD device will fix it.

WOW rebooting / powering off and on my WD NAS fixed it, strange that, thats what caused it..

cheers.

 

[HarryH3]

Is it possible to use admin login passwords (web GUI) longer than 17 chars? The web GUI seems to only accept up to 17 chars for passwords. I'm running Merlin 384.7.

Just in case you didn't catch it, Merlin hinted at a solution in his earlier reply:

"There's nothing weak about a 16 character username combined with a 16 characters password. It would take years to get through the number of variations possible with a combination of 32 different characters."

Don't use the default "Admin" as the Router Login Name for router access. You can change it to anything that you want from the Administration -> System page. Now an attacker has to try to guess both the login name AND the password to hack their way in. That makes it orders of magnitude more difficult.

 

[krozar]

Looks like the NTP client is broken on the AC68U, at least. I also reported this issue with 384.6, and it appears to still be broken in 384.7. Looks like some others reported NTP issues on page 7 for this thread, as well. I'm reverting back to 384.5 again, where I know it works.

 

[BGood]

This still being pretty new to me, I just flashed from AC5300_384.4_2 to AC5300_384.7_0. The release notes recommend doing a factory default:
Updating from a firmware version that is more than 3 releases older. So on the downloads page it appears that this is the 4th release after the one I was on, so I should factory reset and start from scratch? Or is 384.42 to 384.70 still within the 384 release "family" (if there is such a thing), meaning I can skip the reset? So far everything *seems* to be working, but I don't want to get this wrong.

Thanks.

 

[scjr]

This still being pretty new to me, I just flashed from AC5300_384.4_2 to AC5300_384.7_0. The release notes recommend doing a factory default:
Updating from a firmware version that is more than 3 releases older. So on the downloads page it appears that this is the 4th release after the one I was on, so I should factory reset and start from scratch? Or is 384.42 to 384.70 still within the 384 release "family" (if there is such a thing), meaning I can skip the reset? So far everything *seems* to be working, but I don't want to get this wrong.

Thanks.

If everything is running fine, you’re good. If you detect any weirdness later on, then factory reset.

 

[JIPG]

Looks like the NTP client is broken on the AC68U, at least. I also reported this issue with 384.6, and it appears to still be broken in 384.7. Looks like some others reported NTP issues on page 7 for this thread, as well. I'm reverting back to 384.5 again, where I know it works.

It has been also reported for the RT AC87U, but I have installed 384.7 and it works flawlessly (with es.pool.ntp.org).
I always recommend to install new fw from scratch, initializing the router and with a final off/on cycle. I never had a problem doing it in this way.

 

[y2k se]

Running 384.7 on my RT-AC3100, the 2.4 GHz radio is reporting a temperature of 800896076 °C. The 5 GHz and CPU temperatures are reasonable.

 

[M@rco]

Looks like the NTP client is broken on the AC68U, at least. I also reported this issue with 384.6, and it appears to still be broken in 384.7. Looks like some others reported NTP issues on page 7 for this thread, as well. I'm reverting back to 384.5 again, where I know it works.

No issues with NTP here.

Upgraded to 384.7 from beta 3, all working fine except for the common issues with USB3. Is the USB3 driver closed source or is there room for improvement @RMerlin? It seems to recognize drives randomly sometimes but most of the time it fails. According to syslog it doesn't even try to mount it, it doesn't detect the device being connected. However, when it does recognize a USB3 drive on the USB3 port (in USB3 mode), it looks like the USB2 light on the front is blinking while mounting the drive (regardless whether there's a USB2 drive mounted too). It's kinda frustrating that I've purchased 4 USB3 64GB drives over the past months and none of them can be used as USB3.

 

[RMerlin]

Is the USB3 driver closed source or is there room for improvement @RMerlin?

It's just a generic Linux kernel driver.

 

[M@rco]

It's just a generic Linux kernel driver.

That actually surprises me, seeing several people reporting issues with their USB3 thumb drives on the forum. I have no issues mounting any of these thumb drives on any of Linux distros I'm using (Ubuntu, Mint, Debian and Kali), only on my router. The distros however are using a 4.x kernel. It's not specific to 384.7 though, I've had issues with it for as long as I've been using your firmware (about 10 months now, never really used stock, can't remember which version I first used). It would be nice if one could use the benefit of USB3 on their routers as well.