FlexQoS FlexQoS 1.2.4 - Flexible QoS Enhancement Script for Adaptive QoS

[NGI]

Thanks for the prompt replay, as always, Dave. The traffic is controlled by 3 iptables rules based on the fixed IP address of the streamer (see below). With regards to your other question I'm trying to replicated the problem but I can't brake it now . As soon as I manage to reproduce it, I will report the findings.

View attachment 28968

I managed to reproduce it and it appears that the traffic class changes from "Others" to "File transfer" in the charts but it is still tracked as "Others" in the connections when I filter based on remote IP.

 

[dave14305]

I managed to reproduce it and it appears that the traffic class changes from "Others" to "File transfer" in the charts but it is still tracked as "Others" in the connections when I filter based on remote IP.

View attachment 28970
View attachment 28972

Try making your rules apply to BOTH protocol (tcp and udp) since I see udp connections in the list.

 

[NGI]

Try making your rules apply to BOTH protocol (tcp and udp) since I see udp connections in the list.

Happy to do that but I'm certain that the audio stream comes from IP: 69.64.52.71 Port: 10999. The streamer communicates with all sort of other IP for whatever reason hence I only made the rules applicable for 3 Marks that cover all Audio streams but exclude all other stuff.

 

[dave14305]

Happy to do that but I'm certain that the audio stream comes from IP: 69.64.52.71 Port: 10999. The streamer communicates with all sort of other IP for whatever reason hence I only made the rules applicable for 3 Marks that cover all Audio streams but exclude all other stuff.

Ok, what stats do you see if you run iptables -t mangle -nvL FlexQoS

Also, what Mark is that HiFi connection in the list (click the label)?

 

[NGI]

Ok, what stats do you see if you run iptables -t mangle -nvL FlexQoS

Also, what Mark is that HiFi connection in the list (click the label)?

Please see below:

T-AC86U-4AB0:/tmp/home/root# iptables -t mangle -nvL FlexQoS
Chain FlexQoS (1 references)
 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
    1    92 MARK       udp  --  *      br0     0.0.0.0/0            0.0.0.0/0                                                                               multiport dports 16384:16415 MARK xset 0x8006ffff/0x803fffff
    0     0 MARK       udp  --  *      ppp0    0.0.0.0/0            0.0.0.0/0                                                                               multiport sports 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       udp  --  *      br0     0.0.0.0/0            0.0.0.0/0                                                                               multiport sports 3478:3481 mark match 0x80000000/0xc03fffff MARK xset 0                                                                   x8006ffff/0x803fffff
   10  2520 MARK       udp  --  *      ppp0    0.0.0.0/0            0.0.0.0/0                                                                               multiport dports 3478:3481 mark match 0x40000000/0xc03fffff MARK xset 0                                                                   x4006ffff/0x403fffff
    0     0 MARK       udp  --  *      br0     0.0.0.0/0            0.0.0.0/0                                                                               multiport sports 8801:8810 mark match 0x80000000/0xc03fffff MARK xset 0                                                                   x8006ffff/0x803fffff
    0     0 MARK       udp  --  *      ppp0    0.0.0.0/0            0.0.0.0/0                                                                               multiport dports 8801:8810 mark match 0x40000000/0xc03fffff MARK xset 0                                                                   x4006ffff/0x403fffff
23692   34M MARK       tcp  --  *      br0     0.0.0.0/0            0.0.0.0/0                                                                               multiport sports 8080 mark match 0x800d00de/0xc03fffff MARK xset 0x8003                                                                   ffff/0x803fffff
12930  705K MARK       tcp  --  *      ppp0    0.0.0.0/0            0.0.0.0/0                                                                               multiport dports 8080 mark match 0x400d00de/0xc03fffff MARK xset 0x4003                                                                   ffff/0x403fffff
25149   13M MARK       tcp  --  *      br0     0.0.0.0/0            0.0.0.0/0                                                                               multiport sports 443 mark match 0x800d007e/0xc03fffff MARK xset 0x8003f                                                                   fff/0x803fffff
32758   40M MARK       tcp  --  *      ppp0    0.0.0.0/0            0.0.0.0/0                                                                               multiport dports 443 mark match 0x400d007e/0xc03fffff MARK xset 0x4003f                                                                   fff/0x403fffff
1108K 1569M MARK       tcp  --  *      br0     0.0.0.0/0            192.168.1.66                                                                            mark match 0x80030005/0xc03fffff MARK xset 0x800affff/0x803fffff
 593K   31M MARK       tcp  --  *      ppp0    192.168.1.66         0.0.0.0/0                                                                               mark match 0x40030005/0xc03fffff MARK xset 0x400affff/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

 

[dave14305]

Please see below:

