[Beta] Asuswrt-Merlin 384.11 Beta is now available

[RMerlin]

Hi Eric,

Great work! I've been very interested in this since you released it. I tried Alpha 4 a few days ago, but I was unable to access the GUI after a clean flash. Ended up having to do a recovery flash to stock to get it to work again. Would I experience the same problems with this Beta on my AC3100?

Either your router got stuck on reboot and required a power cycle, or the flash process got interrupted.

The commits after April 23 are what's new compared to a4?

merlin@ubuntu-dev:~/amng$ git log 2169d263b9..HEAD --oneline
e0ab79dc0b (HEAD -> mainline, tag: 384.11-beta1-mainline, origin/mainline) Merge branch 'master' into mainline
112d1493cf Bumped revision to beta 1
46dc0faf5a webui: reflect the state of DNS Privacy on the Network Map / Internet pane
1c01b403cd httpd: don't try to use robocfg on HND when calling sysinfo("ethernet")
bf11b34808 Updated documentation
d9a005b59e httpd: also count guest clients on the Sysinfo page
03a503bfcf webui: add 'inner' flag to check_hwaddr_flag() calls missing it; also add it to the WAN page
7257f6f539 miniupnpd: fix ssdp notify on wrong interfaces
6fd2d604d1 rc: use dnsmasq for dnssec validation
cc3c709825 net-snmp: fix clean target
756caf15f4 shared: replace upper_strcmp() calls with strcasecmp() in QTN-specific parts

 

[RMerlin]

With regard to the AX88U. I flashed the Beta over the Alpha 4 and still the same reboot issue. With OVPN Server and/or Client set to start at boot, the router will not connect to the internet. I tried several different ways with and without DNSSEC and such and still no way will the time sync or the WAN connection come up.

Works for me. I just setup a router with a PIA OpenVPN client set to connect at boot, and DNS over TLS enabled. On a reboot everything was started normally.

VPN clients don't get started until after the WAN comes up.

Check what customization you have in place. Also check your boot log for any error message during boot.

 

[RMerlin]

it is something that really needs to be tested to see what is going on to cause the issues.

The code is written so postconf script will not return until it has completed, and stubby will not start until that happens (the router will wait up to 120 seconds for the postconf script to return). So, I don't see how there could be any link, unless your script spawns a separate process.

Make sure you aren't manually starting stubby elsewhere (for instance in left-overs from a previous install).

The code squence:

        append_custom_config("stubby", fp);
        fclose(fp);
        use_custom_config("stubby.yml", (char *)stubby_config);
        run_postconf("stubby", (char *)stubby_config);
        chmod(stubby_config, 0644);
        if (nvram_get_int("stubby_debug")) {
                stubby_argv[index++] = "-l";
                stubby_log = ">/tmp/stubby.log";
        }
        _eval(stubby_argv, stubby_log, 0, NULL);

Likewise, using a custom config will have that file copied on top of the router-generated one before starting Stubby, so there's no reason for a delay to be added there.

This code segment is identical to all other services.

 

[RMerlin]

I just created a stubby postconf that sent text to a temp file, waited 5 secs, then checked if stubby was already running by running "ps w | grep stubby" - and it wasn't, confirming that Stubby will not start until the postconf script has completed its execution.

admin@Stargate86:/tmp/home/root# cat /tmp/000output.txt
Starting postconf
Waited 5 secs
  772 admin     3364 S    {stubby.postconf} /bin/sh /jffs/scripts/stubby.postconf /etc/stubby/stubby.yml
  778 admin     3368 S    grep stubby
Starting postconf
Waited 5 secs
 1153 admin     3364 S    {stubby.postconf} /bin/sh /jffs/scripts/stubby.postconf /etc/stubby/stubby.yml
 1175 admin     3368 S    grep stubby
Starting postconf
Waited 5 secs
 1595 admin     3364 S    {stubby.postconf} /bin/sh /jffs/scripts/stubby.postconf /etc/stubby/stubby.yml
 1764 admin     3368 S    grep stubby
Starting postconf
Waited 5 secs
 1768 admin     3364 S    {stubby.postconf} /bin/sh /jffs/scripts/stubby.postconf /etc/stubby/stubby.yml
 1777 admin     3368 S    grep stubby

So from a technical point of view, I see no reason why a pause would be necessary between the config file customization/creation, and starting the process.

