What's new

FlexQoS FlexQoS 1.0 - Flexible QoS Enhancement Script for Adaptive QoS

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

The only thing that changed in the hotfix is the ability to enable/disable the flushing. You also need to restart qos for the flushing setting to take effect on existing connections. Check if your iptables rules for Others traffic is being hit.
Code:
iptables -t mangle -nvL POSTROUTING
Hi Dave, it did happen again even though I didn't make any QoS related changes.

The first example below is when there is no traffic shown under Other Class ( I might have missed part of the last line due to copy/paste)

Chain POSTROUTING (policy ACCEPT 13370 packets, 9601K bytes)

pkts bytes target prot opt in out source destination

0 0 MARK udp -- * br0 0.0.0.0/0 0.0.0.0/0 multiport sports 500,4500 MARK xset 0x8006ffff/0x803fffff

0 0 MARK udp -- * ppp0 0.0.0.0/0 0.0.0.0/0 multiport dports 500,4500 MARK xset 0x4006ffff/0x403fffff

0 0 MARK udp -- * br0 0.0.0.0/0 0.0.0.0/0 udp dpts:16384:16415 MARK xset 0x8006ffff/0x803fffff

0 0 MARK udp -- * ppp0 0.0.0.0/0 0.0.0.0/0 udp spts:16384:16415 MARK xset 0x4006ffff/0x403fffff

0 0 MARK tcp -- * br0 0.0.0.0/0 0.0.0.0/0 multiport sports 119,563 MARK xset 0x8003ffff/0x803fffff

0 0 MARK tcp -- * ppp0 0.0.0.0/0 0.0.0.0/0 multiport dports 119,563 MARK xset 0x4003ffff/0x403fffff

0 0 MARK tcp -- * br0 0.0.0.0/0 192.168.1.66 mark match 0x80030005/0xc03fffff MARK xset 0x800affff/0x803fffff

0 0 MARK tcp -- * ppp0 192.168.1.66 0.0.0.0/0 mark match 0x40030005/0xc03fffff MARK xset 0x400affff/0x403fffff

0 0 MARK udp -- * br0 0.0.0.0/0 0.0.0.0/0 udp spts:3478:3481 mark match 0x80000000/0xc03fffff MARK xset 0x8006ffff/0x803fffff

0 0 MARK udp -- * ppp0 0.0.0.0/0 0.0.0.0/0 udp dpts:3478:3481 mark match 0x40000000/0xc03fffff MARK xset 0x4006ffff/0x403fffff

0 0 MARK udp -- * br0 0.0.0.0/0 0.0.0.0/0 udp spts:8801:8810 mark match 0x80000000/0xc03fffff MARK xset 0x8006ffff/0x803fffff

0 0 MARK udp -- * ppp0 0.0.0.0/0 0.0.0.0/0 udp dpts:8801:8810 mark match 0x40000000/0xc03fffff MARK xset 0x4006ffff/0x403fffff

0 0 MARK tcp -- * br0 0.0.0.0/0 192.168.1.66 mark match 0x80040050/0xc03fffff MARK xset 0x800affff/0x803fffff

0 0 MARK tcp -- * ppp0 192.168.1.66 0.0.0.0/0 mark match 0x40040050/0xc03fffff MARK xset 0x400affff/0x403fffff

0 0 MARK tcp -- * br0 0.0.0.0/0 192.168.1.66 mark match 0x801400c2/0xc03fffff MARK xset 0x800affff/0x803fffff

  • 0 MA

and the second is with traffic shown normally

pkts bytes target prot opt in out source destination

0 0 MARK udp -- * br0 0.0.0.0/0 0.0.0.0/0 multiport sports 500,4500 MARK xset 0x8006ffff/0x803fffff

0 0 MARK udp -- * ppp0 0.0.0.0/0 0.0.0.0/0 multiport dports 500,4500 MARK xset 0x4006ffff/0x403fffff

0 0 MARK udp -- * br0 0.0.0.0/0 0.0.0.0/0 udp dpts:16384:16415 MARK xset 0x8006ffff/0x803fffff

0 0 MARK udp -- * ppp0 0.0.0.0/0 0.0.0.0/0 udp spts:16384:16415 MARK xset 0x4006ffff/0x403fffff

0 0 MARK tcp -- * br0 0.0.0.0/0 0.0.0.0/0 multiport sports 119,563 MARK xset 0x8003ffff/0x803fffff

