[Release 384/NG] Asuswrt-Merlin 384.3 is now available

[RMerlin]

Thanks! Would not have looked there without your pointer..

Apparently it’s currently set to “None”

Should I change this to “Import/Persistent Auto-generated” to use my own?

(It seems to be using my certificate anyway)

Yes, otherwise it will generate a new one on restarts.

Installed 384.3 on my AC68U (upgraded from 380.69_2) and even after performing a factory reset I think I'm seeing some lag on both 2.4 and 5 GHz compared to the older generation (Apple devices mostly).

Disable Airtime Fairness and Implicit Beamforming. Forget the SSID on your mobile devices and reconnect them.

Are you going to add support for Let's Encrypt certificate issuing and renewal from the DDNS tab, also for RT-AC3200?

Unknown yet. It's closed source, so I cannot add it to every models.

Can I update straight from there to the new Merlin 384.3 build or do I need to jump to some intermediary build before that?

378.55 should be fine, be prepared to do a factory default reset after flashing.

 

[Mieszko]

Hello,
I have just upgraded my RT68U to next-gen 384.3. One question: where is the option to upload own HTTPS SSL certificate? I used to exist in the legacy branch, under adminisration tab.

 

[RMerlin]

Hello,
I have just upgraded my RT68U to next-gen 384.3. One question: where is the option to upload own HTTPS SSL certificate? I used to exist in the legacy branch, under adminisration tab.

Asus added it to the DDNS tab since the Let's Encrypt support is tied to it. To avoid splitting related settings, I have kept it there for those models with LE support.

 

[username0475]

Disable Airtime Fairness and Implicit Beamforming. Forget the SSID on your mobile devices and reconnect them.

Question: is it best practice when doing a big Firmware update like this 384.3 to reset all the clients (smart devices, smart switches, smart phones) also?

Thanks Merlin for everything!

 

[agilani]

Having the same problem with my wireless upgrading from 380.69 code base to 382/384 on my ac3100. After reboot everything works ok for awhile and then after 5 to 6 hours the wireless becomes completely unresponsive and access to my ac66 and ac68 repeaters both running merlin as well. For now I've disabled IGMP proxy and snooping to see if that makes any difference. Not sure what's going on. CPU and memory both look fine. Wired connections are also fine. Definitely a problem with wireless and wireless repeaters.

Update - It doesn't look like IGMP proxy or snooping are the culprit. Basically after the upgrade and between 2 to 6 hours of time, the latency on both bands of wireless go through the roof (100 to 200 ms latency) compared to less than 10 before. At that point the wireless becomes unresponsive. My setup is a central ac3100 and two repeaters, one running ac66 and the ac68. All are running asus merlin. The cpu and memory look fine so i'm not sure what would be causing the error. I will be looking at the debug logs next. Hopefully that will show something. For now I've had to revert back to 380.69

 

[Sanna1967]

Question: is it best practice when doing a big Firmware update like this 384.3 to reset all the clients (smart devices, smart switches, smart phones) also?

Thanks Merlin for everything!

If you have issues after, normally, just disconnect and reconnect the clients is enough

 

[Hunterx]

Please explain how a VPN client on a PC has anything to do with VPN in a router?

I use a VPN client on my desktop , VPN is off in my router and always has been.

It probably doesn't, but the firmware 100% has a bug in it causing the issue. I verified that the STOCK Asus firmware has the same issue starting with FW_RT_AC68U_300438410007. I have used FW_RT_AC68U_300438218881 and did not experience this issue. I see the same behavior after I upgraded to RT-AC68U_384.3_0. RT-AC68U_380.69_2 is completely fine.

I have flashed my router so far 7 times to test this. from RT-AC68U_380.69_0, to RT-AC68U_384.3_0, then back to RT-AC68U_380.69_0, then RT-AC68U_380.69_2, then FW_RT_AC68U_300438420308, then RT-AC68U_380.69_2, then FW_RT_AC68U_300438410007, then back to RT-AC68U_380.69_2. Every time I flash to 384, the issue comes back. Every time I flash to 380, the issue is fixed.

