It needs the bwdpi engine.
At least for me, the bwdpi engine (with both ASUSWRT or Merlin - both 388.x) upon a reboot will work for a few minutes or randomly if there is anything set in either
http://www.asusrouter.com/Advanced_QOSUserPrio_Content.asp or
http://www.asusrouter.com/Advanced_QOSUserRules_Content.asp (exposed via ScMerlin), I have all the QoS settings set to off, Web and Appfilter and Timeschedueling as well. But because I use DDNS, privacy is eanbled.
I had an issue with 388.x where my bandwidth would be cut by 50% ramdomly, by chance I stumbled upon
http://www.asusrouter.com/Advanced_QOSUserPrio_Content.asp add cleared everything out as soon as I did and applied, problem solved immediately without a reboot, bandwidth back to 100%. Recently upon a reboot (post flash to the beta), I discovered that the Bandwidth Monitor and Data Classification was active if only for a few minutes while the bwdpi engine was running, even with all the QoS settings set to off. Once it bwdpi shutt down, going into Data classification I get greeted with "
Note: Statistics require Traditional QoS mode or the TrendMicro bwdpi engine to be enabled." which is correct.
Though I will add, upon reboot if you go to Bandwidth Monitor and its working, then to Data Classification it will work for a few seconds, three seconds default refresh. But while the engine is alive you can hop back Bnadwidth Monitor and if it is still updating, then to Data Classification to see statistics for another three seconds. Untill the engine finally falls asleeep, because QoS is off, then both stop working.
Digging around I found
Master@Router:/tmp/bwdpi# cat dcd.stat
***** data_colld statistics ************************************
start_time : 1701140094 (2023-11-27 21:54:54)
which correlates to the last reboot, note: post 388.5 beta. Upon reboot, after the firmware update form the second alpha I had all sorts of errors (have log) and firewall restarts, even got kicked out of the GUI at one point, but a few minute power off and reboot, solved them and its been 100% stable every since. I suspect it was something with the USB dirver/USB stick as I SSH'd in and found certain directories were no longer visible, but the power off reboot solved it.
I wouldn't call this bwdpi temporary activation a bug and if I did its closed source anyway (out of
@RMerlin control) but its an interesting behavior that I've managed to stumble across and get around, under 388.x (both ASUSWRT native and Merlin/w scripts albeit with better visibility).
As of this morning it's running, still going strong