[Beta] Asuswrt-Merlin 384.13 Beta is now available

[nzwayne]

Always now for me "firmware recovery & NVRAM erase" on changing ASUS router code, just seems to make them more stable in coming days/weeks. 5GHz on RT-AX88U router turns on/off/on in about a 10 second cycle after you disable/enable the 160GHz in the 5GHz Professional panel. Earlier merlin code releases, needed to have 160MHz on to have the 5GHz enabled. Smart connect disabled, otherwise my earlier vintage Epson printer won't connect to the 2.4GHz.
One RT-AC86U was working in Wireless AP repeater mode at a cottage. Alpha2 kept dropping the 5GHz after a day or two and couldn't log on again to 5GHz. Reboot the router all ok for next day or two. Beta1 all ok after after three days, as was the GA 384.12 code level. Back from that cottage now, will place this router back into my wired backbone.
Everything just seems a little quicker/snappier with this 384.13 Beta1 over the Alpha1 & 2.
Next...to play with AiMesh with the AX88U and two AC86U's on a wired connection...key though, my partner must leave the house for a few hours...

 

[RMerlin]

Just curious does anyone even use Smart Connect? Even yourself @RMerlin

No.

 

[joe scian]

No.

the single most useless addition to routers Asus ever made

 

[Swistheater]

the single most useless addition to routers Asus ever made

That and mac filtering

 

[telUK]

I'm on 384.11_2, not been following the thread for a while but recently I have noticed my ac86u rebooting/crashing, only the last week or so have I noticed it happening strangely.

Noticed it twice in the last 2 weeks when I have been browsing the internet, suddenly my browser reports no internet, look at the ac86u and see the standby light flashing.

Internet comes back in minutes.

Was this a known issue on 384.11?

I will update to 384.13 when it's released, just strange I have noticed this after so long, and the system log resets to sometime in May so I can't see what the issue is.

 

[Clark Griswald]

Beta 1 has been flawless in my Main-AP setup!!
Easily survived everything Family/Friends threw at it, this weekend.
As Always, Thank You RMerlin!!

 

[Clark Griswald]

I'm on 384.11_2, not been following the thread for a while but recently I have noticed my ac86u rebooting/crashing, only the last week or so have I noticed it happening strangely.

Noticed it twice in the last 2 weeks when I have been browsing the internet, suddenly my browser reports no internet, look at the ac86u and see the standby light flashing.

Internet comes back in minutes.

Was this a known issue on 384.11?

I will update to 384.13 when it's released, just strange I have noticed this after so long, and the system log resets to sometime in May so I can't see what the issue is.

You really should update your fw, and a full reset. Paging @L&LD

 

[QuikSilver]

I'm on 384.11_2, not been following the thread for a while but recently I have noticed my ac86u rebooting/crashing, only the last week or so have I noticed it happening strangely.

Noticed it twice in the last 2 weeks when I have been browsing the internet, suddenly my browser reports no internet, look at the ac86u and see the standby light flashing.

Internet comes back in minutes.

Was this a known issue on 384.11?

I will update to 384.13 when it's released, just strange I have noticed this after so long, and the system log resets to sometime in May so I can't see what the issue is.

You need to start your own thread. This thread is for people who have updated to 384-13 beta 1 to report any issues they have noticed.

 

[heysoundude]

or to the node it makes contact with. it will not bounce to another node. For example, i have security cameras that are pretty close to the out side signals of two nodes, sometimes it wants to connect to one node and sometimes the other. I added it to the roaming block list and it seems to be staying on the node it made first contact with, with no problems.

This may be useful for people with stationary devices that never change position because I can imagine there is no need for a security camera or a computer that never moves locations, to really need to be "roamed" on the network.

For those type of situations, it may be beneficial for your wireless traffic if you define them on the roaming block list, I imagine it would save resources and be helpful for overall wireless performance.

It can definitely be beneficial from a LAN POV to keep stationary devices tethered to a particular node in this manner; I'd consider these to be "virtually wired"

 

[RMerlin]

the single most useless addition to routers Asus ever made

There must be a fair number of users that use it, since there's been frequent complains from RT-AC68U users who wanted that feature added to their router.

Some people prefer to have a fire-and-forget type of setup rather than manually allocating clients to specific bands. And with tri-band routers, it allows to split clients between the two 5 GHz radios without having to manually allocate them.

 

[Elmer]

384.13 beta 1: Just meshed my AX88 with a, reset to latest stock firmware, AC88, using an ethernet backhaul. Seems to be working great. Only hiccup was that the 5 GHz band reset to auto, and I had to set it back to a specific channel and then got overlap. Can I still use the LAN ports on the aimeshed node router as a remote hub? If so, will the backhaul to the WAN supply the hub or do you run a separate line to a LAN port to use it as a repeating hub like you would with any old unmanaged switch? Got 8 LAN ports back there - hate to see them go to waste.

 

