What's new

[Beta] Asuswrt-Merlin 384.13 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!

Status
Not open for further replies.
The 2.4 GHz (legacy) does not handle channel width internally the same way as the 5 GHz band. The 2.4 GHz band will register as two separate channels (which will be shown if using 40 MHz), while the 5 GHz band will register as one larger channel.





Check your system log for errors, also please read the third post in this thread listing known issues.

Thank you! I missed that post. Will stick with alpha2 for now and await for beta-2.


Sent from my iPhone using Tapatalk
 
I followed the AiMesh setup from post #2, yet I was never able to get my 86U/AC88U to connect via AiMesh setup. I was able to up/down fw (official & RMerlin) on both 86U/AC88. Aimesh Router 86U would find 88U during AiMesh setup, then Router/node failed to connect, despite all AiMesh conditions met. I always received the popup stating node too far, etc, and that the 88U was returned to factory. After an hour of failed attempts (I always used RMerlin on Main, yet tried official and RMerlin on node), I returned network back to Main-AP.
I will wait for Beta 2 or RMerlin's official to attempt again.
 
I followed the AiMesh setup from post #2, yet I was never able to get my 86U/AC88U to connect via AiMesh setup. I was able to up/down fw (official & RMerlin) on both 86U/AC88. Aimesh Router 86U would find 88U during AiMesh setup, then Router/node failed to connect, despite all AiMesh conditions met. I always received the popup stating node too far, etc, and that the 88U was returned to factory. After an hour of failed attempts (I always used RMerlin on Main, yet tried official and RMerlin on node), I returned network back to Main-AP.
I will wait for Beta 2 or RMerlin's official to attempt again.

Did you try using an Ethernet cable to set up your nodes? This worked for me as I was struggling with the same issue. Then I used a cable from the LAN of AiMesh router to the WAN of the node and it set up right away. I made sure to reset the node each time before I tried that setup.
 
Did you try using an Ethernet cable to set up your nodes? This worked for me as I was struggling with the same issue. Then I used a cable from the LAN of AiMesh router to the WAN of the node and it set up right away. I made sure to reset the node each time before I tried that setup.
Yes I tried Ethernet connected and wireless, both saw 88U, yet failed mesh setup.
 
Yes I tried Ethernet connected and wireless, both saw 88U, yet failed mesh setup.
Was the node just reset to factory defaults and no settings on it at all?
 
Was the node just reset to factory defaults and no settings on it at all?
Yes.
Also during a couple of attempts, I began setup, and highlighted "setup as AiMesh node, which took me to the main router's gui to setup AiMesh.
 
Upgraded from 384.12 to 384.13 Beta 1 and tried Quad9 DOT again (instead of Cloudflare).

Still need to reload a page now and then to see all content, as on 384.12.

Does Quad9 really perform that poor?

I have the opposite issue.
Cloudflare won’t deal with all sites, Quad9 will.
Go figure....
 
I have the opposite issue.
Cloudflare won’t deal with all sites, Quad9 will.
Go figure....
I use Quad9 DoT servers as my primaries, with Cloudflare and Google servers as secondaries. I can go for a couple of weeks without a single "need to hit reload a page" issue and, then, I'll get a few instances fairly tightly grouped in time, and then it won't happen for a while... Who knows why?
 
I use Quad9 DoT servers as my primaries, with Cloudflare and Google servers as secondaries. I can go for a couple of weeks without a single "need to hit reload a page" issue and, then, I'll get a few instances fairly tightly grouped in time, and then it won't happen for a while... Who knows why?
For what I understood from the first DOT thread is, that you don't have primaries and secondaries, It is going sequentially through the list. So maybe sometimes you have the wrong DNS at the wrong time. (Please correct me if I'm wrong)
 
For what I understood from the first DOT thread is, that you don't have primaries and secondaries, It is going sequentially through the list. So maybe sometimes you have the wrong DNS at the wrong time. (Please correct me if I'm wrong)
You could be correct. I'm not sure. Attached are my WAN DNS settings. Clipboard01.jpg
 
For what I understood from the first DOT thread is, that you don't have primaries and secondaries, It is going sequentially through the list. So maybe sometimes you have the wrong DNS at the wrong time. (Please correct me if I'm wrong)
You are correct. The way Merlin has Stubby set up (round_robin_upstreams: 1) each resolver is used in turn. Early on there was a bug in Stubby and using this feature solved connectivity issues. Now, I'm not sure it is needed. I have Stubby set to round_robin_upstreams: 0 with Cloudflare and it works well for me. Going to Quad9 with round_robin_upstreams on or off I have connectivity issues but that is due to my ISP.With that said I have two AC68U's with default 394.12 on Quad9 (alternate IPV4/IPV6 resolvers) on Comcast that work just fine.
It boils down to whatever works best for you.

