FlexQoS FlexQoS issues with 388.4 HND5.04 models

[grateful70]

Try removing your special non default rules like 80,443>08****>5<>8.8.0.0/16>both>>>>0<192.168.1.122>>both>>>>3

nope. If I'm not using my own rules then I have no need to use flexqos at all.
My point is that flexqos 1.3.2 with the patch listed by Dave still doesn't work for me on 388.4

 

[Yiannis]

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.

 

[grateful70]

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

 

[Yiannis]

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.

 

[grateful70]

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

 

[thiggins]

Please refrain from speaking to me. I think you are a complete tool

@grateful70 Refrain from further personal attacks or you will be temporarily banned.

 

[SomeWhereOverTheRainBow]

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?

 

[dave14305]

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.

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.

 

[SomeWhereOverTheRainBow]

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.

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.

 

[dave14305]

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.

 

[SomeWhereOverTheRainBow]

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.

 

[dave14305]

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.

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

/*
 *------------------------------------------------------------------------------
 * 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 );
}
}

 

[Kingp1n]

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.

 

[SomeWhereOverTheRainBow]

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.

 

[dave14305]

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.

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:

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

 

[kuki68ster]

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?

 

[TurnstileBlues]

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.

 

[dave14305]

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?

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/

 

[dave14305]

I can't actually keep the router up long enough to try to explore any logs.

That’s OK, I don’t believe the problem is going to be fixable anyway.

 

[Yiannis]

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.