[Grisu]

384.13 beta 1: Just meshed my AX88 with a, reset to latest stock firmware, AC88, using an ethernet backhaul. Seems to be working great. Only hiccup was that the 5 GHz band reset to auto, and I had to set it back to a specific channel and then got overlap. Can I still use the LAN ports on the aimeshed node router as a remote hub? If so, will the backhaul to the WAN supply the hub or do you run a separate line to a LAN port to use it as a repeating hub like you would with any old unmanaged switch? Got 8 LAN ports back there - hate to see them go to waste.

You just meshed them, so you could easily see on you own that you can use the ports like they where on main router.
And you could disable Wifi on node with poper SSH commands. But really, whats the benefit of Aimesh then, run it in AP mode and disable Wifi.

 

[FTC]

Hi, just a brief post to report no issues here with 384.13 beta on my ax88 in non-aimesh configuration for 3 days already. Features I use : DDNS, DNSSEC, DNSFILTER, VPN, Samba, DLNA, Guest Wifi, DHCP, IPTV, entware, diversion, transmission and a RP-AC68 connected in access point mode (cabled). Very solid network in fact. Alpha 2 also ran flawless for 1 week before.

Thanks Merlin and all the team for the good work!

 

[ferko]

Asuswrt-Merlin 384.13 Beta is now available for all supported models. While the list of changes isn't as long as recent releases, this one introduces some significant changes, primarily in supporting AiMesh (for compatible models).

The highlights:

• AiMesh support for both router and nodes. See the AiMesh section below for more information.
• Updated RT-AX88U to GPL 384_6210
• dnsmasq now uses OpenSSL instead of Nettle for DNSSEC cipher operations. This allows dnsmasq to validate a wider range of ciphers.
• Note for developers, the dhcp_staticlist format was changed to revert back to the same format as stock firmware (for AiMesh compatibility). The hostname field was moved to a separate variable, dhcp_hostnames. Note that this variable will be stored in a jffs file on the RT-AC86U and RT-AX88U due to limitations on variable length for their HND platform. That means that a backed up config file will not restore these hostnames when restored (but using a JFFS backup will).
• Some changes also had to be done to the webs_* variables that are used by the new firmware checks, which might affect script developers that were accessing those variables.
• A number of minor issues were fixed, see the Changelog for details

Things in need of testing:

• After updating for the first time to a 384.13 build, make sure your DHCP static leases and their defined hostnames are still properly shown on the webui, and that you are still able to add/edit them.
• Test AiMesh compatibility, mixing stock and non-stock firmware versions on your nodes
• Test downgrading/upgrading firmware releases on your nodes

Please only post in this thread about this specific beta release.

Downloads are here.
Changelog is here.

The Merlin 384.13 Beta has big issues vpn client doesnt work if you want get vpn for all devices conects on , you have to write mac adress for all devices and than does not conect exemple 192.168.50.0/24 doesnt work.

 

[skeal]

The Merlin 384.13 Beta has big issues vpn client doesnt work if you get vpn for all devices ,

Keep reading, he explains that problem in his next post. It's a known issue and will be corrected next beta.

 

[Magnus33]

Interesting it seems there something of a issue going on. AC86U beta 1 is seeing quite a bit of this going on.


Had multiple devices from my tv to my harmony hub and even my phone just flat out loose all connection.

Jul 29 18:41:57 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.62: Resource temporarily unavailable
Jul 29 18:42:00 kernel: net_ratelimit: 3731 callbacks suppressed
Jul 29 18:42:05 kernel: net_ratelimit: 4981 callbacks suppressed
Jul 29 18:42:10 kernel: net_ratelimit: 2040 callbacks suppressed
Jul 29 18:42:10 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.177: Resource temporarily unavailable
Jul 29 18:42:15 kernel: net_ratelimit: 5728 callbacks suppressed
Jul 29 18:42:20 kernel: net_ratelimit: 4236 callbacks suppressed
Jul 29 18:42:23 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.141: Resource temporarily unavailable
Jul 29 18:42:25 kernel: net_ratelimit: 2483 callbacks suppressed
Jul 29 18:42:30 kernel: net_ratelimit: 842 callbacks suppressed
Jul 29 18:42:34 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.62: Resource temporarily unavailable
Jul 29 18:42:35 kernel: net_ratelimit: 4078 callbacks suppressed
Jul 29 18:42:40 kernel: net_ratelimit: 2056 callbacks suppressed
Jul 29 18:42:45 kernel: net_ratelimit: 4330 callbacks suppressed
Jul 29 18:42:46 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.141: Resource temporarily unavailable
Jul 29 18:42:50 kernel: net_ratelimit: 3575 callbacks suppressed
Jul 29 18:42:55 kernel: net_ratelimit: 69 callbacks suppressed
Jul 29 18:42:57 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.177: Resource temporarily unavailable
Jul 29 18:43:00 kernel: net_ratelimit: 388 callbacks suppressed
Jul 29 18:43:05 kernel: net_ratelimit: 63 callbacks suppressed
Jul 29 18:43:11 kernel: net_ratelimit: 76 callbacks suppressed
Jul 29 18:43:13 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.64: Resource temporarily unavailable
Jul 29 18:43:16 kernel: net_ratelimit: 73 callbacks suppressed
Jul 29 18:43:21 kernel: net_ratelimit: 66 callbacks suppressed
Jul 29 18:43:26 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.64: Resource temporarily unavailable

