What's new

[Release 384/NG] Asuswrt-Merlin 384.5 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!

OK - in the interest of proper testing, I reset one of my 68U routers, reloaded 384.5, factory reset, reformatted the 2.0 USB drive on a linux box, then went thru the router setup (including Samba and ftp), removed and replaced the USB drives (both 3.0 and a 2.0 - and yes, plugged into the proper ports...). 3.0 is seen and works, 2.0 not seen by the OS (blue light is on). Then did the toggle trick, rebooted... Still no good. Reformatted 2.0 as a fat, rebooted... still no good... Logs show nothing for the 2.0 on insert, removal...
 
I have another discovery related to FTP. As reported there seems to be an issue with setting permissions for FTP users. It seems that the permissions actually work as in prior releases but are not reported on the FTP Shares page properly. Example, if you setup 2 users with different permissions for a folder, save permissions and apply, the screen shows the users revert to "No" access. But the access thru an ftp client works properly...
 
I would go back one dot release at this point, no idea what's causing that.
You know 380.70 works and you know 384.5 does not
Well this release is stable and resolved some other things for me. Since USB 3.0 works, I plan on using that for now... I have lots of 3.0 USB sticks...

Thanks again rmerlin for another great release...
 
So not sure if anyone else is having the same issue but it looks like once you change the routers IP address the network map feature stops showing how many clients are connected. I thought it was a bug so i factory reset my router and everything was working. Upon reconfiguration and changing the IP address to 10.0.0.1 the clients stopped showing.

RT-AC5300
Firmware: 384.5

EDIT: Changing the IP address back to 192.168.1.1 makes the clients show again.
 
So not sure if anyone else is having the same issue but it looks like once you change the routers IP address the network map feature stops showing how many clients are connected. I thought it was a bug so i factory reset my router and everything was working. Upon reconfiguration and changing the IP address to 10.0.0.1 the clients stopped showing.

RT-AC5300
Firmware: 384.5

EDIT: Changing the IP address back to 192.168.1.1 makes the clients show again.

Not seeing that problem on my RT-AC5300

ZoBgiSm.png
 
Last edited:
Well this release is stable and resolved some other things for me. Since USB 3.0 works, I plan on using that for now... I have lots of 3.0 USB sticks...
You do know USB 3.0 is backwards compatible, right? You can use any USB 2.0 stick in the USB 3.0 port.
 
Yep, the pattern continues. After each 4 Gig of download, get a upload spike equaling 4 Gig in a couple mins on my RT-AC68U.
@MarkRH @RMerlin

This change in rstats.c seems to be the cause for the 4GB spikes
https://github.com/RMerl/asuswrt-me...3182da5#diff-ad1905e5fc69da7fa5328b342764d36e

specifically these lines https://github.com/RMerl/asuswrt-me.../release/src/router/rstats/rstats.c#L937-L948

Asus seems to be doing extra calculations for certain models (RTCONFIG_BCMARM); the statements in the else blocks are especially weird as vlan_{tx,rx} aren't actually used anywhere else.

Code:
counter[0] = counter[0] + 0xffffffff - vlan_rx;

The 0xffffffff is where the 4GB figure comes from.

It is also weird that @MarkRH mentions the official firmware 384_20624 does not exhibit this issue, while this is in the GPL archive for that release which Merlin merged.

My current theories are:
  1. Asus firmwares do not line up with their GPL archives perfectly ie. what they used to compile the firmware is slightly out of sync with their GPL releases.
  2. These weird calculations are for upcoming changes to how traffic is calculated ie. Broadcom drivers would post aggregated numbers to /proc/net/dev, and rstats has to separate WAN from LAN.
  3. These code changes to rstats.c seem pretty isolated and should be safe to revert?
  4. I think this code block is supposed to address traffic monitoring issues some other user is experiencing after upgrading to 384.4_2 https://www.snbforums.com/threads/s...fter-upgrading-to-384-4_2-on-rt-ac5300.46512/
