[Experimental] Asuswrt-Merlin 384.13 test - AiMesh/DNSSEC through OpenSSL

[RMerlin]

Pleasant surprise with this new alpha, i don’t have mesh, but all wireless clients show up with my given names now, instead of some with <no name> Thanks!

Alpha 2 received some enhancements to how it handles hostnames for clients that are not on the lease list but are present in the ARP cache. (I actually ended up rewriting both code sections).

I think @RMerlin mentioned he has a P30 that supports 160 but I've heard no one else mention it.

I used 160 MHz for a while, but I eventually downgraded back to 80 MHz. I saw no reason to pollute 160 MHz of airwaves for a smart phone connecting to a 120 Mbps Internet connection.

Im also concerned Merlin might EOL it soon.

I doubt Asus is going to EOL in the near future, as it's one of their most popular models. There is currently nothing else in the same price range as the RT-AC66U_B1 that could replace it. That was probably why they decided to implement AiMesh support for the RT-AC68U, but not for the very similar RT-AC56U.

 

[Marin]

It has worked quite well for me and have not messed with it all until now.

Figured it out [emoji6]. I had to reset my AX88U. Will now begin the long journey of slowly adding everything that I had on it before (Diversion, etc) along with mesh nodes, etc. [emoji36][emoji36][emoji36]




Sent from my iPhone using Tapatalk

And......after resetting my AiMesh router from scratch I selected the 160MHz bandwidth on the 5GHz frequency and set my channel to 48. Then change to another channel and rebooted. Then went back in and changed the channel back to 48. Again rebooted the router and let it stabilize for at least 30 minutes. Went back to the wireless settings and made sure that 160 MHz channel was the same.

Then I began setting my nodes one by one (via Ethernet cable from LAN of the AiMesh router to the WAN of the node). Then checked the wireless settings on the AiMesh router after the first node was setup....and voila! The same issue reappeared.

So it appears that the Auto channel box was automatically checked during node setup. So if you have 160MHz frequency selected it no longer gives you the option to unselect it unless you switch to 80 MHz bandwidth.

Anyone else experiencing the same wireless setting behavior with 160MHz bandwidth and your AiMesh nodes? If not, can you share how you set up your nodes with that particular WiFi bandwidth?

Thank you!



Sent from my iPhone using Tapatalk

 

[LimJK]

RMerlin,

Thanks for incorporating AiMesh so that I can comeback to use your firmware , I just flash your alpha version over my AiMesh Router last night and forced a reboot, Everything seems to be running OK for the last 12 hours. I will do more tests when I get home, I will do further testing including reconfiguring my OpenVPN Server.

By the way, considering that I am using Wired Ethernet Backhaul between my AiMesh Router (RT-AC5300) to both my AiMesh Nodes (RT-AC86U), it will be nice to be able to get back my TriBand for my RT-AC5300 in AiMesh configuration. I noticed from Specs of the ASUS RT-AX95Q/AX6600 AiMesh kit, it appears to support both backhaul and fronthaul; getting back my TriBand

 

[sdmf74]

So can anyone confirm if aimesh will work if I have the main router and secondary node somewhat close to one another?
They are on different floors but unfortunately their isn't a way to seperate them any further (wired backhaul).
Using a secondary router in Access point mode is not working well at all.
It could have something to do with the fact the AP is a cheap RT-ACRH13 which I believe uses a qualcomm rather than broadcom chipset that my main router uses, or the issue could lye in my sticky android 6.0 device also?

I just ordered an rt-ac68u to try out an AIMESH setup

 

[RMerlin]

So can anyone confirm if aimesh will work if I have the main router and secondary node somewhat close to one another?
They are on different floors but unfortunately their isn't a way to seperate them any further (wired backhaul).

Having two strong signals overlap is a bad idea for mesh, as your clients might not connect to the one you'd expect. You want to limit the amount of signal overlap.

 

[ttgapers]

**** closed. Bad hosts.add file left Bridge and Pixesrv-tls reserved IP conflicting. Issue is resolved and un-related ****

Hi,

Running Alpha 2 on a RT-AC86U. Not using AIMesh, but using SmartConnect and have a RT-N66U in Media Bridge mode long-term release (John). Started noticing the following behaviour once the RT-N66U connects. This did not occur on Alpha 1.

Note: I have only two devices wired into the RT-N66U. HP Printer and HDHomerun. I can access the printer but not the HDHR unless directly wired into the AC86U. I use a reservation for the HDHR.

On the AC86U here is what shows (accurately except for the phantom 192.168.40.190 & 226). Did a nmap scan against and got nada nil. Also the printer though resolvable doesn't show here, but did prior on Alpha 1. The bridge occasionally doesn't show up and I have to restart it. Once again only since Alpha 2.