EDIT: BTW, providing a replacement stubby.yml will fail at boot because it needs to be told NOT to enforce TLS at boot time. If you just copy a stubby.yml config with TLS enabled, then your ntp will fail to synchronize the clock, as TLS cannot work until the clock is set. I will probably remove support for replacing stubby.yml for this reason, leaving postconf and .add only.

 

[Adamm]

Replaced the custom ntpclient with an ntp daemon. This daemon acts as a client (to sync your router's clock with the NTP servers configured on the router's System -> Administration page), but it can also be used as an ntp server for your LAN devices. Server functionality can be enabled on the System Administration page. Afterward, you can configure your LAN clients to use your router's IP as their NTP server.

Have you considered adding something similar to DNSFilter functionality where all client NTP requests are forwarded to the local server instead? I believe John did something similar in his fork.

 

[RMerlin]

Have you considered adding something similar to DNSFilter functionality where all client NTP requests are forwarded to the local server instead? I believe John did something similar in his fork.

I'm still unsure about that one. While it's a nice feature, I'm always hesitant in adding these kind of settings, as I want to avoid the feature creep syndrome that too many modern software have. If I add that, the next person will ask for a forced SMTP redirection, then a forced web proxy redirection, and so on. You end up with a long list of settings that aren't always obvious to end-users, and scare away the less technically-inclined ones. A lot of people think that OpenWRT is "too complicated", while it's not - it just has a lot of knobs and dials to fiddle with.

DNSFilter was a different case. It was designed as a more advanced feature to allow people to put select client devices behind a DNS-based filtering service (hence the DNSFilter name), for example putting the kid's clients behind OpenDNS. So it was more than just one cryptic "bind DNS" checkbox like Tomato (I think?) offers, it opened the door to a more fleshed out feature on its own.

I'll have to think some more about it. I'm not totally opposed to it, just... reluctant at this time.

 

[John Adler]

dirty flash went OK
now starting tests

 

[AmyGrrl]

I just bought an RT-AX88U this week to replace my RT-AC66U B1. Then gave my RT-AC66U B1 to my brother. Looking forward to installing this beta build on the RT-AX88U. Just had one question. I know AiMesh is not supported. Which is fine because I will only have this one router anyways. What I was curious to know was if any other features are missing or not functioning correctly well using Merlin. Only ask because this is the most expensive router I've ever purchased. Also thanks for all the hard work you put into these builds for us. Have been using your firmware for several years now.

 

[toast]

RT- AC87U.
Dirty flash over 384.10_2. last factory reset is maybe 2-3 releases away.
SNMP not responding and getting this error when disable/enable SNMP.

Maybe time for a factory reset but I will save that for the FW release. So just reporting in case someone see the same behaviour.

Apr 27 09:05:28 rc_service: httpds 243:notify_rc restart_snmpd
Apr 27 09:05:29 kernel: SQUASHFS error: xz_dec_run error, data probably corrupt
Apr 27 09:05:29 kernel: SQUASHFS error: squashfs_read_data failed to read block 0xf00a83
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read data cache entry [f00a83]
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read page, block f00a83, size 719c
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read data cache entry [f00a83]
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read page, block f00a83, size 719c
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read data cache entry [f00a83]
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read page, block f00a83, size 719c
....
....
....
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read page, block f00a83, size 719c
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read data cache entry [f00a83]
Apr 27 09:05:29 kernel: SQUASHFS error: Unable to read page, block f00a83, size 719c
Apr 27 09:05:30 nat: apply nat rules (/tmp/nat_rules_vlan2_vlan2)

 

[Zastoff]

RT-AC87u, 72hours on alpha4 and all have been running great, Smooth fw update to beta1 all looking good

 

[Joey Crocker]

Hi Eric,

Great work! I've been very interested in this since you released it. I tried Alpha 4 a few days ago, but I was unable to access the GUI after a clean flash. Ended up having to do a recovery flash to stock to get it to work again. Would I experience the same problems with this Beta on my AC3100?

I am having that same issue

 

[InstantAli3n]

Hi Eric,

Great work! I've been very interested in this since you released it. I tried Alpha 4 a few days ago, but I was unable to access the GUI after a clean flash. Ended up having to do a recovery flash to stock to get it to work again. Would I experience the same problems with this Beta on my AC3100?

I was also unable to access the GUI after flashing alpha4. AC3100

I've been dirty flashing each new build, alpha and beta since 378 I think... but seriously I've had no problems from doing that. (About time lol!)