This seems like a band-aid fix for another programming error or design flaw (by Broadcom), not to mention introducing an integer underflow.
 
Last edited:
@MarkRH @RMerlin

This change in rstats.c seems to be the cause for the 4GB spikes
https://github.com/RMerl/asuswrt-me...3182da5#diff-ad1905e5fc69da7fa5328b342764d36e

specifically these lines https://github.com/RMerl/asuswrt-me.../release/src/router/rstats/rstats.c#L937-L948

Asus seems to be doing extra calculations for certain models (RTCONFIG_BCMARM); the statements in the else blocks are especially weird as vlan_{tx,rx} aren't actually used anywhere else.

Code:
counter[0] = counter[0] + 0xffffffff - vlan_rx;

The 0xffffffff is where the 4GB figure comes from.

It is also weird that @MarkRH mentions the official firmware 384_20624 does not exhibit this issue, while this is in the GPL archive for that release which Merlin merged.

My current theories are:
  1. Asus firmwares do not line up with their GPL archives perfectly ie. what they used to compile the firmware is slightly out of sync with their GPL releases.
  2. These weird calculations are for upcoming changes to how traffic is calculated ie. Broadcom drivers would post aggregated numbers to /proc/net/dev, and rstats has to separate WAN from LAN.
  3. These code changes to rstats.c seem pretty isolated and should be safe to revert?
This seems like a band-aid fix for another programming error or design flaw (by Broadcom), not to mention introducing an integer underflow.
How about a bandage fix for an ancient obsolete kernel.
 
I know you are taking some (well deserved) time off, some possible suggestions for 384.6

Update IPSet from v6.32 > v6.38 (current version is over a year old with 6 releases since then)
Implementing the SMB tweaks detailed here. Honestly this is something I'm surprised Asus haven't done themselves seeing how competitive the market is, increasing performance on a major component by x2 - x3 seems like a no brainier.
 
You do know USB 3.0 is backwards compatible, right? You can use any USB 2.0 stick in the USB 3.0 port.
I think it is the USB 2.0 protocol.... USB 2.0 stick won't work in either port; the USB 3.0 stick will work in only the USB 3.0 port on this release...
 
So not sure if anyone else is having the same issue but it looks like once you change the routers IP address the network map feature stops showing how many clients are connected. I thought it was a bug so i factory reset my router and everything was working. Upon reconfiguration and changing the IP address to 10.0.0.1 the clients stopped showing.

RT-AC5300
Firmware: 384.5

EDIT: Changing the IP address back to 192.168.1.1 makes the clients show again.
Maybe the clients need to re IP before they will show and can't because they are looking for a different IP
 
This may help others. I was having a surprising amount of instability with my iOS devices and was surprised to find this (if it was in the readme, I must have overlooked it?) in Tools -. Other Settings:
dhcpd: send empty WPAD with a carriage return

