What's new

Beta Asuswrt-Merlin 386.1 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.
Still can't detect RT-AC88U mesh node that was updated to beta 2 and WPS reset with my AC5300. AC5300 was WPS reset after flash, JFFS format, disconnected USB HDD prior.
 
Did a dirty upgrade to beta 2, but still the same problem with my wan disconnecting when I try to start more than one VPN Client. When running just one VPN Client it works great.
 
Do you have your DNS filter in the LAN settings configured to Router? It should look like this:


This will make sure all your outgoing DNS requests are routed through the DNS server configured under your WAN settings.

Yes DNS filter is set to router; note I haven't changed any settings between 384.19 & beta 2

Edited with a sample DNS WAN setting:

Tried setting Cloudflare DNS servers under WAN (rather the Automatic) - this setting change has no effect, I expect it's overridden by the DoT servers setting anyway.

I'm flagging this issue as a change of behaviour between 384.19 & 386.1 betas, not really a big issue to me as I can assign static values on my phone for my home WiFi SSID's to get Diversion ad-blocking.
 
I'm flagging this issue as a change of behaviour between 384.19 & 386.1 betas, not really a big issue to me as I can assign static values on my phone for my home WiFi SSID's to get Diversion ad-blocking.
What’s the output of grep dhcp-option /etc/dnsmasq.conf

There should not have been any change to how this normally works. Is the device connected to the main SSID and not a guest network?
 
Did a dirty upgrade to beta 2, but still the same problem with my wan disconnecting when I try to start more than one VPN Client. When running just one VPN Client it works great.

Same but different: 2 x ‘idevice's’ here, 1 x can connect via VPN at a time, both, no.
Attempting two doesn’t affect WAN, just kicks the other device off VPN. :oops:
Not a huge issue, prolly just Apple strangeness? (Shrug).
 
Beta2 dirty install over Beta1 on ax86. Everything running smoothly.
At the moment no new issues found
 
I had a strange issue both with 386 beta 1 and beta 2. After updating from 384, I could no longer access my QNAP NAS via web interface, FTP, SSH and lost all file sharing access too. The NAS is setup for DHCP and IP address binding from the RT-AC86U.

I could connect up to the NAS directly and everything works fine. When I connect back up to the router, I can see it in the Client list, but cannot access it nor ping it.
I went back to 384 and no problems.

Any idea what could be wrong?
 
Did you reboot the NAS during your testing? What version of '384' did you update from? Did you do a full reset after flashing 386.1 Beta 2?
 
The last 384 release. I didn't do a full reset of the router, haven't had to for a long time and previous releases.

The NAS was rebooted several times with no joy. I could see it appearing in the client list and tried accessing it from various devices on the network with no luck.

It only came good when I referred back to the 384 version.
 
The last 384 release doesn't mean anything. So, when was the last time the router was fully reset? From which firmware to the latest Beta did you flash it from? What router are you talking about?
 
What’s the output of grep dhcp-option /etc/dnsmasq.conf

There should not have been any change to how this normally works. Is the device connected to the main SSID and not a guest network?

Connected to the main SSID

Code:
dhcp-option=lan,3,192.168.131.1
dhcp-option=lan,15,131kk.lan
dhcp-option=lan,44,192.168.131.121
dhcp-option=lan,252,"\n"
dhcp-option=dnsf5,option6:23,[2a02:6b8::feed:bad],[2a02:6b8:0:1::feed:bad]
dhcp-option=dnsf6,option6:23,[2a02:6b8::feed:a11],[2a02:6b8:0:1::feed:a11]
dhcp-option=dnsf13,option6:23,[2620:fe::fe],[2620:fe::9]
dhcp-option=dnsf14,option6:23,[2a0d:2a00:1::2],[2a0d:2a00:2::2]
dhcp-option=dnsf15,option6:23,[2a0d:2a00:1::1],[2a0d:2a00:2::1]
dhcp-option=dnsf16,option6:23,[2a0d:2a00:1::],[2a0d:2a00:2::]
dhcp-option=lan,option6:23,[::]
dhcp-option=lan,option6:24,131kk.lan
dhcp-option=br1,3,192.168.101.1
dhcp-option=br2,3,192.168.102.1
dhcp-option=lan,42,192.168.131.1 # ntpMerlin
 
Would it be wrong to wish for brand new Merlin FW for Christmas??? :)

I know it's one of the things on my list :)
No, but you're not going to make it easy for good old Santa. "Who's this Merlin now? Oh right, the wizard! Was an old pal of mine but I haven't seen him in centuries... how am I supposed to get hold of him now?? Let alone 386 of them..."
 
You won`t get anything from Let's Encrypt if you already have a certificate still valid for at least one month.

Ah, so if the files written to the JFFS was the trigger for my strange issues I guess it could come back next time Let's Encrypt updates. But I don't see why and how it could break things like that. Unless it overwrites something I dont see how enabling Let's Encrypt could actually do anything affecting NTP/scripts and stuff.
 
On Beta2, factory reset.
Log is filling up with this:

Dec 15 10:08:12 kernel: protocol 0800 is buggy, dev eth6
Dec 15 10:08:12 kernel: protocol 0800 is buggy, dev eth7
Dec 15 10:08:16 kernel: protocol 0800 is buggy, dev eth7
Dec 15 10:08:16 kernel: protocol 0800 is buggy, dev eth7
Dec 15 10:08:16 kernel: protocol 0800 is buggy, dev eth7
Dec 15 10:08:16 kernel: protocol 0800 is buggy, dev eth7

Edit: Using RT-AX88U, merlin 386.1 beta 2
 
Last edited:
Status
Not open for further replies.

Sign Up For SNBForums Daily Digest

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