0 0 MARK tcp -- * ppp0 0.0.0.0/0 0.0.0.0/0 multiport dports 119,563 MARK xset 0x4003ffff/0x403fffff

5344 7816K MARK tcp -- * br0 0.0.0.0/0 192.168.1.66 mark match 0x80030005/0xc03fffff MARK xset 0x800affff/0x803fffff

2978 154K MARK tcp -- * ppp0 192.168.1.66 0.0.0.0/0 mark match 0x40030005/0xc03fffff MARK xset 0x400affff/0x403fffff

0 0 MARK udp -- * br0 0.0.0.0/0 0.0.0.0/0 udp spts:3478:3481 mark match 0x80000000/0xc03fffff MARK xset 0x8006ffff/0x803fffff

0 0 MARK udp -- * ppp0 0.0.0.0/0 0.0.0.0/0 udp dpts:3478:3481 mark match 0x40000000/0xc03fffff MARK xset 0x4006ffff/0x403fffff

0 0 MARK udp -- * br0 0.0.0.0/0 0.0.0.0/0 udp spts:8801:8810 mark match 0x80000000/0xc03fffff MARK xset 0x8006ffff/0x803fffff

0 0 MARK udp -- * ppp0 0.0.0.0/0 0.0.0.0/0 udp dpts:8801:8810 mark match 0x40000000/0xc03fffff MARK xset 0x4006ffff/0x403fffff

0 0 MARK tcp -- * br0 0.0.0.0/0 192.168.1.66 mark match 0x80040050/0xc03fffff MARK xset 0x800affff/0x803fffff

0 0 MARK tcp -- * ppp0 192.168.1.66 0.0.0.0/0 mark match 0x40040050/0xc03fffff MARK xset 0x400affff/0x403fffff

0 0 MARK tcp -- * br0 0.0.0.0/0 192.168.1.66 mark match 0x801400c2/0xc03fffff MARK xset 0x800affff/0x803fffff

0 0 MARK tcp -- * ppp0 192.168.1.66 0.0.0.0/0 mark match 0x401400c2/0xc03fffff MARK xset 0x400affff/0x403fffff

Can you see anything unusual?

EDIT: The only thing I did was to block and subsequently unblock one of my children devices from the Mobile App/Family section which make some changes to the permissions in the AiProtection which might have trigger it?
 
Last edited:
Hi Dave, it did happen again even though I didn't make any QoS related changes.

The first example below is when there is no traffic shown under Other Class ( I might have missed part of the last line due to copy/paste)

Can you see anything unusual?
There have been no new connections from your devices since the firewall rules were recreated due to a qos restart, I'm assuming. This is why the conntrack option exists to force persistent "pre-existing" connections to be filtered through the iptables rules. If spdMerlin/AutoBW is restarting qos every x minutes, but your .66 device is maintaining the same persistent connections, it will lose its special markings until a new connections are made or the conntrack table is flushed. Test it by manually running conntrack -F conntrack and seeing if the iptables counters start increasing again.
 
