Menu
What's new
By:
Filters Better Search

FlexQoS FlexQoS 1.2.4 - 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!

NGI said:
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 :rolleyes:. As soon as I manage to reproduce it, I will report the findings.

View attachment 28968
Click to expand...

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.

File transfer.jpg

Remote IP.jpg
 
dave14305 said:
Try making your rules apply to BOTH protocol (tcp and udp) since I see udp connections in the list.
Click to expand...

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.
 
NGI said:
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.
Click to expand...
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)?
 
dave14305 said:
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)?
Click to expand...

Please see below:

Code: 
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
 
NGI said:
Please see below:

Code: 
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
Click to expand...
Please post tc -s filter show dev br0 | grep -B1 0x800a
 
dave14305 said:
Please post tc -s filter show dev br0 | grep -B1 0x800a
Click to expand...

Code: 
 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)
 
NGI said:
Code: 
 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)
Click to expand...
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...
 
dave14305 said:
A New Year’s Eve stumper...
Click to expand...

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.

Classification.jpg


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.

FlexQoS.jpg


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"

Classification V2.jpg



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"

Problem.jpg

Bandwith monitor.jpg
 
NGI said:
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"
Click to expand...
This part is expected because the FlexQoS iptables rule is moving the traffic to Others but the Mark is still Web File Transfer.
NGI said:
the FlexQoS page reports the traffic differently in the Tracked connections.
Click to expand...
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?
 
dave14305 said:
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?
Click to expand...

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.
 
NGI said:
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.
Click to expand...
What about spdMerlin with AutoBW? Do you use that? Grasping here and hoping I can find a way to shift the blame toward him. :D
 
@dave14305, always a wise path! @Jack Yaz has broad shoulders and can handle it with ease. :)
 
dave14305 said:
What about spdMerlin with AutoBW? Do you use that? Grasping here and hoping I can find a way to shift the blame toward him. :D
Click to expand...

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?

Code: 
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
 
NGI said:
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?
Click to expand...
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.

FlexQoS.png
 
dave14305 said:
Still not sure if or how this might apply to your scenario, but I found it odd.
Click to expand...

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 :confused: after playing for 5-6min (685.13MB/2/60).

Problem V2.jpg
 
dave14305 said:
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
Click to expand...

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.
 
Last edited:
@dave14305 just as an update a rooter reboot fixed the issue :confused:. 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?

Code: 
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?
 
You must log in or register to reply here.

Similar threads

Squall Leonhart
FlexQoS FlexQOS faulty insstallation instruction
2
Replies
21
Views
2K
dave14305
dave14305
dave14305
FlexQoS FlexQoS 1.4.4 - Flexible QoS Enhancement Script for Adaptive QoS
2 3
Replies
41
Views
4K
dave14305
dave14305
G
amtm Intermittent connection resets when checking for or downloading script updates
Replies
2
Views
322
grim42
G
W
Looking for an add-on that does...
Replies
5
Views
2K
JGrana
JGrana
K
FlexQoS GT-AX11000 Pro - FlexQOS not starting?
Replies
10
Views
2K
raion969
raion969
Similar threads
Thread starter Title Forum Replies Date
dave14305 FlexQoS FlexQoS 1.4.4 - Flexible QoS Enhancement Script for Adaptive QoS Asuswrt-Merlin AddOns 41
M CAKEQOS/FLEXQOS Advise/Guidance/Best Practice Asuswrt-Merlin AddOns 34
A FlexQoS FlexQos Settings Problem Asuswrt-Merlin AddOns 83
poolbeetse7en FlexQoS FlexQoS - Setting up a Multicast IPTV box Asuswrt-Merlin AddOns 9
O FlexQoS FlexQOS Packet classification Asuswrt-Merlin AddOns 6
Squall Leonhart FlexQoS FlexQOS faulty insstallation instruction Asuswrt-Merlin AddOns 21
D CakeQOS GT-AX11000 with 1.5gbit symmetrical fibre internet and QoS Asuswrt-Merlin AddOns 6
Jack-Sparr0w Tune flex qos speed to vpn or with out vpn enabled. Need the specifics. Asuswrt-Merlin AddOns 5
Tom K. CakeQOS Problem with Zoom sent video quality (Cake QoS is a solution, but why?) Asuswrt-Merlin AddOns 8
A [SOLVED] Turned off outbound filtering and qos for upload still incredibly slow upload speeds? Asuswrt-Merlin AddOns 24

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!

Members online

Total: 760 (members: 12, guests: 748)
Top