Physically turning the router off and on did cure the problem for the moment.

 

[bluepoint]

Do you mean dnsleak.com?

That only shows the IP of the DNS server?

Use this instead https://browserleaks.com/ip for about 1/3 of the page down, it'll tell you your DNS's server location.

 

[Swistheater]

Interesting it seems there something of a issue going on. AC86U beta 1 is seeing quite a bit of this going on.


Had multiple devices from my tv to my harmony hub and even my phone just flat out loose all connection.

Jul 29 18:41:57 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.62: Resource temporarily unavailable
Jul 29 18:42:00 kernel: net_ratelimit: 3731 callbacks suppressed
Jul 29 18:42:05 kernel: net_ratelimit: 4981 callbacks suppressed
Jul 29 18:42:10 kernel: net_ratelimit: 2040 callbacks suppressed
Jul 29 18:42:10 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.177: Resource temporarily unavailable
Jul 29 18:42:15 kernel: net_ratelimit: 5728 callbacks suppressed
Jul 29 18:42:20 kernel: net_ratelimit: 4236 callbacks suppressed
Jul 29 18:42:23 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.141: Resource temporarily unavailable
Jul 29 18:42:25 kernel: net_ratelimit: 2483 callbacks suppressed
Jul 29 18:42:30 kernel: net_ratelimit: 842 callbacks suppressed
Jul 29 18:42:34 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.62: Resource temporarily unavailable
Jul 29 18:42:35 kernel: net_ratelimit: 4078 callbacks suppressed
Jul 29 18:42:40 kernel: net_ratelimit: 2056 callbacks suppressed
Jul 29 18:42:45 kernel: net_ratelimit: 4330 callbacks suppressed
Jul 29 18:42:46 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.141: Resource temporarily unavailable
Jul 29 18:42:50 kernel: net_ratelimit: 3575 callbacks suppressed
Jul 29 18:42:55 kernel: net_ratelimit: 69 callbacks suppressed
Jul 29 18:42:57 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.177: Resource temporarily unavailable
Jul 29 18:43:00 kernel: net_ratelimit: 388 callbacks suppressed
Jul 29 18:43:05 kernel: net_ratelimit: 63 callbacks suppressed
Jul 29 18:43:11 kernel: net_ratelimit: 76 callbacks suppressed
Jul 29 18:43:13 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.64: Resource temporarily unavailable
Jul 29 18:43:16 kernel: net_ratelimit: 73 callbacks suppressed
Jul 29 18:43:21 kernel: net_ratelimit: 66 callbacks suppressed
Jul 29 18:43:26 dnsmasq-dhcp[17358]: Error sending DHCP packet to 192.168.1.64: Resource temporarily unavailable

Physically turning the router off and on did cure the problem for the moment.

you should read this .... may shine alittle light on what may have happen.
https://bani.com.br/2015/06/linux-getting-rid-of-net_ratelimit-n-callbacks-suppressed-messages/
basically everything went spazztastic all at once, who knows what caused it (DoS attack maybe or DHCP service failure with ISP "internet connection loss"), but the kernel net_ratelimit is packets that are being suppressed probably in regards to all the crashes with the dhcp service.

 

[RAH-66]

Changelog is here.
In 384.12
- UPDATED: RT-AC3200 and RT-AC87U to 382_51640/51634 binary blobs

For RT-AC87U updated to 382_51640?

GPL of ASUS RT-AC87U for firmware 3.0.0.4.382.51640 2019/07/11
https://dlcdnets.asus.com/pub/ASUS/wireless/RT-AC87U/GPL_RT_AC87U_300438251640.zip

 

[telUK]

You really should update your fw, and a full reset. Paging @L&LD

Yeah, I will, but I may wait until 384.13 is out of beta.