There have been no new connections from your devices since the firewall rules were recreated due to a qos restart, I'm assuming. This is why the conntrack option exists to force persistent "pre-existing" connections to be filtered through the iptables rules. If spdMerlin/AutoBW is restarting qos every x minutes, but your .66 device is maintaining the same persistent connections, it will lose its special markings until a new connections are made or the conntrack table is flushed. Test it by manually running conntrack -F conntrack and seeing if the iptables counters start increasing again.
a fix/improvement is on my to-do, I can only work so fast :(
 
There have been no new connections from your devices since the firewall rules were recreated due to a qos restart, I'm assuming. This is why the conntrack option exists to force persistent "pre-existing" connections to be filtered through the iptables rules. If spdMerlin/AutoBW is restarting qos every x minutes, but your .66 device is maintaining the same persistent connections, it will lose its special markings until a new connections are made or the conntrack table is flushed. Test it by manually running conntrack -F conntrack and seeing if the iptables counters start increasing again.
The only thing I did was to block and subsequently unblock one of my children devices from the Mobile App/Family section which makes some changes to the permissions in the AiProtection which might have trigger it?

EDIT: FYI conntrack -F conntrack restarted the counters and dropped my audio connection as expected.
 
Last edited:
The only thing I did was to block and subsequently unblock one of my children devices from the Mobile App/Family section which makes some changes to the permissions in the AiProtection which might have trigger it?

EDIT: FYI conntrack -F conntrack restarted the counters and dropped my audio connection as expected.
If it restarts the firewall, probably so.
 
a fix/improvement is on my to-do, I can only work so fast :(

Thanks @Jack Yaz. There is no rush in my side I wanted to understand what was causing the behavior and @dave14305 explanation of the firewall restart makes perfect sense. Thank you both very much for the amazing work you are doing.
 
@RMerlin are plans in the future to re-implement fq-codel or this no longer will be included in future firmwares

fq_codel support for Adaptive QoS was always a hack. Now that hack no longer works due to a change on how the Trend Micro engine generates the rules. So it's not a matter of whether I plan to support it or not, it's a matter of this hack no longer being possible.
 
I notice that if one checks the mark associated with an ATA voip adapter its either 000000 or 000051 in tracked connections. But if I go to the app DB section and type in 'Voip' a special mark comes up 06****. My question is how come the router does not pick up my voip traffic and label it with the 06****? What sort of device or s/w would that apply to?
 
I notice that if one checks the mark associated with an ATA voip adapter its either 000000 or 000051 in tracked connections. But if I go to the app DB section and type in 'Voip' a special mark comes up 06****. My question is how come the router does not pick up my voip traffic and label it with the 06****? What sort of device or s/w would that apply to?
VoIP services (06) is a category of the appdb database, which is why it has the **** to be used as a wildcard rule for all VoIP services marks.

1606271915924.png
 
Right that is what I wrote. except that the voip traffic from the Voip ata seems to attract a label/mark of 000000 when I check the tracked connections. That is why i was wondering what the source has to be in order for the Mark to show 06****. Voip traffic from the ata does not count is what I see.
 
Right that is what I wrote. except that the voip traffic from the Voip ata seems to attract a label/mark of 000000 when I check the tracked connections. That is why i was wondering what the source has to be in order for the Mark to show 06****. Voip traffic from the ata does not count is what I see.
A connection will never be marked with 06****. The Trend Micro engine doesn't know 06****. It's a FreshJR/FlexQoS placeholder to filter on all marks that are within the 06 category called VoIP. Your concern is that the Trend Micro engine does not properly identify your VoIP ATA traffic at all (000000), which is why iptables rules come in handy if the traffic can be unique identified by some criteria.
 
Hi,

I have a bit of a newbie question.

I've been using FlexQoS 1.05 for a couple of months and the gaming performance seems to have deteriorated. I've been getting a few stutters even when home network traffic is low. I am using the suggested gaming rule !80,443 / 000000. I have scheduled a daily router reboot a 05:00 to clear our any cobwebs, but it doesn't seem to have made any difference.

I've been reading through this thread and noticed that fq_codel is no longer supported in the new firmwares. Do the changes, made by Trend Micro, also apply to the older firmwares - i.e. is the change external to my router? Should I be switching to SFQ for 384.19?

My Roku radio streams have also been dropping after 30 minutes or so. The comments in this thread suggest this is linked to 'automatic bandwidth', but I'm using manual bandwidth settings. Is there an automatic speed test that's still running in the background? Where would I find those settings?

I've now updated FlexQoS to 1.06.

Thanks,
 
I've been reading through this thread and noticed that fq_codel is no longer supported in the new firmwares. Do the changes, made by Trend Micro, also apply to the older firmwares - i.e. is the change external to my router? Should I be switching to SFQ for 384.19?
fq_codel is still working fine in 384.19. No need to change until 386.1.
there an automatic speed test that's still running in the background? Where would I find those settings?
This is/was only an issue for people running the spdMerlin Addon also. Your system log would hold clues if something was happening to restart QoS or your firewall on a frequent basis.
 
Hi Dave,

Thanks for taking the time to reply.

What am I looking for in the logs? I can see that the date keeps changing to May?

1606478889379.png
 
Hi Dave,

Thanks for taking the time to reply.

What am I looking for in the logs? I can see that the date keeps changing to May?

View attachment 28022
When your router reboots the clock gets reset to May 5 2018 until NTP can sync. You’d be looking for FlexQoS to be applying changes or other service restarts or WAN DHCP renewing and restarting the firewall. In other words, we’ll know what we’re looking for once we see it. ;)
 
How should I set my QoS priorities?
There is 1 requirement to ensure the script works properly:
Learn-From-Home is lower priority than Video and Audio Streaming (I recommend the bottom of the priority list).

I'm not sure if I got properly what is the suggestion. Would you help me?
Screenshot_20201127-152558__01.jpg

Screenshot_20201127-152622__01.jpg


Edit: Added screenshots
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

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