Asuswrt-Merlin 378.56 is available

[roofy]

AC-68U...... Upgraded from 378.55 to .56. No changes is configuration between .55 and .56. Running a pretty vanilla setup. No MediaServer, no Ai*, no FTP, etc. No custom scripts other than storing traffic history to a USB drive. Have not had any issue with any previous firmware release. After 48 hours of uptime, the logs are flooded with: failed to write /var/lib/misc/dnsmasq.leases: No space left on device (retry in 60s). Any ideas or suggestions much appreciated.

RAM consumption is also much higher than on .55..... Currently @ 66% whereas on .55 would never go above 30%

 

[Trebuin]

Hello Merlin,
I have an RT-AC66R currently set up in repeater mode using the 40 MHz band on the 5G side. I would like to set it up in repeater mode using the 80 MHz band, tying the AC side of it to my primary router's AC side. I originally set the wifi up as 80 MHz prior to the repeater mode setup but it goes back down to 40 MHz with no option for 80 in the GUI. Is it possible to do what I'm asking?

 

[pege63]

80MHz goes on chanells 42, 58, 106, 122, 138, 155 on 5GHz band.
With 802.11ac it may be tempting to use 80 MHz channel widths for peak performance. However, in order to reduce co-channel interference it is recommended that you derive your channel plan using non-overlapping 20 MHz or 40 MHz channels instead, allowing 80 MHz channel width on a best-effort basis. This allows APs to back-down to smaller channel widths that are non-overlapping when 80 MHz CCI is present using per-frame channel width capabilities available with 802.11ac. This allows APs to use the higher peak performance when possible, while maintaining separate collision domains at smaller channel widths when 80 MHz transmissions are not possible.

 

[EdoAsus]

RAM consumption is also much higher than on .55..... Currently @ 66% whereas on .55 would never go above 30%

Are you sure?? I get almost 90% busy RAM with .55, I asked in a previous post if .56 is better in RAM consumption, with no answer yet. I don't understand why the RAM is managed in this bad way and nobody complains about.

 

[soleillune]

AC-68U...... Upgraded from 378.55 to .56. No changes is configuration between .55 and .56. Running a pretty vanilla setup. No MediaServer, no Ai*, no FTP, etc. No custom scripts other than storing traffic history to a USB drive. Have not had any issue with any previous firmware release. After 48 hours of uptime, the logs are flooded with: failed to write /var/lib/misc/dnsmasq.leases: No space left on device (retry in 60s). Any ideas or suggestions much appreciated.

RAM consumption is also much higher than on .55..... Currently @ 66% whereas on .55 would never go above 30%

I have the same problem (9135 firmware), and I lost access to the UI but router still working. (RT-AC68U). I had to reboot the router to get access to the UI again.

 

[RMerlin]

Are you sure?? I get almost 90% busy RAM with .55, I asked in a previous post if .56 is better in RAM consumption, with no answer yet. I don't understand why the RAM is managed in this bad way and nobody complains about.

Because as was previously answered in multiple posts, the RAM gets used by buffers, which are dynamically freed by the kernel when they become required by other processes. There was no change to memory management in 378.56.

 

[RMerlin]

For me that was the last straw. Getting tired of constantly answering the same question, so I'm removing the memory buffer fix for the next release.

 

[charlie2alpha]

For me that was the last straw. Getting tired of constantly answering the same question, so I'm removing the memory buffer fix for the next release.

Ouch, that will hurt performance. The actual fix would be to fix the memory gauge to report the usage minus the buffer/caches. Also, some users seem to have actual memory issues with RAM getting full, hence those errors from dnsmasq. But that is another problem, since at least one user reported getting this with the official firmware. Seems something is leaking.

 

[L&LD]

For me that was the last straw. Getting tired of constantly answering the same question, so I'm removing the memory buffer fix for the next release.

Please consider leaving it in and just ignoring people who can't use search properly.

 

[charlie2alpha]

Please consider leaving it in and just ignoring people who can't use search properly.

Too late, it's already committed in his git. What troubles me is, in my RT-AC56U /proc/sys/vm/drop_caches is already set at "1". Weird.

 

[john9527]

Too late, it's already committed in his git. What troubles me is, in my RT-AC56U /proc/sys/vm/drop_caches is already set at "1". Weird.

It retains the last value that was set. Caches are cleared after the boot cycle, so it gets set there.

 

[EdoAsus]

Because as was previously answered in multiple posts, the RAM gets used by buffers, which are dynamically freed by the kernel when they become required by other processes. There was no change to memory management in 378.56.

Well I just asked if there was some changes regarding memory management in .56, I have most of the time 90% busy RAM on .55 and sometimes I have web-streaming media getting stuttering so I thought if the issue can be related to the memory of the router.

 

[roofy]

For me that was the last straw. Getting tired of constantly answering the same question, so I'm removing the memory buffer fix for the next release.

Merlin,

Don't get me wrong..... I was simply trying to provide as much info as possible with regard to the "...no space left one device" log entries. I was in no way implying anything with regard to the RAM consumption. I have read previous change logs and did see the RAM changes that had been made.

 

[john9527]

Don't get me wrong..... I was simply trying to provide as much info as possible with regard to the "...no space left one device" log entries

Let's check and see if it's something obvious like the syslog not getting rotated....telnet/ssh and enter

ls -l /tmp | sort -k 5

what's the size of the last entry?

 

[Blinkyz]

For me that was the last straw. Getting tired of constantly answering the same question, so I'm removing the memory buffer fix for the next release.

OMG!!!!! no

 

[FlyByWire]

The issue is still there. I did a few blind attempts at fixing it, without any luck. Since I don't have any network printer, I didn't want to spend too much time blindly trying things out. I have a feeling it's tied to the networkmap scans.

Thanks Merlin, I could provide a wireshark log of what's happening when the issue appears if you are interested?!

 

[RMerlin]

Thanks Merlin, I could provide a wireshark log of what's happening when the issue appears if you are interested?!

Thanks, but that wouldn't really help. I do know that networkmap does various connection attempts to determine if a certain device is a printer, however I don't know if just one specific test there is responsible for the wake up. I tried simplifying the test by only connecting to the usual LPR port instead of also submitting a test job, but reports indicated that it wasn't enough.

 

[RMerlin]

Please consider leaving it in and just ignoring people who can't use search properly.

I've had that very question asked at least four times in the past week only. It's not just the forums, but it's also over Twitter and emails.

Those who asked (again) in this thread, don't take it personal. I'm not blaming any of you specifically, it's just that together, all of those constantly asking about it are getting annoying for me, so I'm removing the problem.

And quite frankly, I never could observe any measurable performance gain from allowing buffering to work as intended. Main reason why I had removed it was because the Kernel documentation itself recommended against using that control method to flush buffers, so from my point of view, I was removing something that was a bad hack from the start.

And hiding buffers from the reported free memory would be cheating, and might lead to more confusion from people expecting it to ONLY report really available memory.

 

[JohnNerd]

"RMerlin said: ↑
For me that was the last straw. Getting tired of constantly answering the same question, so I'm removing the memory buffer fix for the next release."

I agree with Merlin. There are too many stupid claims in these threads. Too few nerds.

 

[charlie2alpha]

Point taken. In the end it's hardly surprising, I've seen the same and worse on Android phone related forums, people with zero knowledge of the Linux kernel memory management kept asking why memory is full. There's no end to it ...

Sent from my Nexus 9 using Tapatalk