What's new

[Beta] Asuswrt-Merlin 384.11 Beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

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.
My guess is that OVPN Server and or Client cannot start without a WAN connection and or NTP update.
 
What firmware did you use for the restore exactly been having failed firmware upload.

Recovery flash usually requires a stock firmware. You can use any of the official ASUS ones. That's what I used, and then flashed back to Merlin 384.10_2.

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

A few other people had this problem too. Please look into this!
 
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.
The other strange thing is, without making any changes if i set the same settings in 384.10_2 the router boots clean both OVPN Server and Client start. I have reset to defaults many times to isolate the issue. Please let me know any additional information you need to fix this. I could send you my logs, maybe I'm missing something obvious. o_O:confused:
 
I have not had trouble with stubby.postconf although I do not use a VPN client
Code:
# cat /jffs/scripts/stubby.postconf
#!/bin/sh
CONFIG=$1
source /usr/sbin/helper.sh
#
pc_delete "tls_query_padding_blocksize" $CONFIG
pc_delete "round_robin_upstreams" $CONFIG
pc_delete "tls_connection_retries" $CONFIG
pc_delete "tls_backoff_time" $CONFIG
pc_delete "timeout" $CONFIG
#
pc_append "idle_timeout: 9900" $CONFIG
#
this config will delete whatever line u want to delete in stubby.yml?

@RMerlin
I realised that "dns_transport_list" is using UDP and TCP, not TLS (- GETDNS_TRANSPORT_TLS)? why is that so?
Also, the IPv6 listening address ( - 0::1@53 )is not added when IPv6 is enabled.
 
this config will delete whatever line u want to delete in stubby.yml?

@RMerlin
I realised that "dns_transport_list" is using UDP and TCP, not TLS (- GETDNS_TRANSPORT_TLS)? why is that so?
Also, the IPv6 listening address ( - 0::1@53 )is not added when IPv6 is enabled.
Yes, I do this because the default settings have updates which are not reflected in the documentation sample configs which I assume the firmware settings are based upon. Why hard code them if the defaults are being thoughtfully updated by experts? Here are the values of the lines I have changed:
Code:
# stubby -i | egrep "tls_query_padding_blocksize|round_robin_upstreams|tls_connection_retries|tls_backoff_time|timeout"
[15:46:24.779548] STUBBY: Read config from file /etc/stubby/stubby.yml
Result: Config file syntax is valid.
    "idle_timeout": 9900,
    "round_robin_upstreams": 1,
    "timeout": 5000,
    "tls_backoff_time": 3600,
    "tls_connection_retries": 2,
    "tls_query_padding_blocksize": 256,
Here is the resulting stubby.yml.
  • Notice that there is no problem with GETDNS_TRANSPORT_TLS.
  • While there has been discussion of stubby not listening on IPv6, whether it was intentional or not was not clear.
Code:
# cat /tmp/etc/stubby/stubby.yml
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_ca_file: "/etc/ssl/certs/ca-certificates.crt"
appdata_dir: "/var/lib/misc"
resolvconf: "/tmp/resolv.conf"
edns_client_subnet_private: 1
listen_addresses:
  - 127.0.1.1@53
upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1111
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1001
    tls_auth_name: "cloudflare-dns.com"
idle_timeout: 9900
 
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?

Can’t access the GUI after dirty flashing from 384.10_2 on both ac3100 I have.

Was asked to manually reboot.

The router is alive, as I see the ssid specific to the the two ac3100 I am using as Access points. Just no access to the GUI.
 
When you decide to make changes using these features you should do service restart_dnsmasq. Wait a good 15 minutes to see it be stable-- then move on to test if it is stable via reboot.
Well, have failed on all attempts so far to get DNSSEC working in Stubby after a reboot. Have had some siding blow off of the house that I've had to fix. Enough for now. Going for a walk to contemplate nature...
 
Yes, I do this because the default settings have updates which are not reflected in the documentation sample configs which I assume the firmware settings are based upon. Why hard code them if the defaults are being thoughtfully updated by experts? Here are the values of the lines I have changed:
Code:
# stubby -i | egrep "tls_query_padding_blocksize|round_robin_upstreams|tls_connection_retries|tls_backoff_time|timeout"
[15:46:24.779548] STUBBY: Read config from file /etc/stubby/stubby.yml
Result: Config file syntax is valid.
    "idle_timeout": 9900,
    "round_robin_upstreams": 1,
    "timeout": 5000,
    "tls_backoff_time": 3600,
    "tls_connection_retries": 2,
    "tls_query_padding_blocksize": 256,