It was set to Yes. Changing it to No made everything better (since this is supposedly to help w/ Windows, I'll add that our two Windows systems had more trouble w/ that on than with it off).
 
This may help others. I was having a surprising amount of instability with my iOS devices and was surprised to find this (if it was in the readme, I must have overlooked it?) in Tools -. Other Settings:
dhcpd: send empty WPAD with a carriage return

It was set to Yes. Changing it to No made everything better (since this is supposedly to help w/ Windows, I'll add that our two Windows systems had more trouble w/ that on than with it off).
Uptime nearly 4 days here and no issues with my idevices. The feature you mentioned is set to Yes here.

We have two iPhones and two iPads. I will say this, our idevices don’t much like the higher 5ghz channels. Channel 44 and rock solid connections. I have universal beamforming off on 5ghz (ac beamforming is on).
 
So not sure if anyone else is having the same issue but it looks like once you change the routers IP address the network map feature stops showing how many clients are connected. I thought it was a bug so i factory reset my router and everything was working. Upon reconfiguration and changing the IP address to 10.0.0.1 the clients stopped showing.

RT-AC5300
Firmware: 384.5

EDIT: Changing the IP address back to 192.168.1.1 makes the clients show again.

Networkmap only supports /24 networks.

It is also weird that @MarkRH mentions the official firmware 384_20624 does not exhibit this issue, while this is in the GPL archive for that release which Merlin merged.

Could be related either to their use of BCM530x0 registers to retrieve some of the data (which I don't), or could be because I have increased some variables to a 64-bit long in some of the rstats code while they kept it as 32-bit (I don't remember if they ever increased it to 64-bit as well on their own end).

The first thing I would try would be to change that hardcoded 32-bit value to a 64-bit one (along with all related variables).

Update IPSet from v6.32 > v6.38 (current version is over a year old with 6 releases since then)
Implementing the SMB tweaks detailed here. Honestly this is something I'm surprised Asus haven't done themselves seeing how competitive the market is, increasing performance on a major component by x2 - x3 seems like a no brainier.

@john9527 did most of the ipset upgrade work a few months ago, and at the time he chose to stick to 6.32 for now to avoid introducing new issues (there were already too many things to deal with at the same time).

I would be open in upgrading, provided it's technically doable. Keep in mind that I have two different kernels in need of updating (2.6.36 and 4.1), so it's twice the amount of work.

This may help others. I was having a surprising amount of instability with my iOS devices and was surprised to find this (if it was in the readme, I must have overlooked it?) in Tools -. Other Settings:
dhcpd: send empty WPAD with a carriage return

It was set to Yes. Changing it to No made everything better (since this is supposedly to help w/ Windows, I'll add that our two Windows systems had more trouble w/ that on than with it off).

This has actually been the same for close to four years now. The only change in 384.5 is that now there is an option to disable that behaviour.
 
Last edited:
My AC86u syslog continue get the following message, can you tell me whats the error for.

May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x02; Reg_in: 0x08020000; Reg_out: 0x1802ffff
May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x03; Reg_in: 0x08030000; Reg_out: 0x1803ffff
May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x04; Reg_in: 0x08040000; Reg_out: 0x1804ffff
May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x05; Reg_in: 0x08050000; Reg_out: 0x1805ffff
May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x06; Reg_in: 0x08060000; Reg_out: 0x1806ffff
May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x07; Reg_in: 0x08070000; Reg_out: 0x1807ffff
May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x00; Reg_in: 0x08000000; Reg_out: 0x1800ffff
May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x01; Reg_in: 0x08010000; Reg_out: 0x1801ffff
May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x02; Reg_in: 0x08020000; Reg_out: 0x1802ffff
May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x03; Reg_in: 0x08030000; Reg_out: 0x1803ffff
May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x04; Reg_in: 0x08040000; Reg_out: 0x1804ffff
May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x05; Reg_in: 0x08050000; Reg_out: 0x1805ffff
May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x06; Reg_in: 0x08060000; Reg_out: 0x1806ffff
May 17 22:48:59 kernel: ****** Error: MDIO Access Returned FAIL! CL22 Access: Op: Read; PortAddr: 0x00; DevAddr: 0x07; Reg_in: 0x08070000; Reg_out: 0x1807ffff
 
This has actually been the same for close to four years now. The only change in 384.5 is that now there is an option to disable that behaviour.

Interesting. I had never seen them have so much trouble getting new dhcp assignments before, and it did improve after changing that. Another mystery...
 
Uptime nearly 4 days here and no issues with my idevices. The feature you mentioned is set to Yes here.

We have two iPhones and two iPads. I will say this, our idevices don’t much like the higher 5ghz channels. Channel 44 and rock solid connections. I have universal beamforming off on 5ghz (ac beamforming is on).

I have no idea what the problem was, but it was around getting DHCP assignments. They would get bumped and could not rejoin. Based on what RMerlin said, that setting is nothing new, so the fact that things cleared up after that is a mystery. There is nothing else I could identify from my settings that was different from a solid working setup in the beta.
 

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