What's new

FlexQoS FlexQoS issues with 388.4 HND5.04 models

  • 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!

I was sure that 388.4 beta 2 was reboot free, but I wanted to be certain. Hence I downgraded the firmware from 388.4 >> 388.4 beta 2. The routers runs without any reboot for 11.42 hours. Usually, reboots come at around 30 minutes, but I will be monitoring further. FlexQoS is 1.3.3.
 
I was sure that 388.4 beta 2 was reboot free, but I wanted to be certain. Hence I downgraded the firmware from 388.4 >> 388.4 beta 2. The routers runs without any reboot for 11.42 hours. Usually, reboots come at around 30 minutes, but I will be monitoring further. FlexQoS is 1.3.3.
For me something changed with 388.3.
With flexqos 1.3.2 and 388.3 I was getting reboots. I tried the 388.4 betas but continued to have reboot issues. 388.2.2 with flexqos 1.3.2 was rock solid for me with the few custom rules I was using. I spoke to Merlin and we troubleshot a wan issue but we never uncovered the reboot issue with regards to 388.3. I was still using 1.3.2 at that time so there were no changes to flexqos. Something had to change within 388.3 from 388.2.2

For me on my version 1 88PRO:
388.2.2 and 1.3.2 solid
388.3 and 1.3.2 reboots
388.3 and 1.3.3 reboots
388.4 beta 1 and 1.3.2 reboots
388.4 beta 2 and 1.3.2 reboots
388.4 public and 1.3.2 reboots
388.4 public and 1.3.3 reboots.
3.0.0.6 asus code runs fine
3.0.0.4 asus code runs fine
 
I agree, 388.2_2 was good for me with FlexQoS. For my model, RT-AX86U Pro, there was no 388.3. Presumably, changes from 388.3 would have been incorporated in early betas of 388.4. if that assumption is correct, then it's strange why for my case installing 388.4 beta 1 , then beta2 didn't bring any major reboot issue. I have already one Asus RT-AX86U Pro downgraded in 388.4 beta 2 with latest FLexQoS and monitoring the situation.
 
please share screenshots of what your rules look like in the webui. I am trying to see if I experience the same issue using the same (or similar) rules. Maybe there is some syntax interpretation bug that is causing an issue getting FlexQoS to work properly.

E.g.

View attachment 52761

please share screenshots that provide examples of how you fill out your policies.
Please refrain from speaking to me. I think you are a complete tool
 
Thansk for the info...I know you dont game but If you create a rule i.e. Gaming rule (default) with a static IP, do you think it would cause any reboot issues? Just curious. Any input is greatly appreciated!
I am trying to test it out. I will look at it later today sometime. I am sure if I put in rules like some of the posters around here have I might trigger some kind of bad behavior. But apparently some of the posters around here get touchy about sharing examples. Do you have any rules that seem to be causing your router to reboot?
 
Usually, reboots come at around 30 minutes
That’s weird to me, unless it suggests only certain traffic triggers some classification/marking that causes a reboot. Is there ever any crashlog in the syslog during the next boot?

The other wildcard is the QoS signature versions between then and now. In the end, I think we’re going to discover that the new GPL and the closed-source components have screwed us over without any recourse.

It would be useful if someone would add a manual iptables rule to a vanilla Adaptive QoS setup and see if any crashes.
Code:
iptables -t mangle -A POSTROUTING -o br0 -p tcp -m multiport --sports 80,443 -m mark --mark 0x80080000/0xc03f0000 -j MARK --set-mark 0x8003ffff/0xc03fffff
iptables -t mangle -A POSTROUTING -o eth0 -p tcp -m multiport --dports 80,443 -m mark --mark 0x40080000/0xc03f0000 -j MARK --set-mark 0x4003ffff/0xc03fffff
Or add just one in case it’s a directional issue, and add the next one if no issues after a day.
 
That’s weird to me, unless it suggests only certain traffic triggers some classification/marking that causes a reboot. Is there ever any crashlog in the syslog during the next boot?

The other wildcard is the QoS signature versions between then and now. In the end, I think we’re going to discover that the new GPL and the closed-source components have screwed us over without any recourse.

It would be useful if someone would add a manual iptables rule to a vanilla Adaptive QoS setup and see if any crashes.
Code:
iptables -t mangle -A POSTROUTING -o br0 -p tcp -m multiport --sports 80,443 -m mark --mark 0x80080000/0xc03f0000 -j MARK --set-mark 0x8003ffff/0xc03fffff
iptables -t mangle -A POSTROUTING -o eth0 -p tcp -m multiport --dports 80,443 -m mark --mark 0x40080000/0xc03f0000 -j MARK --set-mark 0x4003ffff/0xc03fffff
Or add just one in case it’s a directional issue, and add the next one if no issues after a day.
I added both of these rules to test it for you. Will report back if the reboots start to happen.
 
But you don’t normally have reboots.
I had a random reboot spell when I added a full set of rules to the iptables using the policy under flexQoS. I just wanted to see how well it handled the rules. I was testing to see if traffic was being marked properly if I added my own policies. Which I verified it was working well until the router randomly rebooted. It happened approximately 20 to 30 minutes after adding all the rules. I haven't been able to reproduce the behavior since.
 
I keep coming back to this change that Asus made to the netfilter xt_mark module. It landed in 388.3 for the 88 PRO and the other HND5.04 models in 388.4. Since FlexQoS makes extensive use of the mark module with iptables, I’d like to understand what’s so special about marks that end in 001 (assuming I interpret the code correctly) and what it means to skip blog.

Diff:
commit bf1758f280e808597348933cbc4227851d066426
Author: Eric Sauvageau <merlin@asuswrt-merlin.net>
Date:   Wed Jun 7 00:37:08 2023 -0400

    Merge RT-AX88U_PRO binary blobs + SDK from 388_23110

