What's new

[Beta 384/NG] Asuswrt-Merlin 384.3 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.
Please, can you explain more about what did you do with Adaptative QoS to fix AiProtection? I can confirm that with this error in log, AiProtection is not loaded correctly into memory thus not working although seems ok in admin ui

I think all I did was change Adaptive QoS mode from Customize to Media then apply. I might have changed it back to Custom afterward, I don't remember since this was on a development device.
 
Bug in traffic analyzer - statistic tab. RT-ac68u. There are 12 clients active at the moment on this device. The graph on the upper half of the page works correctly for the daily report for all 12 clients. However the title and stats table in the lower half only display the stats for the first 6 clients. Clients 7-12 show a frozen title and table last seen for the client 6. Photo attached - client 6 was android, showing selected is client 7 cisco spa ata... table title and table stats don't update for 7-12. Same for weekly and monthly.

Also may be a bug with the All clients / All apps pull down selector. When you change an all clients display by switching from daily to weekly or monthly it flips the selector from all clients to all apps even though you did not not change the router/application button. You then have to flip the router/app button back and forth until all clients comes back.
Are those bugs in the official Asus firmware?
 
Last edited:
this has probably been asked before in previous threads but i gather Rmerlin that AImesh will not be supported ever on the RT-AC88U

if it will be added later though thats great news :) though im sure i remember someone saying the source code was asus closed source ect.
 
I cant get per device monitoring to show up on tools > other settings as I used to on previous firmwares.
The data files are stored on an external usb but the option just wont show up.
This is on an ac86u, is there some additional step I need to take? My subnet is 192.168.0.x
 
Are you those bugs in the official Asus firmware?

I don't know. This is the thread for 384.3 beta 3 firmware which merges Asus GPL 384_10007. Perhaps someone running that Asus official code can compare if need be? I was noting them here mostly for those people keeping a list of things to investigate or fix. If this area of code is closed source then it would be in the official for sure.
 
Love the work your doing Rmerlin!!!! I do have one issue that I've noticed since trying the 382 beta through to 384.3 beta 3. On my Asus AC-68P the Let's Encrypt certificate request gets stuch at "Updating...". Looking at the log, I'm seeing an invalid request response:

Feb 13 07:39:59 kernel: /usr/sbin/acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: bad HTTP: 400
Feb 13 07:39:59 kernel: /usr/sbin/acme-client: transfer buffer: [{ "type": "urn:acme:error:malformed", "detail": "Error creating new authz :: DNS name does not have enough labels", "status": 400 }] (137 bytes)

If it's useful information, I'm currently using DDNS supplied by www.namecheap.com and I do not have wildcard enabled.
 
Love the work your doing Rmerlin!!!! I do have one issue that I've noticed since trying the 382 beta through to 384.3 beta 3. On my Asus AC-68P the Let's Encrypt certificate request gets stuch at "Updating...". Looking at the log, I'm seeing an invalid request response:

Feb 13 07:39:59 kernel: /usr/sbin/acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: bad HTTP: 400
Feb 13 07:39:59 kernel: /usr/sbin/acme-client: transfer buffer: [{ "type": "urn:acme:error:malformed", "detail": "Error creating new authz :: DNS name does not have enough labels", "status": 400 }] (137 bytes)

If it's useful information, I'm currently using DDNS supplied by www.namecheap.com and I do not have wildcard enabled.

No idea what are the actual requirements for LE. Maybe they require the use of Asus's own DDNS.
 
I don't know. This is the thread for 384.3 beta 3 firmware which merges Asus GPL 384_10007. Perhaps someone running that Asus official code can compare if need be? I was noting them here mostly for those people keeping a list of things to investigate or fix. If this area of code is closed source then it would be in the official for sure.
That traffic analzyer bug has been there for a long time. I think the last build that worked correctly was 368.xx
 
No idea what are the actual requirements for LE. Maybe they require the use of Asus's own DDNS.
LE requires a router supported ddns account (check ddns drop down on the ddns page) and an open https port then it works ok. I will advise it is buggy. I tried it and had all kinds of issues the most vital was httpd crashing.
 
Love the work your doing Rmerlin!!!! I do have one issue that I've noticed since trying the 382 beta through to 384.3 beta 3. On my Asus AC-68P the Let's Encrypt certificate request gets stuch at "Updating...". Looking at the log, I'm seeing an invalid request response:

Feb 13 07:39:59 kernel: /usr/sbin/acme-client: https://acme-v01.api.letsencrypt.org/acme/new-authz: bad HTTP: 400
Feb 13 07:39:59 kernel: /usr/sbin/acme-client: transfer buffer: [{ "type": "urn:acme:error:malformed", "detail": "Error creating new authz :: DNS name does not have enough labels", "status": 400 }] (137 bytes)

If it's useful information, I'm currently using DDNS supplied by www.namecheap.com and I do not have wildcard enabled.
Your ddns service is not listed in the supported ddns providers but there is a custom feature I have not tried.
 
Same as with RT-AC87U: the source code was released too late during the 384.3 development cycle, supporting it would have required me to ditch 2+ weeks of work and start all over again with a new GPL.

384.3 is based on 384_10070, with the models already supported by that specific GPL (and previous ones). New models introduced in 384_20287 will have to wait for 384.4, which should be based on 384_20308 (which I only just got the GPL this morning).

Not wanting to be too much of a distraction but does this mean the AC87U is included in the 384 firmware? I ask as 382 only just came out so I wondered if it might be a long time, if ever.
 
Not wanting to be too much of a distraction but does this mean the AC87U is included in the 384 firmware? I ask as 382 only just came out so I wondered if it might be a long time, if ever.

That's what I need to determine, whether the 382_5010 components can be used with the 384_20308 GPL code.
 
Not wanting to be too much of a distraction but does this mean the AC87U is included in the 384 firmware? I ask as 382 only just came out so I wondered if it might be a long time, if ever.
Yes , in the stock ASUS 384.20308, but not yet in the Merlin version...
 
In the last few firmwares, my USB 3 speed has dropped from 95-100MBs to 55MB from PC to HD with big files. Verified with Networx speed meter too.
Interference is off as usual. Did anything change in that area recently?

Edit: DL from router to PC 85MB/s
UL to Router 56MB/s
 
Last edited:
You don't need to turn on web access, and I think web access from port 80 is no longer supported I think?
Check out the article you posted it says to allow web access on 8443 :rolleyes:
 
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