I have no clue what the issue is. The logs seem clean. I cant explain why a windows client is having issues. No speed issues with VPN off as far as I can tell.

 

[RMerlin]

Question: is it best practice when doing a big Firmware update like this 384.3 to reset all the clients (smart devices, smart switches, smart phones) also?

Thanks Merlin for everything!

It's usually not necessary, but some clients might be more picky than others, some firmware updates might have more radical wireless changes, etc... It's a case-by-case basis usually.

 

[sirwifi]

@RMerlin BUG REPORT: for Guest wifi networks, the time limit does not seem to work. If I set it to 1 hour it keeps showing 59 min. left forever and it's not only a GUI issue, the actual guest SSID doesn't go away after 1 hr.

 

[florid]

This version’s dualwan definitely not work in load balance mode. Tried to enable/disable route rules, no help to fix Internet access issue. I can see the connection out but in time waiting status. Seems like the TCP handshake cannot properly established or the return packs are not properly delivered to the correct WAN link.
At this point I can only use dualwan failover mode which works normal. Interesting thing is on the backup link, it will show cold standby which no IP address obtained, hot standby which has IP either thru pppoe or dhcp.
I will try asus stock firmware of the dualwan load balance to see whether it is a bug.

 

[zitev]

Do you mean in the FTP Share settings?

Ohh, of course, sorry...

 

[Zolpho]

I upgraded my RT-AC88U from 380.68_4 to 384.3 (did a factory reset)
It's running stable since a couple of days.

I'm running a CentOS server (Asterisk) on a QNAP TS-253B (Virtualization Station) and the iptables logs are showing me this string every 2 minutes:

Feb 19 10:46:30 localhost kernel: iptables_INPUT_denied: IN=eth0 OUT= MAC=01:00:5e:00:00:01:10:7b:44:ac:aa:c8:08:00 SRC=0.0.0.0 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0xC0 TTL=1 ID=0 DF PROTO=2

I'm not a network specialist, but this looks like a multicast packet sent by my AC88U to all my LAN devices.
I never had this with firmware 380.68_4

I tried to enable the following option (this has always been disabled in the past):
LAN/IPTV -> Enable multicast routing (IGMP Proxy)

and iptables is not logging the strings above anymore.

Doing that I have now a new entry in my Asus logs:

Feb 19 10:48:20 kernel: rtk port_phyEnableAll Failed!(-1)

Is that something to worry about?
Are my iptables supposed to log the multicast packets with the option "Enable multicast routing (IGMP Proxy)" disabled? Why they did not appear in firmware 380.68_4 ?
I'm not using IPTV options at all.

I can probably just ignore the multicast packets, but I would like to understand which scenario is the best in terms of performance: having iptables logs about multicast packet drops or enable the multicast routing?

Thanks

 

[lbradio]

Last night I updated to 384.3. RT-AC88U
Until this build I was able to hide my Guest WIFI. 2,4GHz, 1 and 3.
I noticed config 3 is now used for IFTTT, so I moved one of the configs to WIFI 2.

With

nvram set wl0.2_closed=1
nvram commit
service restart_wireless​

I usually could hide the SSID. But now it stays visible.

Please advise.

 

[cdturri]

Hi, I have updated my RT-AC68U to 384.3 today. I experienced some login issues (see this thread) but these are now sorted. The other problem I got is that my DDNS doesn't seem to be updating. I am using no-ip.com and Let's Encrypt. Here is how much DDNS looks like. when I click on Apply I get a message that says: "IP address, server and hostname have not changed since the last update. If you want to update, please click [Yes]". However the options are OK or Cancel. Clicking on OK does not trigger a DDNS update as I can see the IP registered on no-ip.com is not my current IP. Any ideas?

 

[muffintastic]

