What's new

[Beta] Asuswrt-Merlin 384.10 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.
@RMerlin thanks for fixing the self compilation code. I was able to compile 384.10_beta2. Running it now and it seems to be better than beta1. I know cleaning up coding errors takes time and I appreciate the work you do.
 
Testing (clean install) on AX88U, 2 quick issues so far:

- problems on Dual-WAN (but I know the same problem is present in the ASUS firmware since a friend has exactly the same AX88U and exactly the same problem)

- problem with the refresh for the list of clients (also I believe something that I have seen in the official firmware).

Are those known issues or should I post more details?

Also the 5Ghz wireless starts very late and seems to only work well if I leave it in Auto.
 
Although I unchecked dns query and only checked ping on Network monitoring, router is still sending dns query to dns.msftncsi.com.

Then I have no idea what Asus intends with that setting. It doesn't seem tied to any of the actual check code.
 
still https not working because clock sync , i guess ,loaded old fw same thing . cannot get to https sites on ny network , frustrating

it has decided to work now , strange as i did nothing , it just works
 
Last edited:
still https not working because clock sync , i guess ,loaded old fw same thing . cannot get to https sites on ny network , frustrating

Try this as your ntp server (and don't forget to hit apply): https://www.nrc-cnrc.gc.ca/eng/services/time/network_time.html
Click the link and look for the URL; there are 2 to choose from
Might also help to reboot from inside the GUI while you're there, and reboot any/everything on the network, wired and wireless, just to make sure the handshakes happen.
 
still https not working because clock sync , i guess ,loaded old fw same thing . cannot get to https sites on ny network , frustrating
That happened to me also a couple days ago. I was running a Pi-hole DNS server and once I took that down, things started working. Never happened before, not sure why that was happening.
 
One other thing - the timezone on my AX88U seems to be configured correctly (I believe that was done without me doing anything) but the DST information for my zone (GMT+2 EU) was wrong (and more like the DST info for US - 2nd weekend of March and October instead of last)
 
One other thing - the timezone on my AX88U seems to be configured correctly (I believe that was done without me doing anything) but the DST information for my zone (GMT+2 EU) was wrong (and more like the DST info for US - 2nd weekend of March and October instead of last)
Yes, the settings for the appropriate DST zone (dates of changeover), must always be configured manually, regardless of where you are located.
 
In the syslog there are these warning messages that I don't understand, can anyone explain what problems they are? Thank you.
AX88U (384.10 beta 1)
Mar 15 13:28:39 kernel: tfat error (device sdb1, pid 8919): exfat_ucstonls(): Unicode name contains characters that cannot be converted to character set cp437.
Mar 15 14:00:13 kernel: blog_death_by_timeout: bad timeout value=18446744073709541616, extra_jiffies=30000, idle_jiffies=40000
Mar 15 17:18:15 kernel: eth2 (Ext switch port: 1) (Logical Port: 9) (phyId: 9) Link DOWN.
Mar 15 17:18:18 kernel: eth2 (Ext switch port: 1) (Logical Port: 9) (phyId: 9) Link UP at 1000 mbps full duplex
Mar 15 17:19:48 kernel: eth2 (Ext switch port: 1) (Logical Port: 9) (phyId: 9) Link DOWN.
Mar 15 17:19:51 kernel: eth2 (Ext switch port: 1) (Logical Port: 9) (phyId: 9) Link UP at 1000 mbps full duplex
Mar 15 17:34:09 kernel: br0: received packet on eth7 with own address as source address
 
Just an FYI, still getting hundreds of these in the log. They don't seem to be affecting operation of the router. The dnsmasq seems to be a set of 3 varying numbers-317, 321, or 325:
Mar 14 22:47:45 dnsmasq[317]: failed to send packet: Operation not permitted
Mar 14 22:47:45 dnsmasq[317]: failed to send packet: Operation not permitted
Mar 14 22:47:45 dnsmasq[317]: failed to send packet: Operation not permitted

RT AC-5300
 
In the syslog there are these warning messages that I don't understand, can anyone explain what problems they are? Thank you.
AX88U (384.10 beta 1)
I have the same router and none of these error messages appear. For the first message, did you check your USB drive for errors? The second one looks like it could be related. For the others, try to hide them under LAN/DHCP Server/Hide DHCP/RA queries [Yes]
 
Installed the Alpha 2 about 2 hour ago on my Asus 86u and it just died not turning on just getting the light on Ethernet 4 lighting up
 
Last edited:
In the syslog there are these warning messages that I don't understand, can anyone explain what problems they are? Thank you.
AX88U (384.10 beta 1)

My system logs got flooded with similar "Mar 15 14:00:13 kernel: blog_death_by_timeout: bad timeout value=18446744073709541616, extra_jiffies=30000, idle_jiffies=40000" messages on my Asus RT-AX88U.

I did a factory default reset and everything but they just kept reappearing and my RT-AX88U was not stable as it would report DHCP issues on the WAN connection several times per week.

I've tried 384.10 BETA1, 384.10 Alphas and 384.9 final and BETA's. I had to roll back to 384.8_2 for these messages to disappear from the system logs and my RT-AX88U now seems to be stable.
 
Just an FYI, still getting hundreds of these in the log. They don't seem to be affecting operation of the router. The dnsmasq seems to be a set of 3 varying numbers-317, 321, or 325:
Mar 14 22:47:45 dnsmasq[317]: failed to send packet: Operation not permitted
Mar 14 22:47:45 dnsmasq[317]: failed to send packet: Operation not permitted
Mar 14 22:47:45 dnsmasq[317]: failed to send packet: Operation not permitted

RT AC-5300

Haven't heard back from you - I'd need a copy of that SOA request that's apparently generating these errors, since so far nobody else has reported anything similar, and I can't reproduce it either no matter what I try.
 
@RMerlin
I deactivated the UPnP, but in the AiProtection it is displayed as ON
 
Haven't heard back from you - I'd need a copy of that SOA request that's apparently generating these errors, since so far nobody else has reported anything similar, and I can't reproduce it either no matter what I try.
Sure this wasn’t meant for me? I emailed you about the SOA record that seemed to be linked to this. Don’t think I heard anything after that discovery but happy to continue collecting logs and troubleshooting.
 
@RMerlin
I deactivated the UPnP, but in the AiProtection it is displayed as ON

Possibly a very old bug that came back, where it checks for UPnP support on the secondary WAN even if not using Dual WAN.

Sure this wasn’t meant for me? I emailed you about the SOA record that seemed to be linked to this.

Could be, wasn't sure who was who. Can you PM me the SOA record that seemed to trigger it? Wondering if maybe that SOA might be pointing at a private IP instead of a public one, causing the issue.
 
That happened to me also a couple days ago. I was running a Pi-hole DNS server and once I took that down, things started working. Never happened before, not sure why that was happening.
I'd check the timer servers to see if they are blocked.
 
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