T-AC86U-4AB0:/tmp/home/root# iptables -t mangle -nvL FlexQoS
Chain FlexQoS (1 references)
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
    1    92 MARK       udp  --  *      br0     0.0.0.0/0            0.0.0.0/0                                                                               multiport dports 16384:16415 MARK xset 0x8006ffff/0x803fffff
    0     0 MARK       udp  --  *      ppp0    0.0.0.0/0            0.0.0.0/0                                                                               multiport sports 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       udp  --  *      br0     0.0.0.0/0            0.0.0.0/0                                                                               multiport sports 3478:3481 mark match 0x80000000/0xc03fffff MARK xset 0                                                                   x8006ffff/0x803fffff
   10  2520 MARK       udp  --  *      ppp0    0.0.0.0/0            0.0.0.0/0                                                                               multiport dports 3478:3481 mark match 0x40000000/0xc03fffff MARK xset 0                                                                   x4006ffff/0x403fffff
    0     0 MARK       udp  --  *      br0     0.0.0.0/0            0.0.0.0/0                                                                               multiport sports 8801:8810 mark match 0x80000000/0xc03fffff MARK xset 0                                                                   x8006ffff/0x803fffff
    0     0 MARK       udp  --  *      ppp0    0.0.0.0/0            0.0.0.0/0                                                                               multiport dports 8801:8810 mark match 0x40000000/0xc03fffff MARK xset 0                                                                   x4006ffff/0x403fffff
23692   34M MARK       tcp  --  *      br0     0.0.0.0/0            0.0.0.0/0                                                                               multiport sports 8080 mark match 0x800d00de/0xc03fffff MARK xset 0x8003                                                                   ffff/0x803fffff
12930  705K MARK       tcp  --  *      ppp0    0.0.0.0/0            0.0.0.0/0                                                                               multiport dports 8080 mark match 0x400d00de/0xc03fffff MARK xset 0x4003                                                                   ffff/0x403fffff
25149   13M MARK       tcp  --  *      br0     0.0.0.0/0            0.0.0.0/0                                                                               multiport sports 443 mark match 0x800d007e/0xc03fffff MARK xset 0x8003f                                                                   fff/0x803fffff
32758   40M MARK       tcp  --  *      ppp0    0.0.0.0/0            0.0.0.0/0                                                                               multiport dports 443 mark match 0x400d007e/0xc03fffff MARK xset 0x4003f                                                                   fff/0x403fffff
1108K 1569M MARK       tcp  --  *      br0     0.0.0.0/0            192.168.1.66                                                                            mark match 0x80030005/0xc03fffff MARK xset 0x800affff/0x803fffff
593K   31M MARK       tcp  --  *      ppp0    192.168.1.66         0.0.0.0/0                                                                               mark match 0x40030005/0xc03fffff MARK xset 0x400affff/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

Please post tc -s filter show dev br0 | grep -B1 0x800a

 

[NGI]

Please post tc -s filter show dev br0 | grep -B1 0x800a

 tc -s filter show dev br0 | grep -B1 0x800a
filter parent 1: protocol all pref 5 u32 fh 827::803 order 2051 key ht 827 bkt 0 flowid 1:11  (rule hit 10589469 success 1243059)
  mark 0x800affff 0xc03fffff (success 1243059)
--
filter parent 1: protocol all pref 13 u32 fh 806::800 order 2048 key ht 806 bkt 0 flowid 1:11  (rule hit 195657 success 185)
  mark 0x800a0000 0xc03f0000 (success 185)

 

[dave14305]

 tc -s filter show dev br0 | grep -B1 0x800a
filter parent 1: protocol all pref 5 u32 fh 827::803 order 2051 key ht 827 bkt 0 flowid 1:11  (rule hit 10589469 success 1243059)
  mark 0x800affff 0xc03fffff (success 1243059)
--
filter parent 1: protocol all pref 13 u32 fh 806::800 order 2048 key ht 806 bkt 0 flowid 1:11  (rule hit 195657 success 185)
  mark 0x800a0000 0xc03f0000 (success 185)

It appears like the rules are working, but that doesn’t explain what you see in the GUI. To rule out any UI bugs, do you see the same mis-classification on the Classification page? The connection table will look different, but I’m at a loss where to start. Also, if you view the Bandwidth Monitor page, do you see the device receiving 2 Mbps? Lastly, if you filter the FlexQoS connections by Application class File Transfer, are other devices possibly downloading at the same time?

A New Year’s Eve stumper...

 

[NGI]

A New Year’s Eve stumper...

Indeed, apologies for the bad timing .

When the problem occurs, the Classification page reports the traffic in the same Class "Web File Transfer" in the charts and in the filtered connections sections.