I'm not sure if anyone has experienced this, when I upgraded to the new build (384.3) working flawlessly for about two days then strange things started to occur from;

1. Slow, laggy GUI - When logging into the router
2. NAT errors occurring when UPNP was enabled - Breaking all port forwarding regardless if it was on or off and breaking the internet effectively no internet whatsoever if UPNP was enabled.

So, rather than be a hindrance I reset the NVRAM once again, then again using the WPS button then re-flash 384.3 build, setup once again working.. Then it would break again after about 24 hours of testing.

Before these problems, I was on 380.69_2 which ran sweet as a nut so, I decided to flash back, obviously clearing and resetting the NVRAM from 384.3 - boot into recovery mode then use the Asus FW Restore utility, uploaded then the programme reported that it couldn't be flashed - so OK, so reset, still on 384.3 managed to flash the previous FW through the GUI, no problems, back to 380.69_2, setup all my information, WiFi etc, then had to reboot, would you believe constant soft boot loop, so my testimonial is that 384.3 is buggy and breaks everything even if you're on a previous build, build 380.69_2 was working flawlessly, UPNP etc.

So, in the end I flashed and cleared NVRAM 384.3 and flashed 384.4 alpha build, been running 48 hours without a glitch touched wood. I might add this is all on a RT-AC3200 - Unless @RMerlin can correct me on something on why UPNP breaks everything in 384.3 then I can speak from my testimonial and maybe other users whom are running the 384.3 have no problems or can replicate this issue, all I know from experience 384.3 is somewhat borked.

 

[M@rco]

@RMerlin, I know there's most likely nothing you can do about it, but after the 384 alphas and betas, I returned to 380.69_2 where QoS worked out of the box. This morning I decided to take another go at it and did a clean install of 384.3 stable, but unfortunately QoS is still not working on my RT-AC68U (HW Rev E1). This post is just to let you know. I'll stick with 384.3, regardless whether QoS works or not for now, but at least you know now I gave it another try

 

[agilani]

Update - It doesn't look like IGMP proxy or snooping are the culprit. Basically after the upgrade and between 2 to 6 hours of time, the latency on both bands of wireless go through the roof (100 to 200 ms latency) compared to less than 10 before. At that point the wireless becomes unresponsive. My setup is a central ac3100 and two repeaters, one running ac66 and the ac68. All are running asus merlin. The cpu and memory look fine so i'm not sure what would be causing the error. I will be looking at the debug logs next. Hopefully that will show something. For now I've had to revert back to 380.69

After some more testing - the wireless latency issue that pops up is not due to igmp proxy or snooping or airtime fairness or mimo or implicit or explicit beamforming. i get the same wireless latency issues on all of my wireless devices on the ac3100 with no visible cpu loss or memory. Wired connections work fine with no latency. The debug logs don't show anything either. So I'm back to 380.69 again.

Anyone else using multiple repeaters with 384.3? I'm starting to think this may be an issue with repeaters and this code base.

 

[Enzo]

AC-3200 on 384.3, (Thank You)

However NAT Accel not working?

I cant select to Auto, upon "apply settings" always return with "Disabled"

Read mouse over text hinting at other services/features may conflict, and 1 by 1 I turned them ALL off, still comes back after "apply" with Disabled...

Anyone else seeing this? I am NOT on PPOE

Thanks,
Enzo

• NAT acceleration for PPPoE has been fixed for most models (can't provide a definitive list since I can't test it)

 

[Piratdjinn]

Anyone else experiencing problems when adding devices and setting or changing addresses through DHCP?
Every time I add or change a device the router hangs and reboots.
RT-AC68U, didn't have any problems with the earlier (380 something) release.

 

[Enzo]

@RMerlin

Can't locate your preferred bug submission location, so going best effort here...

Tools:SysInfo:Network
Listing of switch ports is correct, i.e. MAC to PORT

General:Network Map:Status:Ehternet Ports, appear "flipped". I think this was an older, and previously resolved, bug?

Thx,
Enzo