First, the teasers:
And:
dnsmasq OpenSSL support
Dnsmasq uses nettle to handle the crypto portion of DNSSEC, which limits the supported ciphers. @themiron implemented OpenSSL support in dnsmasq, which opens the door for supporting more ciphers.
The implementation required a fair amount of changes to dnsmasq itself, and so it will require in-depth testing to ensure it works properly. I have already personally observed some oddities: when using my ISP's DNS, I am able to to validate DSA signatures despite it not being enabled in dnsmasq. Seems like somehow dnsmasq accepts the upstream server's validation.
AiMesh support
The two main technical obstacles (that I was aware of, so far) to supporting AiMesh were:
- I use a custom format for dhcp_staticlist to store user-defined hostnames
- AiMesh manipulates/validates firmware versions between all nodes
A future change to dhcp_staticlist layout forced me to investigate into ways to deal with that. I ended up moving the hostnames to a separate nvram variable for non-HND models, and reading/writing that new setting directly in /jffs for HND models (where a new variable's max length is 255 characters). Doing so allows me to stay 100% compatible with Asus's current (and future) dhcp_staticlist format. It also allows people to enter more static leases than before (since the 2999 characters of dhcp_staticlist no longer need to also include hostnames). And finally it should make cfg_sync (the daemon that syncs settings between AiMesh nodes) happy, and no longer claiming that an Asuswrt-Merlin router is running firmware 3.8.4...
Since the only remaining obstacle was the firmware version handling, I looked into also making it closer to stock firmware. I've settled with storing a bogus version in the webs_state_info variable, and instead storing the real firmware version announced by the update server into a new variable. This required a fair amount of changes and workarounds to deal with this. Also, the update check code needed to be able to handle both my own update server (for the primary node) and Asus's own servers (for all the child nodes).Therefore, there is one restriction: only your primary AiMesh router can run Asuswrt-Merlin. All the other nodes connected to it must run the stock firmware from Asus. Which shouldn't be a problem, as those nodes wouldn't be able to really benefit from the Asuswrt-Merlin enhancements. Starting with alpha 2, Asuswrt-Merlin nodes are supported, however your primary router must also be running Asuswrt-Merlin.
This is still experimental
At this point, both of these features are considered experimental projects, in need of thorough testing. The result of these tests will determine if it will be possible to go ahead with either of these features as part of the standard feature set. So, nothing is guaranteed yet. There is still a chance that something will go wrong, and ultimately these features might have to be put back on the shelves.
Before you begin
Make a backup of both your Settings and your JFFS partition before you start playing with these experimental builds.
To use the new dnsmasq support you don't need to do anything: just enable DNSSEC support, then watch the general behaviour. DNS-over-TLS settings should not have any impact on these tests.
Note that any node (other than the primary router) that you turn into an AiMesh node will be reset to factory default settings (as part of a standard AiMesh setup). So, make a backup of their configurations first if you intend to revert back to a non-AiMesh state with these.
How to use AiMesh
The procedure is identical to if you were running a "pure" stock firmware environment. Do a factory default reset on any node you wish to connect (use the Reset button on it to do that, somehow trying to use the AiMesh Node option on System Operation Mode page never worked for me). Once the node is done rebooting, log in your primary router, click on the AiMesh icon on the front page, then click on the button to search for nodes, on the right side panel.
Also note that only models that have AiMesh support from Asus will get that support in my firmware. So, RT-AC87U and RT-AC3200 remain unsupported for AiMesh.
Downloads: https://www.asuswrt-merlin.net/test-builds
And:
dnsmasq OpenSSL support
Dnsmasq uses nettle to handle the crypto portion of DNSSEC, which limits the supported ciphers. @themiron implemented OpenSSL support in dnsmasq, which opens the door for supporting more ciphers.
The implementation required a fair amount of changes to dnsmasq itself, and so it will require in-depth testing to ensure it works properly. I have already personally observed some oddities: when using my ISP's DNS, I am able to to validate DSA signatures despite it not being enabled in dnsmasq. Seems like somehow dnsmasq accepts the upstream server's validation.
AiMesh support
The two main technical obstacles (that I was aware of, so far) to supporting AiMesh were:
- I use a custom format for dhcp_staticlist to store user-defined hostnames
- AiMesh manipulates/validates firmware versions between all nodes
A future change to dhcp_staticlist layout forced me to investigate into ways to deal with that. I ended up moving the hostnames to a separate nvram variable for non-HND models, and reading/writing that new setting directly in /jffs for HND models (where a new variable's max length is 255 characters). Doing so allows me to stay 100% compatible with Asus's current (and future) dhcp_staticlist format. It also allows people to enter more static leases than before (since the 2999 characters of dhcp_staticlist no longer need to also include hostnames). And finally it should make cfg_sync (the daemon that syncs settings between AiMesh nodes) happy, and no longer claiming that an Asuswrt-Merlin router is running firmware 3.8.4...
Since the only remaining obstacle was the firmware version handling, I looked into also making it closer to stock firmware. I've settled with storing a bogus version in the webs_state_info variable, and instead storing the real firmware version announced by the update server into a new variable. This required a fair amount of changes and workarounds to deal with this. Also, the update check code needed to be able to handle both my own update server (for the primary node) and Asus's own servers (for all the child nodes).
This is still experimental
At this point, both of these features are considered experimental projects, in need of thorough testing. The result of these tests will determine if it will be possible to go ahead with either of these features as part of the standard feature set. So, nothing is guaranteed yet. There is still a chance that something will go wrong, and ultimately these features might have to be put back on the shelves.
Before you begin
Make a backup of both your Settings and your JFFS partition before you start playing with these experimental builds.
To use the new dnsmasq support you don't need to do anything: just enable DNSSEC support, then watch the general behaviour. DNS-over-TLS settings should not have any impact on these tests.
Note that any node (other than the primary router) that you turn into an AiMesh node will be reset to factory default settings (as part of a standard AiMesh setup). So, make a backup of their configurations first if you intend to revert back to a non-AiMesh state with these.
How to use AiMesh
The procedure is identical to if you were running a "pure" stock firmware environment. Do a factory default reset on any node you wish to connect (use the Reset button on it to do that, somehow trying to use the AiMesh Node option on System Operation Mode page never worked for me). Once the node is done rebooting, log in your primary router, click on the AiMesh icon on the front page, then click on the button to search for nodes, on the right side panel.
Also note that only models that have AiMesh support from Asus will get that support in my firmware. So, RT-AC87U and RT-AC3200 remain unsupported for AiMesh.
Downloads: https://www.asuswrt-merlin.net/test-builds
Last edited: