[Beta] Asuswrt-Merlin 384.7 Beta is now available

[maxsteel]

That will be up to Asus to fix.

https://www.snbforums.com/threads/a...rt-ac86u_3-0-0-4-384-32797.48520/#post-425767

Seems fix is included with this firmware ?

 

[tdub42]

Is anyone having issues with the asus app on android. I haven't been able to get mine to find my router for a while. Any help would be greatly appreciated.

Well after nvram reset on the new version it works now. I always do this but hey it works now so no complaints.

 

[RMerlin]

https://www.snbforums.com/threads/a...rt-ac86u_3-0-0-4-384-32797.48520/#post-425767

Seems fix is included with this firmware ?

In that case it will happen when I merge 384_32797, which is currently scheduled for 384.8.

 

[Kingp1n]

In that case it will happen when I merge 384_32797, which is currently scheduled for 384.8.

@RMerlin, you're a busy guy. I really do appreciate all the efforts in making our routers 'GREAT' which is better than just good. Your FW makes that possible. I know the beta 3 is still in testing but normally from your experience, how long normally does it take to go final? Thanks again for all you do!!!!

 

[skeal]

@RMerlin, you're a busy guy. I really do appreciate all the efforts in making our routers 'GREAT' which is better than just good. Your FW makes that possible. I know the beta 3 is still in testing but normally from your experience, how long normally does it take to go final? Thanks again for all you do!!!!

The final release of 384.7 is in the immediate future. My guess...this weekend. He wants to fully test the DDNS changes he made.

 

[RMerlin]

@RMerlin, you're a busy guy. I really do appreciate all the efforts in making our routers 'GREAT' which is better than just good. Your FW makes that possible. I know the beta 3 is still in testing but normally from your experience, how long normally does it take to go final? Thanks again for all you do!!!!

Hard to say for sure, there's one last minute update to dnsmasq that I want to apply due to a resolver issue it fixes, so that's delaying the release a bit.

 

[john9527]

Hard to say for sure, there's one last minute update to dnsmasq that I want to apply due to a resolver issue it fixes, so that's delaying the release a bit.

Are you planning on adding the CERT config changes to the standard config?

EDIT: Nevermind...see you already did it

 

[bigcid10]

OK,I don't really know how to explain this but I'll take a shot at it.
I have a ac88u router with merlin's 47 b3 on it and a new upright xfinity cable modem/ac router
the new ddns is supposed to handle dual NAT i.e. cable modem in non-bridged mode
I used to have it bridged so I could use my ddns without issue
when the ddns came out in this fw of merlin's ,I was like I'll unbridge my modem and see if it works
but The ddns status is stuck on " updating"
I have a no-ip,asuscomm,and freeddns as well,they all do the same thing
Is there an answer to this issue

PS: The reason I had to unbridge my modem is because I have a wireless xfinity x1 box
it requires MOCA to work ,I tried it without MOCA and it's a PIA
Thank you

 

[RMerlin]

Are you planning on adding the CERT config changes to the standard config?

EDIT: Nevermind...see you already did it

Yeah, since it seemed quite safe to do. Themiron believes however that the fix might not be complete, in scenarios where a client might issue a FQDN instead of just "wpad", but personally I'm not sure it would allow this issue to be exploited if that were the case.

The cache fix however might possibly resolve some random resolution failures in his opinion. He's been testing it for a while, and will merge to my repo in the coming days, so I can also test it on my end.

 

[john9527]

The cache fix however might possibly resolve some random resolution failures in his opinion. He's been testing it for a while, and will merge to my repo in the coming days, so I can also test it on my end.

I'm just compiling with 2.80test7 and will give it a workout for a day or so as well.

 

[octopus]

afraid.org DDNS working fine. Update both wan and vpn1 ip-nummer with inadyn.conf.add.
Uptime 1 days 11 hours 36 minute(s) 1 seconds

When use second inadyn with "conf.add" there is no cached 2:nd ip in "ddns.cache"
I update with 2:nd with: "checkip-command = "/usr/sbin/nvram get vpn_client1_rip"
Maby It's take longer time to get ip from gettunnelip.sh

 

[Adamm]

My question @RMerlin why you are using a snapshot and unstable version of dnsmasq and knowing that version 2.79 is stable?, why not remove that alpha version and add the stable version 2.79?

I don't speak for Merlin but can make a pretty educated guess. v2.79 was released 7 months ago, which means if Merlin stays on the stable branch you would be exposed to about 12 months+ worth of bugs and vulnerabilities until the next "major" releases for both AsusWRT-Merlin and DNSMasq.