diff --git a/release/src-rt-5.04axhnd.675x/kernel/linux-4.19/net/netfilter/xt_mark.c b/release/src-rt-5.04axhnd.675x/kernel/linux-4.19/net/netfilter/xt_mark.c
index fccc2b940b..ee63884584 100644
--- a/release/src-rt-5.04axhnd.675x/kernel/linux-4.19/net/netfilter/xt_mark.c
+++ b/release/src-rt-5.04axhnd.675x/kernel/linux-4.19/net/netfilter/xt_mark.c
@@ -33,7 +33,7 @@ mark_tg(struct sk_buff *skb, const struct xt_action_param *par)
        skb->mark = (skb->mark & ~info->mask) ^ info->mark;
 
 #if defined(CONFIG_BCM_KF_BLOG) && defined(CONFIG_BLOG)
-       if (skb->mark & 0x1)
+       if ((skb->mark & 0x7) == 0x1)
                blog_skip(skb, blog_skip_reason_nf_xt_skiplog);
 #endif

C:
/*
 *------------------------------------------------------------------------------
 * Function     : blog_skip
 * Description  : Disable further tracing of sk_buff by freeing associated
 *Blog_t (if any)
 * Parameters   :
 *  skb_p       : Pointer to a sk_buff
 *  reason      : The reason/location why blog_skip was called
 *------------------------------------------------------------------------------
 */
void blog_skip( struct sk_buff * skb_p, blog_skip_reason_t reason )
{
    blog_print( "skb<%px> [<%px>]",
skb_p, __builtin_return_address(0) );

    blog_assertv( (skb_p != (struct sk_buff *)NULL) );

if ( likely(skb_p->blog_p != BLOG_NULL) ){
blog_ctx_p->blog_skip_stats_table[reason]++;
_blog_free( skb_p );
}
}
 
Last edited:
I am trying to test it out. I will look at it later today sometime. I am sure if I put in rules like some of the posters around here have I might trigger some kind of bad behavior. But apparently some of the posters around here get touchy about sharing examples. Do you have any rules that seem to be causing your router to reboot?
I had created a gaming rule and streaming rule when I owned the AX11000 Pro similar to below. This was a few months ago. However I'm back to the original AX11000 now so I can't help.
 

Attachments

  • Screenshot_20230825_114016_Samsung Internet.jpg
    Screenshot_20230825_114016_Samsung Internet.jpg
    79.6 KB · Views: 102
I had created a gaming rule and streaming rule when I owned the AX11000 Pro similar to below. This was a few months ago. However I'm back to the original AX11000 now so I can't help.

Thank you for sharing. I will try it out. See if I get any bad results. So, far I haven't had issues with the iptable rule Dave posted. I think he is on the right path though with his prior post.
 
Curious if anyone ever sees any packets that meet this requirement above. This iptables rule would log such packets in syslog. Ideally, people experiencing reboots may see the messages in their syslog prior to the reboot, if this hypothesis has any value. Otherwise, it's just going to make log noise.
Code:
iptables -t mangle -I POSTROUTING -m mark --mark 0x1/0x7 -j LOG --log-prefix "[FlexQoS PRE Debug] " --log-tcp-options --log-ip-options
iptables -t mangle -A POSTROUTING -m mark --mark 0x1/0x7 -j LOG --log-prefix "[FlexQoS POST Debug] " --log-tcp-options --log-ip-options
If it doesn't seem to precede any reboots, you can remove the logging rule by running:
Code:
iptables -t mangle -D POSTROUTING -m mark --mark 0x1/0x7 -j LOG --log-prefix "[FlexQoS PRE Debug] " --log-tcp-options --log-ip-options
iptables -t mangle -D POSTROUTING -m mark --mark 0x1/0x7 -j LOG --log-prefix "[FlexQoS POST Debug] " --log-tcp-options --log-ip-options
 
Last edited:
Hi,

After upgrading for the latest merlin firmware, the flexqos is showing the diversion “page” instead of the flexqos page.

The help and support page is also giving me an error…

404 Not Found​

File not found.

I already uninstalled and installed, but the issue continues.

Can anyone help me?
 

Attachments

  • Captura de ecrã 2023-09-02, às 09.08.53.png
    Captura de ecrã 2023-09-02, às 09.08.53.png
    161.6 KB · Views: 84
I agree, 388.2_2 was good for me with FlexQoS. For my model, RT-AX86U Pro, there was no 388.3. Presumably, changes from 388.3 would have been incorporated in early betas of 388.4. if that assumption is correct, then it's strange why for my case installing 388.4 beta 1 , then beta2 didn't bring any major reboot issue. I have already one Asus RT-AX86U Pro downgraded in 388.4 beta 2 with latest FLexQoS and monitoring the situation.
I'm having the exact same issue with FlexQOS on the same router model and firmware.
I can't actually keep the router up long enough to try to explore any logs.
 
flexqos is showing the diversion “page” instead of the flexqos page
It sounds like Diversion is overwriting the FlexQoS page. Would you run these commands?
Code:
grep -E "FlexQoS|Diversion" /tmp/menuTree.js
grep -E "user[0-9]+\.asp" /jffs/addons/custom_settings.txt
grep -F "<title>" /www/ext/user*.asp
ls -l /www/ext/
 
Hi team! Remained silenced a few days because I had lost access to my remote RT-AX86U Pro due to some WAN connectivity issues with my ISP. However, that router running 388.4 beta 2 with FlexQoS shown absolutely no reboot issues.

Screenshot 2023-09-05 120609.png
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Staff online

Top