However when the problem occurs (it is not necessary triggered with queuing last few times it just happened after playing the streamer for few minutes) the FlexQoS page reports the traffic differently in the Tracked connections.

Then when I stop and start the streamer all is back to normal (for a while) but what I find strange is the discrepancy in the Classification page the Chart shows "Others" and the tracked connections still show "Web File Transfer"

It appears to me that something happens and then the traffic fails to get classified in the custom classes and it switches back to the default Class TM engine assigned which is "File transfer"

 

[dave14305]

Then when I stop and start the streamer all is back to normal (for a while) but what I find strange is the discrepancy in the Classification page the Chart shows "Others" and the tracked connections still show "Web File Transfer"

This part is expected because the FlexQoS iptables rule is moving the traffic to Others but the Mark is still Web File Transfer.

the FlexQoS page reports the traffic differently in the Tracked connections.

The output of the FlexQoS Tracked connections is based on what is expected to happen to the connection and not what actually happens to the connection. It seems like maybe the firewall is restarting at some point during your listening. Is there anything in the system log when the problem occurs?

 

[NGI]

This part is expected because the FlexQoS iptables rule is moving the traffic to Others but the Mark is still Web File Transfer.

The output of the FlexQoS Tracked connections is based on what is expected to happen to the connection and not what actually happens to the connection. It seems like maybe the firewall is restarting at some point during your listening. Is there anything in the system log when the problem occurs?

Nothing that I can find alarming in the syslog, however quite a few events in the crash.log and firewal.log but I can't determine if they can cause the issues. Happy to PM you the logs if you are interested.

 

[dave14305]

Nothing that I can find alarming in the syslog, however quite a few events in the crash.log and firewal.log but I can't determine if they can cause the issues. Happy to PM you the logs if you are interested.

What about spdMerlin with AutoBW? Do you use that? Grasping here and hoping I can find a way to shift the blame toward him.

 

[L&LD]

@dave14305, always a wise path! @Jack Yaz has broad shoulders and can handle it with ease.

 

[NGI]

What about spdMerlin with AutoBW? Do you use that? Grasping here and hoping I can find a way to shift the blame toward him.

Yes I do but it only runs at night so unlikely to cause the problem that occurs during the day .

By the way I managed to catch the time of when the problem occurred and looking at the crash.log I can see the below. Could that be of any relevance?

Dec 31 19:16:12 RT-AC86U-4AB0 kernel: dcd[12257]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: pgd = ffffffc006820000
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: [00000000] *pgd=0000000009fc6003, *pud=0000000009fc6003, *pmd=0000000010850003, *pte=0000000000000000
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: CPU: 1 PID: 12257 Comm: dcd Tainted: P           O    4.1.27 #2
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: Hardware name: Broadcom-v8A (DT)
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: task: ffffffc0192b4b00 ti: ffffffc01056c000 task.ti: ffffffc01056c000
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: PC is at 0xf703af44
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: LR is at 0x1dc74
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: pc : [<00000000f703af44>] lr : [<000000000001dc74>] pstate: 600e0010
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: sp : 00000000ffdd0928
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: x12: 000000000009ff08
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: x11: 00000000f60ff024 x10: 00000000000a02ac
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: x9 : 00000000f60ffec0 x8 : 00000000000a0764
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: x7 : 00000000f60ffef0 x6 : 00000000000a075e
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: x5 : 0000000000000000 x4 : 00000000f60ffea4
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: x3 : 0000000000000000 x2 : 0000000000000000
Dec 31 19:16:12 RT-AC86U-4AB0 kernel: x1 : 000000000007c66c x0 : 0000000000000000

 

[Jack Yaz]

@dave14305, always a wise path! @Jack Yaz has broad shoulders and can handle it with ease.

i mean it could go the other way and I give up visiting the forums ;-)

 

[dave14305]

i mean it could go the other way and I give up visiting the forums ;-)

Already been done too many times...

 

[dave14305]

Yes I do but it only runs at night so unlikely to cause the problem that occurs during the day .

By the way I managed to catch the time of when the problem occurred and looking at the crash.log I can see the below. Could that be of any relevance?

I’m not sure this helps understand your issue, but I noticed today that while I had a large series of OneDrive uploads happening from a PC, and they were classified as “Microsoft Live.com” (Web Surfing). I didn’t like that since I considered it File Upload/Download, so I added an AppDB rule to put 0D0078 in Downloads and hit Apply. After the page refreshed, the connections previously tracked as Microsoft Live.com were now showing as Untracked.

Not until the connection was closed did new connections get classified by the DPI engine as Microsoft Live.com. I’m speculating that if the dpi engine doesn’t witness the beginning of the connection, it won’t always categorize it correctly.

Still not sure if or how this might apply to your scenario, but I found it odd.