After the flash completed it connected back and said please reboot manually which I did, and the GUI was not accessible after that. IPv6 also seemed to take a little while to work fully.
I rebooted again and still no GUI, and also no IPv6 either connectivity whatsoever. Everything else is working very smoothly, QoS etc, are testing perfectly.

Will wait and see what's up.

 

[octopus]

Updated to BETA1 and working fine.
Uptime 0 days 0 hours 22 minute(s) 17 seconds

Thank you RM!

 

[owine]

I was also unable to access the GUI after flashing alpha4. AC3100

I've been dirty flashing each new build, alpha and beta since 378 I think... but seriously I've had no problems from doing that. (About time lol!)

After the flash completed it connected back and said please reboot manually which I did, and the GUI was not accessible after that. IPv6 also seemed to take a little while to work fully.
I rebooted again and still no GUI, and also no IPv6 either connectivity whatsoever. Everything else is working very smoothly, QoS etc, are testing perfectly.

Will wait and see what's up.

Same for me. Will not be able to try the beta for a couple of days.

 

[GoNz0]

Been looking forward to this.
I use NTPmerlin currently, I take it the new NTP server option means I no longer need this installed?

 

[Joey Crocker]

Hi Eric,

Great work! I've been very interested in this since you released it. I tried Alpha 4 a few days ago, but I was unable to access the GUI after a clean flash. Ended up having to do a recovery flash to stock to get it to work again. Would I experience the same problems with this Beta on my AC3100?

What firmware did you use for the restore exactly been having failed firmware upload.

 

[telUK]

Can anyone confirm if the network map is stable on the ac86u, (devices disappearing/reappearing). I believe this has the fix from Asus that sorts that finally.

 

[grifo]

I'll have to think some more about it. I'm not totally opposed to it, just... reluctant at this time.

While I completely understand your reasoning, in this case there would be a good reason for adding the feature, which is avoiding the double ntp syncing that routers using ntpmerlin for it would get.

 

[JIPG]

I have a noob question about this release:
In the changelog it is stated that "GPL merges: 384_5951 (RT-AX88U), 384_45713 (all other models). Note that the RT-AC87U and RT-AC3200 are still using the 384_45149 binary blobs for their closed source components."

I suppose that although the closed source parts belong to a previous release, they are still compatible 100%, aren´t they?

And, It does mean that the last problems solved in 384_45713 are not included for RT-AC87U as they are normally in closed source parts? (e.g Security issues with new CVE, network map related issues, VLAN bug form Movistar, etc).

And thank you again for your great software. Without your releases, the RT AC87U should be completely forgotten, although it is in fact a good router ...

 

[Swistheater]

I just created a stubby postconf that sent text to a temp file, waited 5 secs, then checked if stubby was already running by running "ps w | grep stubby" - and it wasn't, confirming that Stubby will not start until the postconf script has completed its execution.

admin@Stargate86:/tmp/home/root# cat /tmp/000output.txt
Starting postconf
Waited 5 secs
  772 admin     3364 S    {stubby.postconf} /bin/sh /jffs/scripts/stubby.postconf /etc/stubby/stubby.yml
  778 admin     3368 S    grep stubby
Starting postconf
Waited 5 secs
 1153 admin     3364 S    {stubby.postconf} /bin/sh /jffs/scripts/stubby.postconf /etc/stubby/stubby.yml
 1175 admin     3368 S    grep stubby
Starting postconf
Waited 5 secs
 1595 admin     3364 S    {stubby.postconf} /bin/sh /jffs/scripts/stubby.postconf /etc/stubby/stubby.yml
 1764 admin     3368 S    grep stubby
Starting postconf
Waited 5 secs
 1768 admin     3364 S    {stubby.postconf} /bin/sh /jffs/scripts/stubby.postconf /etc/stubby/stubby.yml
 1777 admin     3368 S    grep stubby

So from a technical point of view, I see no reason why a pause would be necessary between the config file customization/creation, and starting the process.

EDIT: BTW, providing a replacement stubby.yml will fail at boot because it needs to be told NOT to enforce TLS at boot time. If you just copy a stubby.yml config with TLS enabled, then your ntp will fail to synchronize the clock, as TLS cannot work until the clock is set. I will probably remove support for replacing stubby.yml for this reason, leaving postconf and .add only.

Since swapping from alpha 4 to beta1 I have experienced no issues with any of the custom script features I fully tested and confirm they are now stable.
*edit* I dont think it really matters if the replace features is there or not, but one could easily cat command replace the yml file in a postconf script. So I don't know if removing the feature really matters much.