Here is the resulting stubby.yml.
  • Notice that there is no problem with GETDNS_TRANSPORT_TLS.
  • While there has been discussion of stubby not listening on IPv6, whether it was intentional or not was not clear.
Code:
# cat /tmp/etc/stubby/stubby.yml
resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_ca_file: "/etc/ssl/certs/ca-certificates.crt"
appdata_dir: "/var/lib/misc"
resolvconf: "/tmp/resolv.conf"
edns_client_subnet_private: 1
listen_addresses:
  - 127.0.1.1@53
upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1111
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 2606:4700:4700::1001
    tls_auth_name: "cloudflare-dns.com"
idle_timeout: 9900
Thx for the script. work as intended. someone please help add to wiki. it would be nice.
 
When I look in the logs, the time sync and WAN up log entries don't take place until the very end of the boot. The log entries are literally right before the end of the reboot process. The probable reason for my OVPN Server or Client not starting is not having a WAN connection and or NTP update. I DO NOT have any special scripts running. Only the stuff in my signature, there are no other custom mods. I have deliberately kept things simple too get to the bottom of the issue. You didn't say how things went when you tried the OVPN Server starting at reboot. I am unable to find any problems in the logs. The only entry I found was:
Code:
May  4 23:05:11 WAN_Connection: Ethernet link down.
May  4 23:10:19 Skynet: [*] NTP Failed To Start After 5 Minutes - Please Fix Immediately!
I also noted that my USB drive doesn't get mounted either.
are you using the network monitor functions under administration?
 
What I was curious to know was if any other features are missing or not functioning correctly well using Merlin.

AiMesh is the only feature I specifically don't support.
SNMP not responding and getting this error when disable/enable SNMP.

I don't know if Asus recently broke something related to firmware image generation, but this is the second time one of my firmware image has these squashfs errors, and Asus also encountered them with a recent RT-AC68U release. I will have to try digging up what changes might have introduced these.

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

They should be, but only way to be 100% sure is by testing, since I have no way of knowing what was changed in the closed source parts.

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).

It depends what was in the open sources parts, and what wasn't. Some of these are in the open sourced parts, others aren't.

*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.

A user-generated stubby.yml is almsot guaranteed to NOT work after a reboot. Rather than face a number of users struggling with that, I prefer to remove it. Users have no way of knowing that the stubby.yml content needs to be different at boot time than after subsequent restarts.
 
Thx for the script. work as intended. someone please help add to wiki. it would be nice.
i am curious to see whatever other options are recommended.. do you have any links to sources of the "experts" i would like to examine the materials.
 
AiMesh is the only feature I specifically don't support.


I don't know if Asus recently broke something related to firmware image generation, but this is the second time one of my firmware image has these squashfs errors, and Asus also encountered them with a recent RT-AC68U release. I will have to try digging up what changes might have introduced these.



They should be, but only way to be 100% sure is by testing, since I have no way of knowing what was changed in the closed source parts.



It depends what was in the open sources parts, and what wasn't. Some of these are in the open sourced parts, others aren't.



A user-generated stubby.yml is almsot guaranteed to NOT work after a reboot. Rather than face a number of users struggling with that, I prefer to remove it. Users have no way of knowing that the stubby.yml content needs to be different at boot time than after subsequent restarts.
I have successfully used it now to make a custom .yml file work without issue. i think my issue was not waiting for it to take set before rebooting. once it has ran for a period of time and the system stabilizes i noticed, reboot becomes successful.
 
I discovered this morning that a stubby.yml in /jffs/configs will not work on reboot. stubby.yml.add does not work either.

The actual filename is stubby.add (I will change it to stubby.yml.add in beta 2 for consistency with other services).

from dnsmasq with static root keys can lead to issues when the resolver providers decide to change the keys.

The keys are not determined by the resolver providers, but by IANA. They are highly unlikely to change (there has been only one change since DNSSEC was introduced, and people had months of lead time to update).

Integrity of the keys can be ensured with S/MIME, but I don't know if getdns implemented that.

I also noted that my USB drive doesn't get mounted either.

Check your system log for any rc_service skipped event.

I have an OpenVPN server configured to start at boot on my main router as well as on many of my test routers, and never had any issue with them starting correctly at boot time. All I can think of would be a race/timing issue during your boot process, this usually shows up with a skipped event.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top