version 2.80
    Add support for RFC 4039 DHCP rapid commit. Thanks to Ashram Method
    for the initial patch and motivation.

    Alter the default for dnssec-check-unsigned. Versions of
    dnsmasq prior to 2.80 defaulted to not checking unsigned
    replies, and used --dnssec-check-unsigned to switch
        this on. Such configurations will continue to work as before,
        but those which used the default of no checking will need to be
        altered to explicitly select no checking. The new default is
        because switching off checking for unsigned replies is
    inherently dangerous. Not only does it open the possiblity of forged
        replies, but it allows everything to appear to be working even
        when the upstream namesevers do not support DNSSEC, and in this
        case no DNSSEC validation at all is occuring.

        Fix DHCP broken-ness when --no-ping AND --dhcp-sequential-ip
    are set. Thanks to Daniel Miess for help with this.

    Add a facilty to store DNS packets sent/recieved in a
    pcap-format file for later debugging. The file location
    is given by the --dumpfile option, and a bitmap controlling
    which packets should be dumped is given by the --dumpmask
    option.

    Handle the case of both standard and constructed dhcp-ranges on the
    same interface better. We don't now contruct a dhcp-range if there's
    already one specified. This allows the specified interface to
    have different parameters and avoids advertising the same
    prefix twice. Thanks to Luis Marsano for spotting this case.

    Allow zone transfer in authoritative mode if auth-peer is specified,
    even if auth-sec-servers is not. Thanks to Raphaël Halimi for
    the suggestion.

    Fix bug which sometimes caused dnsmasq to wrongly return answers
    without DNSSEC RRs to queries with the do-bit set, but only when
    DNSSEC validation was not enabled.
    Thanks to Petr Menšík for spotting this.

    Fix missing fatal errors with some malformed options
    (server, local, address, rebind-domain-ok, ipset, alias).
    Thanks to Eugene Lozovoy for spotting the problem.

    Fix crash on startup with a --synth-domain which has no prefix.
    Introduced in 2.79. Thanks to Andreas Engel for the bug report.

    Fix missing EDNS0 section in some replies generated by local
    DNS configuration which confused systemd-resolvd. Thanks to
    Steve Dodd for characterising the problem.

    Add --dhcp-name-match config option.

    Add --caa-record config option.

    Implement --address=/example.com/# as (more efficient) syntactic
    sugar for --address=/example.com/0.0.0.0 and
    --address=/example.com/::
    Returning null addresses is a useful technique for ad-blocking.
    Thanks to Peter Russell for the suggestion.
    
    Change anti cache-snooping behaviour with queries with the
    recursion-desired bit unset. Instead to returning SERVFAIL, we
    now always forward, and never answer from the cache. This
    allows "dig +trace" command to work.
    
    Include in the example config file a formulation which
    stops DHCP clients from claiming the DNS name "wpad".
    This is a fix for the CERT Vulnerability VU#598349.

 

[john9527]

why not remove that alpha version and add the stable version 2.79?

2.79 was not stable, not caching reliably, so it was skipped.
For Merlin, he needs 2.80 to pick up a fix that prevents a segfault crash on the AC86U.
And after all, for Merlin this is a beta.....if you don't want to participate in the beta, that's fine.

For my LTS fork, 2.80 also contains some security related items that we like to keep up on, especially since we skipped 2.79. It has been really stable, so I doubt your problems are dnsmasq related.

 

[john9527]

P.S @john9527 too these problems happen to me in their firmware.

??? Don't understand this statement

 

[RMerlin]

When use second inadyn with "conf.add" there is no cached 2:nd ip in "ddns.cache"
I update with 2:nd with: "checkip-command = "/usr/sbin/nvram get vpn_client1_rip"

This is normal. ddns.cache is only used by the firmware itself, not by inadyn. Inadyn has its own cache in /tmp/inadyn.cache for determining if an IP needs to be updated or not.

 

[RMerlin]

My question @RMerlin why you are using a snapshot and unstable version of dnsmasq and knowing that version 2.79 is stable?, why not remove that alpha version and add the stable version 2.79?

Because 2.80 introduces a fairly large number of fixes, including some security fixes. It has received nearly two months of testing from Asuswrt-Merlin testers, and has been proven stable enough for use in my firmware.

Asus themselves are frequently using beta releases of dnsmasq for the same reasons. Dnsmasq's release cycles are often too long to stay in sync with, therefore the need for either using test releases or backporting fixes.

I think the culprit is dnsmasq.

dnsmasq only handles DHCP, IPv6 RA and DNS duties. It has no relation to the WAN connection or wifi.

 

[octopus]

This is normal. ddns.cache is only used by the firmware itself, not by inadyn. Inadyn has its own cache in /tmp/inadyn.cache for determining if an IP needs to be updated or not.

My mistake, I don't have inadyn.cache in /tmp. When is't created?
https://github.com/RMerl/asuswrt-merlin.ng/commit/bf829f6ac349b2b368c4e81e4a76449ab3effa93

 

[truglodite]

I discovered what looks like a bug in 384.7_beta3 on my 86u (also existed in previous versions I think, but didn't pin it down until after installing beta3). I normally keep hw acceleration 'runner' enabled, and the webui tools menu shows it as enabled. However if just click on the webui 'adaptive qos' tab on the left (not actually changing any settings there), runner becomes disabled. I am aware that enabling adaptive qos is incompatible with runner, however I think simply reading the qos page(s) and not changing any settings should not trigger a runner disable. Runner should not be disabled until an incompatible setting is actually applied. When this happens to me, rebooting the router re-enables runner.

Is anyone else having this problem? Not sure if it's something that can be fixed, or if it's locked inside a closed source blob.

In case it matters, I'm also running the latest diversion+skynet+pixelserv_beta, some other scripts to add a local ntpd and block webcam wan access via iptables, and an openvpn server... and aiprotection, qos, traffic stats, and ipv6 stuff is all disabled.

 

[JacquesR]

I discovered what looks like a bug in 384.7_beta3 on my 86u (also existed in previous versions I think, but didn't pin it down until after installing beta3). I normally keep hw acceleration 'runner' enabled, and the webui tools menu shows it as enabled. However if just click on the webui 'adaptive qos' tab on the left (not actually changing any settings there), runner becomes disabled. I am aware that enabling adaptive qos is incompatible with runner, however I think simply reading the qos page(s) and not changing any settings should not trigger a runner disable. Runner should not be disabled until an incompatible setting is actually applied. When this happens to me, rebooting the router re-enables runner.

Is anyone else having this problem? Not sure if it's something that can be fixed, or if it's locked inside a closed source blob.

My searches aren't bearing fruit right now, but that problem pre-dates this beta - I had this in earlier 384 stable releases too. Reboots, or toggling things off and on, fixed it for me (sorry, that's vague, but it was a while back).

 

[Sanna1967]

It's weird, I have an AC86u too, with just a basic config, no qos, and i've never seen the "runner" enable