On the plus side, by moving the traffic to Downloads, it correctly uses the full upload bandwidth (set as 22 Mb) but relinquishes the bandwidth when a higher priority class requests bandwidth. In the screenshot below, I ran an Xfinity speedtest from my phone which gets classified as Others. Once the upload speedtest was over, it went back to using as much bandwidth as it could.

I was happy to finally see a useful benefit from my graphs to prove QoS is working as intended.

 

[NGI]

Still not sure if or how this might apply to your scenario, but I found it odd.

Many thanks Dave for the idea above however in my case the issue almost happens few minutes after every time I start playing the streamer and the play is uninterrupted. Following your idea above initially I had a theory that if the bandwidth is close 100% utilisation the traffic to the streamer may get interrupted from time to time even if I don't notice the streamer to stop playing since there is about 4 sec in total in the buffers (3 sec at the streamer and 1 sec at the studio end). However just now my bandwidth is less that 15% utilised and the problem happened again after playing for 5-6min (685.13MB/2/60).

 

[Treadler]

I’m not sure this helps understand your issue, but I noticed today that while I had a large series of OneDrive uploads happening from a PC, and they were classified as “Microsoft Live.com” (Web Surfing). I didn’t like that since I considered it File Upload/Download, so I added an AppDB rule to put 0D0078 in Downloads and hit Apply. After the page refreshed, the connections previously tracked as Microsoft Live.com were now showing as Untracked.

Not until the connection was closed did new connections get classified by the DPI engine as Microsoft Live.com. I’m speculating that if the dpi engine doesn’t witness the beginning of the connection, it won’t always categorize it correctly.

Still not sure if or how this might apply to your scenario, but I found it odd.

On the plus side, by moving the traffic to Downloads, it correctly uses the full upload bandwidth (set as 22 Mb) but relinquishes the bandwidth when a higher priority class requests bandwidth. In the screenshot below, I ran an Xfinity speedtest from my phone which gets classified as Others. Once the upload speedtest was over, it went back to using as much bandwidth as it could.

I was happy to finally see a useful benefit from my graphs to prove QoS is working as intended.

View attachment 29018

Great idea!
Done, & I did likewise with the iTunes/AppStore, plus Apple Store.

Im fairly sure iOS & macOS updates have been classed as web surfing until now......
Shall await developments during the next updates.

 

[NGI]

@dave14305 just as an update a rooter reboot fixed the issue . I've been playing the streamer for hours today and no issues so far. The only thing that started to happen after the reboot I get frequent firewall restarts and the below is what I get in the syslog. Any idea what may be casing this?

Jan  2 15:33:58 RT-AC86U-4AB0 kernel: br0: received packet on wl0.1 with own address as source address
Jan  2 15:34:56 RT-AC86U-4AB0 dnsmasq-dhcp[27149]: DHCPREQUEST(br0) 192.168.1.79 80:2b:f9:1b:86:ef
Jan  2 15:34:56 RT-AC86U-4AB0 dnsmasq-dhcp[27149]: DHCPACK(br0) 192.168.1.79 80:2b:f9:1b:86:ef DESKTOP-V8J7HQR
Jan  2 15:35:26 RT-AC86U-4AB0 rc_service: amas_lib 1424:notify_rc restart_firewall
Jan  2 15:35:26 RT-AC86U-4AB0 kernel: 80:2B:F9:1B:86:EF already exist in UDB, can't add it
Jan  2 15:35:26 RT-AC86U-4AB0 custom_script: Running /jffs/scripts/service-event (args: restart firewall)
Jan  2 15:35:26 RT-AC86U-4AB0 nat: apply nat rules (/tmp/nat_rules_ppp0_eth0)
Jan  2 15:35:26 RT-AC86U-4AB0 custom_script: Running /jffs/scripts/firewall-start (args: ppp0)
Jan  2 15:35:26 RT-AC86U-4AB0 custom_script: Running /jffs/scripts/service-event-end (args: restart firewall)
Jan  2 15:35:26 RT-AC86U-4AB0 FlexQoS: /jffs/addons/flexqos/flexqos.sh (pid=11554) called in unattended mode with 1 args: -start
Jan  2 15:35:26 RT-AC86U-4AB0 FlexQoS: Applying iptables static rules
Jan  2 15:35:26 RT-AC86U-4AB0 FlexQoS: Applying iptables custom rules
Jan  2 15:35:27 RT-AC86U-4AB0 FlexQoS: Flushing conntrack table
Jan  2 15:35:27 RT-AC86U-4AB0 FlexQoS: No TC modifications necessary
Jan  2 15:35:34 RT-AC86U-4AB0 kernel: htb: htb qdisc 16: is non-work-conserving?