A much more reasonable 8 clients are showing on the AC86U, where as the N66U is showing a whopping 137.

Thoughts?

 

[sdmf74]

In a couple days when my 68u arrives I'll test out aimesh and spread them out as far as I can. As stupid as it sounds if There is still too much overlap I'll just go back to using an app for client roaming, seems to be working flawlessly right now with my current setup.
It's kinda pathetic that an app is better at at determing and allowing client roaming than android and potentially asus though.

I thought aimesh was supposed to resolve some of the issues with having nodes somewhat overlapping?guess I was wrong.

I have about a 20-35dbm difference between nodes depending on the band.

 

[GoNz0]

In a couple days when my 68u arrives I'll test out aimesh and spread them out as far as I can. As stupid as it sounds if There is still too much overlap I'll just go back to using an app for client roaming, seems to be working flawlessly right now with my current setup.
It's kinda pathetic that an app is better at at determing and allowing client roaming than android and potentially asus though.

I thought aimesh was supposed to resolve some of the issues with having nodes somewhat overlapping?guess I was wrong.

I have about a 20-35dbm difference between nodes depending on the band.

Seems to do the opposite as for some strange reason they mirror the band's, to me it's a counter productive way of working as the channels now overlap. Whoever came up with mesh should allow channel separation.

Sent from my SM-G920F using Tapatalk

 

[Swistheater]

Hi,

Running Alpha 2 on a RT-AC86U. Not using AIMesh, but using SmartConnect and have a RT-N66U in Media Bridge mode long-term release (John). Started noticing the following behaviour once the RT-N66U connects. This did not occur on Alpha 1.

View attachment 18655

Note: I have only two devices wired into the RT-N66U. HP Printer and HDHomerun. I can access the printer but not the HDHR unless directly wired into the AC86U. I use a reservation for the HDHR.

On the AC86U here is what shows (accurately except for the phantom 192.168.40.190 & 226). Did a nmap scan against and got nada nil. Also the printer though resolvable doesn't show here, but did prior on Alpha 1. The bridge occasionally doesn't show up and I have to restart it. Once again only since Alpha 2.

View attachment 18657

A much more reasonable 8 clients are showing on the AC86U, where as the N66U is showing a whopping 137.

Thoughts?

John's fork will have to adapt some of the changes made to dhcp in order to fully remain compatible with network map functions.

 

[SomeWhereOverTheRainBow]

IMO if DoT is enabled it should be married to stubby DNSSEC, with the simple option of DNSSEC, no need to tell dnsmasq to validate unsigned replies.

dnsmasq.conf would say

dnssec
dnssec-check-unsigned=no

and stubby.yml would say

dnssec_return_status: GETDNS_EXTENSION_TRUE

and the unsigned reply option should simply be disabled in the gui and remain hidden with DoT turned on.

no need for complexities of DNSMASQ verifying when it would be easier upstream by stubby and then cached later.

.......

Some interesting results have emerged.
After doing some testing DNSMASQ appears to accept the dnssec from stubby now. I am able to test look ups with dnssec turned on within stubby.yml and no additions of dnssec to dnsmasq and I am able to receive ad flag for all lookups (gui dnssec turned off).

dig pir.org +dnssec +multi @127.0.1.1

; <<>> DiG 9.12.3-P4 <<>> pir.org +dnssec +multi @127.0.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49007
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message has 270 extra bytes at end

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;pir.org.               IN A

;; ANSWER SECTION:
pir.org.                168 IN A 97.107.141.235
pir.org.                168 IN RRSIG A 5 2 300 (
                                20190730084004 20190716084004 48480 pir.org.
                                GzMYwaG3JNvX88NFvPnD2hvky9Mtd+dafVXV/0i3cKpV
                                NQBxOw+Oe4bL488QyJIS5+7FPeLBpwW1+ACQVZJecH+x
                                u2JhUxH6L3K06o+RMjT7CNRv4U5iAzFCuYNGadS2t45y
                                FDZ8rhvJSyHsWD3PxCH12WMQ80bWvSK4jCM2Mo4= )

;; Query time: 1810 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Wed Jul 17 08:08:42 UTC 2019
;; MSG SIZE  rcvd: 503

 

[JemTheWire]

How does 'Roaming Blocking List' actually work?

I have a couple of IoT devices on 2.4gHz that don't seem to be able to make their mind up as to whether to connect to the AiMesh NODE or MASTER.

Currently I have waited for them to connect to the NODE then on the MASTER I have entered their MAC address' into the 'Roaming Blocking List'. I think I am mistaken thinking that doing this will 'lock' them to the NODE while they are currently fed of it, which is the closer WiFi source.