I also do DNSSEC via Stubby and get better results than DNSSEC via Dnsmasq. There again it is my choice. Either way works, Neither way is wrong...
 
I upgraded to 384.13b1 from 384.12 and have aimesh working great. Excellent work, Merlin! I also have great results from root canary using PIA DNS.

I am getting a boot loop going now with a very active "warning" log. I am seeing lots of this and then reboots. Any ideas?

:50 kernel: blk_update_request: I/O error, dev sda, sector 74063
Jul 27 20:33:50 kernel: blk_update_request: I/O error, dev sda, sector 0
Jul 27 20:33:50 kernel: blk_update_request: I/O error, dev sda, sector 74063
Jul 27 20:33:50 kernel: blk_update_request: I/O error, dev sda, sector 0
Jul 27 20:33:50 kernel: EXT4-fs error (device sda1): ext4_find_entry:1461: inode #2: comm find: reading directory lblock 0
Jul 27 20:33:50 kernel: EXT4-fs (sda1): previous I/O error to superblock detected
Jul 27 20:33:51 kernel: EXT4-fs error (device sda1): ext4_find_entry:1461: inode #2: comm find: reading directory lblock 0
Jul 27 20:33:51 kernel: EXT4-fs (sda1): previous I/O error to superblock detected
Jul 27 20:33:51 kernel: EXT4-fs error (device sda1): ext4_find_entry:1461: inode #2: comm find: reading directory lblock 0
Jul 27 20:33:51 kernel: EXT4-fs (sda1): previous I/O error to superblock detected
Jul 27 20:33:51 kernel: EXT4-fs error (device sda1): ext4_find_entry:1461: inode #2: comm find: reading directory lblock 0
Jul 27 20:33:51 kernel: EXT4-fs error (device sda1): ext4_find_entry:1461: inode #2: comm find: reading directory lblock 0
Jul 27 20:33:51 kernel: EXT4-fs error (device sda1): ext4_find_entry:1461: inode #2: comm find: reading directory lblock 0
Jul 27 20:33:51 kernel: EXT4-fs error (device sda1): ext4_find_entry:1461: inode #2: comm find: reading directory lblock 0
Jul 27 20:33:51 transmission-daemon[1703]: watchdir Failed to open directory "/mnt/Data/Torrents-RTX/Watch" (2): No such file or directory (watchdir.c:354)
Jul 27 20:33:52 kernel: Buffer I/O error on dev sda1, logical block 121667584, lost sync page write
Jul 27 20:33:52 kernel: JBD2: Error -5 detected when updating journal superblock for sda1-8.
Jul 27 20:33:52 kernel: Aborting journal on device sda1-8.
Jul 27 20:33:52 kernel: Buffer I/O error on dev sda1, logical block 121667584, lost sync page write
Jul 27 20:33:52 kernel: JBD2: Error -5 detected when updating journal superblock for sda1-8.
Jul 27 20:33:52 wsdd2[4894]: Terminated received.
Jul 27 20:33:53 wsdd2[6029]: Terminated received.
 
Surfnet works well here, ty for the list of options! Been using the big name, popular choices.
I was looking at surfnet, what locations are they mainly at? all around the world? also, has anyone notice a performance difference with DNS over TLS using port 443 vs 853 because i see they also support it on 443 as well.
 
I was looking at surfnet, what locations are they mainly at? all around the world? also, has anyone notice a performance difference with DNS over TLS using port 443 vs 853 because i see they also support it on 443 as well.
The Surfnet server I use is from Netherlands (dnsovertls3... ) , I don't think they have many locations, maybe only one location . If I am not mistaken, 443 is used for DoH (DNS OVER HTTPS) while DoT mainly use port 853
 
The Surfnet server I use is from Netherlands (dnsovertls3... ) . If I am not mistaken, 443 is used for DoH (DNS OVER HTTPS) while DoT mainly use port 853
i wasn't sure because the site seems to suggest they support DoT on 443 as well. I imagine if they did the overhead on 443 would not be that great with the way DoT functions, it would seem it would run better on 853 if such was the case.
 
I was looking at surfnet, what locations are they mainly at? all around the world? also, has anyone notice a performance difference with DNS over TLS using port 443 vs 853 because i see they also support it on 443 as well.

Not many sites according to their map. For me it says Montreal and I'm in TX.

Port was left blank by mistake so I assume 853, will try 443 later tonight.
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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