What's new

[Release] Asuswrt-Merlin 384.18 and 384.13_10 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.
Is the problem complicated to solve ?
Thanks again for your work. i love merlin firmware!

I think he means its maybe a problem only Asus can resolve.
 
As a workaround for the truncated screen thingy, I propose the following :

1) Type directly the address of a non impacted asuswrt merlin page:

http://router.asus.com/Advanced_DHCP_Content.asp

2) From there, you'll see the language button at the top

3) Change from French to English...et voilà :)

This works for my config and I personally do not consider this bug as a top priority because we have do a way to enjoy 384.18 in English.

Thank you @RMerlin for the work. Greatly appreciated.

Etienne
 
As a workaround for the truncated screen thingy, I propose the following :

1) Type directly the address of a non impacted asuswrt merlin page:

http://router.asus.com/Advanced_DHCP_Content.asp

2) From there, you'll see the language button at the top

3) Change from French to English...et voilà :)

This works for my config and I personally do not consider this bug as a top priority because we have do a way to enjoy 384.18 in English.

Thank you @RMerlin for the work. Greatly appreciated.

Etienne

thank you very much for this solution.
I still sincerely hope that the problem will be resolved quickly because i really like having Merlin in French, I think other people are in the same situation as me.
It is for that matter that I like to use the Merlin firmware.
If everything settings is in English, it is much less practical for me :(

I join @Evictoria for this fabulous work on Merlin firmwares. Well done ! @RMerlin
 
Hey all! Just wondering if anyone has any insight to this issue - after uploading to 384.18 my log is being spammed by:

Jun 30 17:07:08 acsd: eth6 received event: MAC tx failures (exhaustion of 802.11 retries) exceeding threshold(s)​

Any help is much appreciated!
 
Guess what? It's a glitch that's back from 2013! I'm experiencing the same thing as described here:
https://www.snbforums.com/threads/bug-when-applying-a-change-in-admin-system-page.9787/
Also, my router has the name: RT-AC88U -- just as in the thread from 2013 with a dash in the name.
Anyway, I fixed the problem temporarily by entering admin as username and then renaming it later back to what I had.
However, if I want to make a change to that page, then it requires that I enter 'admin' as Router Login Name.
Removing the dash from the router's name did not fix this by the way...
I found the culprit: there was a user with the same username for SMB and FTP. Renamed that user: problems solved!
 
384-18 working well on my AC5300 no problems in 3 days . 38413-10 working well on one of my AC3200 .
thanks agaiun for another great build
 
As a solution of last resort you may use the ASUS Firmware Restoration Tool.
that's what i had to do when i went from 38418 back to 384-17 , a pain but it worked
 
@RMerlin : I think I found a bug ... or something is weird with my router.
I updated my RT-AC88U from 384.17 to 384.18
When I go to Administration page, System tab and try to set Enable local NTP server to yes (I have Unbound running),
then when I click on Save, the page is not saved.
Instead an error is shown for Router Login Name: "This account already exists. Please enter a different name."
Even though I clear this field (it is filled in when I open the Administration page), I cannot save the changes.
I tried entering my password - no luck. I used Safari, Chrome and Firefox - none succeeded.
Do you have any "_" underscore characters in your router login Username? Your same issue happened to me, until I removed the _ characters I had in my Username.
 
Was there ever any sort of fix for this spam in the log? It goes on nonstop... AC88U, MAC in question belongs to a new iPhone SE but has been observed with other devices as well.


Jun 30 22:46:22 syslog: WLCEVENTD wlceventd_proc_event(481): eth1: Disassoc 90:8C:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jun 30 22:46:22 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth 90:8C:XX:XX:XX:XX, status: Successful (0)
Jun 30 22:46:22 syslog: WLCEVENTD wlceventd_proc_event(510): eth1: ReAssoc 90:8C:XX:XX:XX:XX, status: Successful (0)
Jun 30 22:46:33 syslog: WLCEVENTD wlceventd_proc_event(481): eth1: Disassoc 90:8C:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jun 30 22:46:33 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth 90:8C:XX:XX:XX:XX, status: Successful (0)
Jun 30 22:46:33 syslog: WLCEVENTD wlceventd_proc_event(510): eth1: ReAssoc 90:8C:XX:XX:XX:XX, status: Successful (0)
Jun 30 22:46:44 syslog: WLCEVENTD wlceventd_proc_event(481): eth1: Disassoc 90:8C:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jun 30 22:46:44 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth 90:8C:XX:XX:XX:XX, status: Successful (0)
Jun 30 22:46:44 syslog: WLCEVENTD wlceventd_proc_event(510): eth1: ReAssoc 90:8C:XX:XX:XX:XX, status: Successful (0)
Jun 30 22:46:54 syslog: WLCEVENTD wlceventd_proc_event(481): eth1: Disassoc 90:8C:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jun 30 22:46:54 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth 90:8C:XX:XX:XX:XX, status: Successful (0)
Jun 30 22:46:54 syslog: WLCEVENTD wlceventd_proc_event(510): eth1: ReAssoc 90:8C:XX:XX:XX:XX, status: Successful (0)
Jun 30 22:46:58 syslog: WLCEVENTD wlceventd_proc_event(481): eth1: Disassoc 90:8C:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jun 30 22:48:35 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth 90:8C:XX:XX:XX:XX, status: Successful (0)
Jun 30 22:48:35 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc 90:8C:XX:XX:XX:XX, status: Successful (0)
Jun 30 22:48:47 syslog: WLCEVENTD wlceventd_proc_event(481): eth1: Disassoc 90:8C:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jun 30 22:48:47 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth 90:8C:XX:XX:XX:XX, status: Successful (0)
Jun 30 22:48:47 syslog: WLCEVENTD wlceventd_proc_event(510): eth1: ReAssoc 90:8C:XX:XX:XX:XX, status: Successful (0)
Jun 30 22:48:58 syslog: WLCEVENTD wlceventd_proc_event(481): eth1: Disassoc 90:8C:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jun 30 22:48:58 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth 90:8C:XX:XX:XX:XX, status: Successful (0)
Jun 30 22:48:58 syslog: WLCEVENTD wlceventd_proc_event(510): eth1: ReAssoc 90:8C:XX:XX:XX:XX, status: Successful (0)
 
Thanks! Can you tell me please Enable TX Bursting on both should be disable or ?
I have that switched to disabled on 2.4 & 5 from the day I bought my Asus routers.
 
No, it was just a matter of tracking which string required escaping. Already fixed.

In the meantime, the issue only affect the main page. Once logged, access a different page (like http://router.asus.com/Tools_Sysinfo.asp ) then switch the language to English.

great, thank you very much for fixing the bug ! :) Do you have a date for the release of version 384.18_1 ?
thanks again for your work.
 
Was there ever any sort of fix for this spam in the log? It goes on nonstop... AC88U, MAC in question belongs to a new iPhone SE but has been observed with other devices as well.
That's just how Apple device behave on a wireless network. I banned them from my network by configuring dnsmasq not to assign addresses to clients with an OUI that matches Apple's. They give up after awhile.
 
That's just how Apple device behave on a wireless network. I banned them from my network by configuring dnsmasq not to assign addresses to clients with an OUI that matches Apple's. They give up after awhile.
In my experience if you set to wifi / professional / and disable WMM APSD the log file becomes more tranquil. Apple has aggressive battery saving settings (that you cannot change on your phone) causing frequent disconnects that are logged.
When you adjust the WMM APSD it will be less aggressive, hence less disconnects.
It might affect your iphone battery life slightly but who cares.
 
I've updated my RT-AC87U router and my RT-AC68U running in AP mode, all good, thank you RMerlin.

Note for Asus, the Open NAT tab has showed up on the AC68U, there's no need for it in AP mode, not that it bothers me but it may confuse people who are new to the firmware.
 
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