When I check back some time later, it's clear they have moved back to being connected to the MASTER.

So, I guess that anything on the roaming blocking list just locks them to the MASTER, not what they are currently connected to.

Is that right? If anyone can give a more detailed explanation of how this works that would be great.

Thanks as ever for reading.

 

[SomeWhereOverTheRainBow]

Some interesting results have emerged.
After doing some testing DNSMASQ appears to accept the dnssec from stubby now. I am able to test look ups with dnssec turned on within stubby.yml and no additions of dnssec to dnsmasq and I am able to receive ad flag for all lookups (gui dnssec turned off).

dig pir.org +dnssec +multi @127.0.1.1

; <<>> DiG 9.12.3-P4 <<>> pir.org +dnssec +multi @127.0.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49007
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: Message has 270 extra bytes at end

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;pir.org.               IN A

;; ANSWER SECTION:
pir.org.                168 IN A 97.107.141.235
pir.org.                168 IN RRSIG A 5 2 300 (
                                20190730084004 20190716084004 48480 pir.org.
                                GzMYwaG3JNvX88NFvPnD2hvky9Mtd+dafVXV/0i3cKpV
                                NQBxOw+Oe4bL488QyJIS5+7FPeLBpwW1+ACQVZJecH+x
                                u2JhUxH6L3K06o+RMjT7CNRv4U5iAzFCuYNGadS2t45y
                                FDZ8rhvJSyHsWD3PxCH12WMQ80bWvSK4jCM2Mo4= )

;; Query time: 1810 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Wed Jul 17 08:08:42 UTC 2019
;; MSG SIZE  rcvd: 503

After doing some test from devices, it needs to be noted that though DNSMASQ will accept dnssec validation using Dig and Drill from router standpoint with dnssec turned off, it will not pass it to clients, unless dnssec is turned on from Gui. I have done extensive testing using dig on several devices, and could not get a AD flag while on the client himself using dig that is installed on the device v.s. dig from SSH.
After turning GUI dnssec back on (no stubby dnssec), I then used Dig that was individually installed on devices and confirmed with dnssec turned on that signatures are then validated and can be verified on clients as well having received ad flag.
Test done by client with no DNSSEC enabled

dig pir.org +dnssec +multi

; <<>> DiG 9.14.3 <<>> pir.org +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51229
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;pir.org.               IN A

;; ANSWER SECTION:
pir.org.                300 IN A 97.107.141.235
pir.org.                300 IN RRSIG A 5 2 300 (
                                20190731084004 20190717084004 48480 pir.org.
                                R+Glt4W3kUVqyKzy2qgPf+Umyl3SW27RezGQ7VQaw4KB
                                Zg610IeXuxa51RzFEmrl+TwEhUJbTyhMPLbVe9KIQiYg
                                9gGEqeVr3F5avnENy1K3jafoJcLALgFfsjRF7mFJDhnC
                                /SInO0VERkwoCYWnuczMDitkv7K9m2dnbKtR8BA= )

;; Query time: 224 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Jul 17 07:27:38 Eastern Daylight Time 2019
;; MSG SIZE  rcvd: 233

test with client dnssec enabled in GUI

dig pir.org +dnssec +multi

; <<>> DiG 9.14.3 <<>> pir.org +dnssec +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26964
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1452
;; QUESTION SECTION:
;pir.org.               IN A

;; ANSWER SECTION:
pir.org.                193 IN A 97.107.141.235
pir.org.                193 IN RRSIG A 5 2 300 (
                                20190731084004 20190717084004 48480 pir.org.
                                R+Glt4W3kUVqyKzy2qgPf+Umyl3SW27RezGQ7VQaw4KB
                                Zg610IeXuxa51RzFEmrl+TwEhUJbTyhMPLbVe9KIQiYg
                                9gGEqeVr3F5avnENy1K3jafoJcLALgFfsjRF7mFJDhnC
                                /SInO0VERkwoCYWnuczMDitkv7K9m2dnbKtR8BA= )

;; Query time: 1514 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Jul 17 07:29:25 Eastern Daylight Time 2019
;; MSG SIZE  rcvd: 233

So DNSSEC must be enabled, either with GUI,
or alternatively with stubby.yml, with proxy-dnssec inside dnsmasq.conf.add. for clients to properly be able to use dnssec.

 

[OzarkEdge]

I have about a 20-35dbm difference between nodes depending on the band.

This may mesh ok. You can also adjust the transmit power down to reduce WiFi overlap. Or try a AiMesh wireless backhaul and more distance between the nodes.

OE

 

[skeal]

Having two strong signals overlap is a bad idea for mesh, as your clients might not connect to the one you'd expect. You want to limit the amount of signal overlap.

