What's new

[Release 384/NG] Asuswrt-Merlin 384.4 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.
Third time factory reset now, took a 30-30-30 reset and clear nvram, unplug it for 5 minutes and set everything up from scratch. Installed latest 384.4_2 and Netflix bitrate is now down to 1 mbps again. (2.44-4.10mbps on 384.3)

@RMerlin: I understand you are very busy, but can you atleast answer what changed from 380 to 384 FW on the WiFi ? Something have to be different.
Love to know this too, my WiFi has become a mess since this update.

Going to flash back afew firmwares, if that's at all possible.

Sent from my SM-G965F using Tapatalk
 
On a side note what does the bandwidth monitor actually do as far as the priorities settings and the ability to drag clients up and down the page?

No idea. I suspect it won't have any impact, since Bandwidth Limiter doesn't use the Trend Micro engine - only Adaptive QoS does.

@RMerlin: I understand you are very busy, but can you atleast answer what changed from 380 to 384 FW on the WiFi ? Something have to be different.

I don't know, that code is closed source.

IMHO 384.4_0 is a better choice than either 384.3 or 384.4_2 for whatever reason on a RT-AC68u. I have run all 3 but only came across oddities on .3 and .4_2 in my application. Cant speak for other platforms.

Zero code change related to wifi between 384.4_0 and 384.4_2. The only code changes are in the web server, and in the HTML pages. Nothing else.

Code:
merlin@ubuntu-dev:~/amng$ git log 384.4..384.4_2 --oneline
f6377ac Updated documentation; bumped revision to 384.4_2
ca7ae05 webui: display security warning when enabling WAN access to the router's webui
adc2a93 httpd: implement wrapper around check_blacklist_xss() to protect against buffer overruns
f0a3f59 Bumped revision to 384.4_1
5907cd5 httpd: fix potential crash on NULL pointer and potential buffer overrun in do_qis_default()
8055057 webui: fixed QoS overhead preset list
71fef99 Bumped revision to 384.5 alpha 1

Just curious. Is there anything security related in Asus release 20624 change log not in your build?

Not sure, changelog is too vague, and the CVE details are not public. The AiCloud issues are probably present in 384.4_2.
 
384.4_2 is working very well on my AC 3200 4 days up with no problems , seems it needed those 2 manual reboots as have had no problem since . Have no idea why only the Realtek clients had trouble with 384.4 beta and alpha but intel , broadcom and atheros clients were fine . Now all clients are happy , very strange .
Thanks Merlin
 
IMHO 384.4_0 is a better choice than either 384.3 or 384.4_2 for whatever reason on a RT-AC68u. I have run all 3 but only came across oddities on .3 and .4_2 in my application. Cant speak for other platforms.
For me, this update was uneventful. There must be certain combinations of features that are causing issues, otherwise, everyone would be rejecting 384.4_2 and reverting back to the previous release.
I probably avoid lots of problems due to only using my RT-AC68U as a basic router with tweaks to the defaults for both radios.
This is becoming an Urban legend :eek: .... 30-30-30 dont work with Asuswrt or Rmerlin fw.

With Asuswrt , 30-30-30 = Turn off the router, press the WPS button , then turn on the router. Wait about 15 seconds(Power led will flash rapidly), then release the WPS button.Wait 3 min and reconfig, dont import saved settings.
Interesting how something that worked with some routers became the standard method for all. I don't think I ever owned a router that used 30-30-30. Did it work on the old Linksys WRT-54G routers?
Back on topic, considering how trivial the changes are between 384.4_0 and 384.4_2, there seems to be no good explanation for the number of complaints. I noticed absolutely no difference after the update and did not have to do anything extraordinary to make it work.
 
This is becoming an Urban legend :eek: .... 30-30-30 dont work with Asuswrt or Rmerlin fw.

With Asuswrt , 30-30-30 = Turn off the router, press the WPS button , then turn on the router. Wait about 15 seconds(Power led will flash rapidly), then release the WPS button.Wait 3 min and reconfig, dont import saved settings.

