Merlin 376_48.1 Traditional QOS Bug

[Ronv42]

Last night I was replacing the adaptive QOS with traditional rules and as I was scanning the iptables and tc results to see how the firmware was creating the entries the both the mangle table and the tc buckets just disappeared a few minutes after I made my changes via the WebUI. I rebooted my router and they were back.

Then when I was testing throughput to verify the rules I noticed nothing was clamping the outbound bandwidth. Listed out the iptabes rules and the tc rules and again nothing listed. On a hunch I went back to the UI and clicked on save again for the QOS rules and the settings were back. The UI isn't forgetting the values since they are stored in NVRAM but some code in the website is invoking some type of reset to clear out the rules in memory.

What I narrowed it down to was that the firmware was clearing both the IP Tables and the TC QOS rules if you clicked on any of the tabs (QOS, Web History, or Traffic Monitor ) in the Adaptive QOS section of the UI. I can reproduce this 100% of the time.

I am running this with Merlin's firmware 376_48.1 on my Asus AC87R with IE11 as my browser. Any suggestions?

 

[RMerlin]

See if they come back if you restart the firewall:

service restart_firewall

Personally I never touched the QoS code because I'm not familiar enough with Linux's tc, so I'd rather avoid breaking things there.

 

[Ronv42]

See if they come back if you restart the firewall:

service restart_firewall

Personally I never touched the QoS code because I'm not familiar enough with Linux's tc, so I'd rather avoid breaking things there.

When I got home tonight the rules were gone again in both tc and iptables. I ran the service restart_firewall and it rebuilt the mangle tables to tag the traffic but none of the tc buckets were created. I had to go back to the QOS tab and hit apply again and the iptables and tc buckets were built. These are the two commands needed:

service restart_qos
service restart_firewall

You can see them being called in the QoS_EZQoS.asp web page.

 

[Ronv42]

I found another clue of what may be going on. I found the following messages in dmesg after clicking on the "QOS" tab after verifying that my QOS rules were present:

IDPfw: TrendMicro forward module ver-1.0.17
IDPfw: Apply module param dev_wan=eth0
IDPfw: Apply module param sess_num=30000
[alloc_udb:299] Successfully malloc udb 3116 bytes at cf80d000
[alloc_app:364] Successfully malloc udb 131088 bytes at d2c64000
[alloc_patroldb:803] Successfully malloc devdb 268602 bytes at d2c87000
IDPfw: Init chrdev /dev/idpfw with major 191
IDPfw: IDPfw is ready
sizeof forward param = 160

If I am not mistaken this is the TrendMicro firewall module. I bet this is the item that is pulling the rules out. I haven't read though the code yet to see what gets executed when clicking on the "QOS","Web History", or "Traffic Monior" tabs but this seems be executed when you do.

Can anyone help deconstruct the webpage that loads and launches the installation of this module?

 

[RMerlin]

I know that bwdpi will flush some mangle iptable rules when it gets started (which is what forced me to ditch my NAT loopback engine and revert back to Asus's). Since bwdpi is closed source, nothing that can be done there.

 

[Ronv42]

I know that bwdpi will flush some mangle iptable rules when it gets started (which is what forced me to ditch my NAT loopback engine and revert back to Asus's). Since bwdpi is closed source, nothing that can be done there.

The issue itself is the click on the QOS tab and what code on web page is triggering the module to load. I am assuming that AUSU isn't verifying the type of QOS enabled before it calls the service to load the proprietary module.

If web page code would honor the radio button setting of "Traditional QOS" vs. "Adaptive" it would skip the loading of the "IDP" module. My knowledge of the glue that holds the Asus web pages together is very limited and I am able to pick out some of the javascript components that make calls to some OS functions like service start/restart methods.

Merlin can you provide some insight on deconstructing the web page code for the QOS tab? Or can ASUS be contacted about this bug? Thanks...

 

[RMerlin]

The issue itself is the click on the QOS tab and what code on web page is triggering the module to load. I am assuming that AUSU isn't verifying the type of QOS enabled before it calls the service to load the proprietary module.

If web page code would honor the radio button setting of "Traditional QOS" vs. "Adaptive" it would skip the loading of the "IDP" module. My knowledge of the glue that holds the Asus web pages together is very limited and I am able to pick out some of the javascript components that make calls to some OS functions like service start/restart methods.

Merlin can you provide some insight on deconstructing the web page code for the QOS tab? Or can ASUS be contacted about this bug? Thanks...

The DPI engine isn't used only for Adaptive QoS, it's used for various other features: web history, Apps traffic, AiProtection, etc...

 

[Ronv42]

The DPI engine isn't used only for Adaptive QoS, it's used for various other features: web history, Apps traffic, AiProtection, etc...

Thanks for clearing that up....hmmm...how did Asus ship this version with this type of major bug.

 

[RMerlin]

Thanks for clearing that up....hmmm...how did Asus ship this version with this type of major bug.

Quite frankly, the firmware is simply starting to become unmanageable. Too many features, and the Tomato codebase it was initially based on wasn't the cleanest architecture either for adding so many features that interact with one another.