This being said I live in a house where my master and node are separated by about 20 feet. In that 20 feet are two walls, one tiled with mirrors ffs. It all works though excellent I might add!

 

[RMerlin]

It's kinda pathetic that an app is better at at determing and allowing client roaming than android and potentially asus though.

No, actually the BEST place to do effective roaming control IS on the client device. A router can only kick off a client, it cannot instruct a client where to connect. Only a client can decide to which specific BSSID it wants to connect.

I thought aimesh was supposed to resolve some of the issues with having nodes somewhat overlapping?guess I was wrong.

That's not what Mesh technology is about. Mesh networks must always be carefully planned to ensure that you have adequate overlap. Business-class mesh products will often require you to also adjust their output powers, to properly balance coverage.

What AiMesh is about is centralized management of multiple access points, with a roaming assistant kicking off clients ONLY if their signal level is lower than the limit you configure on the roaming assistant. If a client sees two strong wifi signals, it's up to the client to decide to which to connect. And if the signal is strong from both locations, an AiMesh node won't have any reason to kick a client off.

 

[RMerlin]

A much more reasonable 8 clients are showing on the AC86U, where as the N66U is showing a whopping 137.

Please stay on topic. This thread is about evaluating AiMesh and the OpenSSL-based DNSSEC implementation. This is not a public beta test, this is a focused pre-release test project.

 

[QuikSilver]

Updated from .12 stable to .13 alpha 2 dirty. Smooth process, ran RootCanary test and everything checks out good so far. Don't use AiMesh system currently though.

 

[Odkrys]

If a client sees two strong wifi signals, it's up to the client to decide to which to connect. And if the signal is strong from both locations, an AiMesh node won't have any reason to kick a client off.

I am still curious how they are doing
https://www.snbforums.com/threads/aimesh-use-with-or-instead-of-ethernet.44119/#post-375304

 

[Plompie]

Not sure if it's due to DNS issues, Link DOWN/UP switching or something else in this Alpha release but one night ago the router lost all connections and today around 11.00 my AC86U stopped working again.

I'm not a specialist on DNSSEC but can mention the test @ routcanary gives all green and yellow (no red servfail), similar to other patterns people posted here.

Jul 17 10:02:33 dnsmasq[1650]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
Jul 17 10:32:22 dnsmasq[1650]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
Jul 17 10:32:22 dnsmasq[1650]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
Jul 17 10:45:17 dnsmasq[1650]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
Jul 17 10:45:17 dnsmasq[1650]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers
Jul 17 10:45:17 dnsmasq[1650]: Insecure DS reply received for 168.192.in-addr.arpa, could be bad domain configuration or lack of DNSSEC support from upstream DNS servers

<<<<<< CONNECTION DROPPED BETWEEN THESE ENTRIES, but nothing logged >>>>>>>

Jul 17 13:28:49 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 13:28:51 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
Jul 17 13:30:56 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 13:31:00 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
Jul 17 14:13:20 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 14:13:23 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
Jul 17 14:15:27 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 14:15:31 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
Jul 17 14:58:02 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 14:58:04 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
Jul 17 15:00:08 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 15:00:12 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
Jul 17 15:42:37 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 15:42:40 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
Jul 17 15:44:45 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 15:44:49 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
Jul 17 15:44:50 kernel: net_ratelimit: 1994 callbacks suppressed
Jul 17 15:52:42 kernel: net_ratelimit: 605 callbacks suppressed
Jul 17 16:27:24 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 16:27:26 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
Jul 17 16:29:29 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 16:29:34 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
Jul 17 17:11:57 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 17:11:59 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
Jul 17 17:14:02 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 17:14:06 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
Jul 17 17:55:45 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 17:55:47 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
Jul 17 17:57:52 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link DOWN.
Jul 17 17:57:55 kernel: eth3 (Ext switch port: 2) (Logical Port: 10) Link UP 100 mbps half duplex
May  5 07:05:07 kernel: klogd started: BusyBox v1.25.1 (2019-07-12 17:20:10 EDT)
May  5 07:05:07 kernel: Linux version 4.1.27 (merlin@ubuntu-dev) (gcc version 5.3.0 (Buildroot 2016.02) ) #2 SMP PREEMPT Fri Jul 12 18:33:05 EDT 2019

 

[ttgapers]

Thanks. Corrected/updated the post. Apologies on losing focus! Cheers from Tdot.

Please stay on topic. This thread is about evaluating AiMesh and the OpenSSL-based DNSSEC implementation. This is not a public beta test, this is a focused pre-release test project.

Apologies on this one. Assuming AiMesh/

Please stay on topic. This thread is about evaluating AiMesh and the OpenSSL-based DNSSEC implementation. This is not a public beta test, this is a focused pre-release test project.