There's also a way to access to recovery bootloader (via browser during bootup) where you are able clear nvram or upload any firmware.

Code:
Hold reset button 10 seconds

Power off router (keep holding reset)

Wait 10 seconds, keep holding reset

Power on router holding reset for 10 more seconds

Access router via ip address and you will reach miniCFE server

So we got the 10-10-10 method, but I keep holding reset while spamming refresh until the recovery webpage loads.
 
(AC68U on 384.4)

This had been reported on 384.3 but seems unaddressed in 384.4 --

[1] Parental control -> time schedule is broken. Any device set to have time schedule would frequently (and randomly) show the "internet blocked" page during the allowed time period.
[2] Firewall -> Network service filter is not reliable. Sometimes (not always) blocked ports are still accessible during blocked periods. May be related to [1]; it seems the time checking is faulty.

More info on the firewall issue:

My network service filter looks like the pic attached. I suppose the setting should block any access from my local network to any IP address on port 6xxx between 9am-5pm, correct? And it seemed to work this way before, with up to 380.69_2.

Now with 384.4 this does not seem to work, as I can see connections during the day:

tcp 192.168.1.7:35984 192.114.74.5:6099 ESTABLISHED
tcp 192.168.1.7:48389 198.137.227.135:6001 ESTABLISHED

and so on. (IPs are randomized.)

[1] Does this mean my firewall rules are not in effect? How do I check for sure?
[2] If a user establish a connection to port 6000 of an IP address before 9am, can this connection be maintained past 9am, even when the rules are working?

Thanks,

Sean
 

Attachments

  • flt.JPG
    flt.JPG
    56.5 KB · Views: 416
This is becoming an Urban legend :eek: .... 30-30-30 dont work with Asuswrt or Rmerlin fw.

With Asuswrt , 30-30-30 = Turn off the router, press the WPS button , then turn on the router. Wait about 15 seconds(Power led will flash rapidly), then release the WPS button.Wait 3 min and reconfig, dont import saved settings.

Too funny... 'urban legend'.

30-30-30 was something used on old Linksys WRT54G/GS/GL type routers when DD-WRT firmware was being installed or reset. It did not even work on stock Linksys f/w never mind Asus. Here is an example of where even the DD-WRT folks tried to dissuade people from doing 30-30-30 on other things. https://www.dd-wrt.com/wiki/index.php/Hard_reset_or_30/30/30
 
[1] Does this mean my firewall rules are not in effect? How do I check for sure?
[2] If a user establish a connection to port 6000 of an IP address before 9am, can this connection be maintained past 9am, even when the rules are working?

1) run this command in putty

Code:
iptables -t filter -L NSFW

2) rules only apply for new connections going forward (existing connections will NOT be dropped)
 
Last edited:
Hi, i can't flash 384.4_2 firmware into my AC-87U.
Already tried download it several times from main download page / mirror
Need help please.. :)
cant_flash_to_ac87u.png
[/url][/IMG]
cant_flash_to_ac87u.png
 
[1] Does this mean my firewall rules are not in effect? How do I check for sure?
[2] If a user establish a connection to port 6000 of an IP address before 9am, can this connection be maintained past 9am, even when the rules are working?

Thanks,

Sean

The firewall rules are in effect, but, it appears that the Parental controls aren't working as we expect them to. On an 86U running stock firmware version 3.0.0.4.384.20467, the exact situation occurs as you have described. When a connection is established prior to the enforcement time, it remains up and running long after the enforcement time. How long, don't know. It appears that the only thing that solves this is to run a reboot to break the connection.

So, the question is, for anyone who used the Parental control on the 380.xxx versions, did the same thing happen, or was the connection broken at the allocated time?
 
The firewall rules are in effect, but, it appears that the Parental controls aren't working as we expect them to. On an 86U running stock firmware version 3.0.0.4.384.20467, the exact situation occurs as you have described. When a connection is established prior to the enforcement time, it remains up and running long after the enforcement time. How long, don't know. It appears that the only thing that solves this is to run a reboot to break the connection.

