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.
384.3 beta 2 is now available

Changes:

Code:
c3bf092 Updated documentation
c550d5c rc: merge lan.c from 384_20287, including fixes for Repeater mode
0aea283 shared: disable roaming assistant by default on AMAS models since we don't currently support AMAS
582a23a rc: firewall: fix NSFW rules while in blacklist mode
69ddc52 webui: fix scrollbar positioning on Site Survey for native 384 models under Firefox
c1a9430 webui: fix FAQ links on OpenVPN server page
8816d93 webui: fix FAQ linking for people not using the DUT hostname to access the webui
e394ce3 httpd: gencert.sh: also generate the cfgsync certificate
a197dc1 Bumped revision to 384.3 beta 2
 
Thanks for your continued hard work Merlin as always :)

One bug I have found and I believe it's in the official Asus build also is that my system log is full of the following message "unable to send packet on real device for eth1: No buffer space available" and "unable to send packet on real device for eth2: No buffer space available"

I'm using a 68U and have wireless disabled on the router as I use an Ubiquiti AP. I think the message comes from having WI-FI disabled.

Cheers
 
One bug I have found and I believe it's in the official Asus build also is that my system log is full of the following message "unable to send packet on real device for eth1: No buffer space available" and "unable to send packet on real device for eth2: No buffer space available"

According to Asus you can safely ignore these warnings. They are tied to a service used by AiMesh nodes to communicate.
 
384.3 beta 2 is now available

Changes:

Code:
c3bf092 Updated documentation
c550d5c rc: merge lan.c from 384_20287, including fixes for Repeater mode
0aea283 shared: disable roaming assistant by default on AMAS models since we don't currently support AMAS
582a23a rc: firewall: fix NSFW rules while in blacklist mode
69ddc52 webui: fix scrollbar positioning on Site Survey for native 384 models under Firefox
c1a9430 webui: fix FAQ links on OpenVPN server page
8816d93 webui: fix FAQ linking for people not using the DUT hostname to access the webui
e394ce3 httpd: gencert.sh: also generate the cfgsync certificate
a197dc1 Bumped revision to 384.3 beta 2

I can confirm Repeater mode works again after updating.
 
Thanks Eric for all that you do!
I just updated from 384.3 beta 1 to beta 2 and now all 5 GHz clients are showing as "wired" in the client list. Was OK in beta 1.
 
Thanks Eric for all that you do!
I just updated from 384.3 beta 1 to beta 2 and now all 5 GHz clients are showing as "wired" in the client list. Was OK in beta 1.

Give them time for their DHCP leases to update. There was zero changes to networkmap in this beta.
 
I can confirm Repeater mode works again after updating.
I can also confirm the same. I was able to update my RT-AC68U repeater from 380.69_2 to 384.3 Beta 2, and I successfully connected to the RT-AC68U router. Thanks again for all of your hard work.
 
Wouldn't putting a 2nd router in repeater mode with the same SSID as your main router do about the same thing as the AiMesh business?
 
Wouldn't putting a 2nd router in repeater mode with the same SSID as your main router do about the same thing as the AiMesh business?
Similar, but AiMesh doesn't work with Merlin firmware. Also, I tried AiMesh with wired backhaul at our church, but I reverted to traditional wired access points (still wired backhaul) -- I concluded that AiMesh is still quite flaky.
 
My syslog is being spammed with these entries since I upgraded to 384.3 beta 2 on my AC88u

Feb 8 20:24:29 lldpd[411]: custom TLV op replace oui f8:32:e4 subtype 2
 
Wouldn't putting a 2nd router in repeater mode with the same SSID as your main router do about the same thing as the AiMesh business?

AiMesh is primarly about centralized management, and nodes being able to exchange data.
 
the firmware seems ok generally on RT-AC86U till beta1 (I'm going to try beta2 shortly): The only thing that seems working intermittently is the WiFi scheduler and I really don't know why (and this happens since 382.2betas). I tried also to reset the involved NVRAM parameters, but even if the situation gets normal in this case, after few days is stop working again.
 
Last edited:
Fwiw, just looking at this and wondering whats up with the wifi scheduler, it appears to loose its settings and revert to all times available for both 2.4 and 5 Ghz. This is with the stock version 3.0.0.4.384.20308. From what I had seen previously in stock version 3.0.0.4.384.10007 it appeared to work as it should. So, something has changed in the two last stock versions.
 
Fwiw, just looking at this and wondering whats up with the wifi scheduler, it appears to loose its settings and revert to all times available for both 2.4 and 5 Ghz. This is with the stock version 3.0.0.4.384.20308. From what I had seen previously in stock version 3.0.0.4.384.10007 it appeared to work as it should. So, something has changed in the two last stock versions.


Yes. I have seen this with 10007, & now 20308.
A router reboot wipes all the time settings from the scheduler.

I suspect also, that clearing the Aiprotect log, using the trash can icon, clears scheduled times. Not too sure of this though, will test when I get some time........
 
I've noticed since the 382.x betas I can no longer see the NTFS sparse support in SMB options menu on my AC68U. If I load the page in chrome and stop loading quick enough, it appears but during normal page load it disappears. Or I let the page load, and there's no NTFS sparse support option, if I export the page to HTML then it can be seen there.

And yes I do have a HDD mounted and formatted to NTFS.
 
Last edited:
Uploaded 384.3Beta2 on my ac86u.Unsolved problems about guest network ssid updating
 
Last edited:
c1a9430 webui: fix FAQ links on OpenVPN server page
In that commit you commented out the links with id="faq_macOS", id="faq_iPhone" and id="faq_android". But on lines 186-191, faqURL() is still being called with these id's that no longer exist. That results in a TypeErr: document.getElementById(...) is null at httpApi.js:390.
 
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