So, the question is, for anyone who used the Parental control on the 380.xxx versions, did the same thing happen, or was the connection broken at the allocated time?

The original connection will remain running until it is dropped and reestablished.
So for the duration the connection is RELATED or ESTABLISHED, you are out of luck.

I think the rule would take effect immedietly in the FORWARD table. I will double check.

edit:
The NSFW chain has to be moved above ACCEPT in the FORWARD table so rules take effect immediately.
 
Last edited:
So, the question is, for anyone who used the Parental control on the 380.xxx versions, did the same thing happen, or was the connection broken at the allocated time?

Parental control (and firewall) worked on 380 -- I have been using it for a long time. I had to turn off parental control on 384 because (as reported by others as well) when enabled, it blocks internet access randomly even during "allow" periods.

Sean
 
With 380, I did not even seem to have the problem of "established" connection going into the prohibited time period (at least not long enough for me to notice). How long can an "established" connection last?

I still suspect that the time checking part in the firewall rules implementation has a bug -- that would explain the problems with both parental control and network service filter.

BTW I did the iptables listing -- the rules are all enabled. So if the rules were not enforced correctly, they must be reading wrong time values.
 
So we got the 10-10-10 method, but I keep holding reset while spamming refresh until the recovery webpage loads.

As an alternative, try sending a series of ping to the router. Once you get replies with a TTL of 100, it means the bootloader is up. If TTL is 64, then you're in "normal" mode.
 
Hi, i can't flash 384.4_2 firmware into my AC-87U.
Already tried download it several times from main download page / mirror
Need help please.. :)

Reboot your router, with no USB disk attached, to ensure you have enough free RAM.

The hash I provide with the firmware are SHA256 BTW, not MD5.
 
Here's a visual for users affected by the network services filter timed scheduler.

postimage_iptables.png


The rules are read from TOP to BOTTOM.
The NSFW chain is the network services filter.

Once a packets target is ACCEPTED or DROPPED, it stops transversing down the chain.

As you can see any currently any connections RELATED/ESTABLISHED, will not be parsed by the network services filter.

I can simultaneously see the action of "ACCEPTING" established connections bringing a performance bump, but at the same time having the filter work incorrectly for a brief time after it switches ON/OFF. (Overall these extra checks in NFSW chain are insignificant, so it should probably be parsed before the current ACCEPT state rule).

If you are running an old firmware post the output os

Code:
iptables -t filter -L FORWARD

As I am unsure on the behavior/setup that was implemented in the past.
 
Last edited:
I updated my ac5300 from the 380 branch to 384.4_2 on the weekend (factory reset - initialize after flashing) and everything looked to be running really well for next 48hrs or so until yesterday the wifi stopped responding for all clients. I rebooted (more than once) the ac5300 and all wireless interfaces are down (led’s for 2.4 & 5 ghz off).

Have not had an issue like this in any previous merlin version. When i get home from work will connect via ethernet to see if i can get the log to post any errors here and/or downgrade to 384.4 which might be more stable.
 
  • Like
Reactions: GDT
I asked this in the previous firmware release, but don't think I got a response.

In the network map wifi devices, (mostly, if not all 5ghz connected) keep disappearing and then showing again.

They are not losing connectivity.

The network map seems very unstable, if your trying to look at something the device suddenly drops from the map and then appears again a few seconds/minutes later.

I can't remember it ever being like this.
 
Too busy to take a look at it at this time, sorry. My current ToDO list seems to be growing on a daily basis as of late, with miniupnpd and openssl having recently been added to the list of things to merge, on top of two new GPL releases in the last week :(

No problem :D. I just curious if it works as I expected.
If Asus finish to development ipsec client feature in future, RT-AC86U be a very simple and great solution to make site-to-site vpn between two nodes.
 
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