[Release] FreshJR Adaptive QOS (Improvements / Custom Rules / and Inner workings)

[Vexira]

Hmm, good question. Disabled via "FreshJRQoS -disable" (but didn't reboot due to family on the net but did do "service restart_firewall") and then started Asus Adaptive QoS, and it has the same problem - WAN dropped and reconnected after 10 minutes. So I guess that means it's not a FreshJR issue but some other QoS problem. Thanks to the empty scripts, the calls being made are clearly disabling the WAN due to dhcp expiration.

Still no joy with Cloudflare, here's a section of the log with Asus Adaptive QoS on pastebin: https://pastebin.com/0Ecfdye6



Pardon my ignorance, but doesn't this just mark the DHCP (67,68) along with DNS and NTP traffic with the classification for tc to control? Oh, wait, I missed the bang, I'm guessing that excludes those ports.

Ok, started FreshJR QoS back up, waited 5 mins for the rules to apply, and then ran these commands. Still failed! *sigh* Log at https://pastebin.com/UFX4w7qp The one difference I notice is that it gave

May  6 18:59:41 WAN_Connection: ISP's DHCP did not function properly.

which I usually only see once on reboot when DHCP is first initializing. A clue?

Hang on In regards to ISP dhcp not functioning there is a new continuous mode fix from Asus being trialled you might want to talk to Jack Cheng about it he's the Asus rep who's Handling it I can send you a link to his Whirlpool account so you can pm him in regards to the issue, I'm currently testing the fix as we speak, sent me a pm and I can see if I can't help.

 

[brummygit]

The nuclear option would be to run "service restart_wireless" if all the devices are wireless. If they are also wired, you would also have to restart the WAN as well with restart_net which would restart the firewall and QoS again and put you back in the same situation (not helpful).

Thanks, unfortunately I run my own mesh (pre-dating AiMesh) so all devices are wired to my router

 

[solstyce]

How about disabling QoS and posting a log showing happy DHCP renewing for 60 minutes. Maybe there’s a clue in the absence of failure.

BTW Cloudflare will block posts that contain /etc when concatenated with hosts.

Ah, thanks for the tip. Here's an excerpt after reboot (full log since reboot here). QoS is disabled but QoS apps analysis is still on, and I re-upgraded to 384.17. Tweaked with space between /etc /hosts, and obfuscated my IP and work information. As far as activity, web surfing, Netflix, and Plex/Chromecast were all active across multiple devices. Thanks to the stub files for wan and dhcpc you can see the link coming up (in the full log) and DHCP renewals like clockwork.

May  4 22:05:16 ntpd: Started ntpd
May  6 19:44:41 ntpd: Initial clock set
May  6 19:44:41 rc_service: ntpd_synced 679:notify_rc restart_diskmon
May  6 19:44:41 disk_monitor: Finish
May  6 19:44:42 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth E0:B9:4D:24:E8:6D, status: 0, reason: d11 RC reserved (0)
May  6 19:44:42 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc E0:B9:4D:24:E8:6D, status: 0, reason: d11 RC reserved (0)
May  6 19:44:43 disk_monitor: be idle
May  6 19:44:43 kernel: Init chrdev /dev/detector with major 190
May  6 19:44:43 kernel: tdts: tcp_conn_max = 8000
May  6 19:44:43 kernel: tdts: tcp_conn_timeout = 300 sec
May  6 19:44:47 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth AC:83:F3:39:76:02, status: 0, reason: d11 RC reserved (0)
May  6 19:44:47 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc AC:83:F3:39:76:02, status: 0, reason: d11 RC reserved (0)
May  6 19:44:48 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth AC:37:43:4A:03:5C, status: 0, reason: d11 RC reserved (0)
May  6 19:44:48 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc AC:37:43:4A:03:5C, status: 0, reason: d11 RC reserved (0)
May  6 19:44:58 kernel: SHN Release Version: 2.0.1 890c91d
May  6 19:44:58 kernel: UDB Core Version: 0.2.18
May  6 19:44:58 kernel: Init chrdev /dev/idpfw with major 191
May  6 19:44:58 kernel: IDPfw: IDPfw is ready
May  6 19:44:58 kernel: sizeof forward pkt param = 192
May  6 19:44:58 BWDPI: fun bitmap = 3
May  6 19:45:02 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May  6 19:45:02 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
May  6 19:45:02 dhcp_client: bound 108.228.12.XXX/255.255.252.0 via 108.228.12.1 for 600 seconds.
May  6 19:45:22 crond[239]: time disparity of 1055380 minutes detected
May  6 19:46:21 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth D4:D2:52:9E:18:26, status: 0, reason: d11 RC reserved (0)
May  6 19:46:21 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc D4:D2:52:9E:18:26, status: 0, reason: d11 RC reserved (0)
May  6 19:48:19 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth D8:0B:9A:80:EC:FE, status: 0, reason: d11 RC reserved (0)
May  6 19:48:19 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc D8:0B:9A:80:EC:FE, status: 0, reason: d11 RC reserved (0)
May  6 19:49:35 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)
May  6 19:51:20 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth AC:37:43:48:86:C3, status: 0, reason: d11 RC reserved (0)
May  6 19:51:20 syslog: WLCEVENTD wlceventd_proc_event(449): eth2: Assoc AC:37:43:48:86:C3, status: 0, reason: d11 RC reserved (0)
May  6 19:54:35 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)
May  6 19:59:36 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)
May  6 20:04:36 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)
May  6 20:09:36 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)
May  6 20:14:37 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)
May  6 20:14:41 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth E4:70:B8:23:4E:2F, status: 0, reason: d11 RC reserved (0)
May  6 20:14:41 syslog: WLCEVENTD wlceventd_proc_event(430): eth2: ReAssoc E4:70:B8:23:4E:2F, status: 0, reason: d11 RC reserved (0)
May  6 20:14:42 dnsmasq-dhcp[231]: Ignoring domain mywork.com for DHCP host name worklaptop
May  6 20:17:52 syslog: WLCEVENTD wlceventd_proc_event(420): eth2: Auth E4:70:B8:23:4E:2F, status: 0, reason: d11 RC reserved (0)
May  6 20:17:52 syslog: WLCEVENTD wlceventd_proc_event(430): eth2: ReAssoc E4:70:B8:23:4E:2F, status: 0, reason: d11 RC reserved (0)
May  6 20:17:53 dnsmasq-dhcp[231]: Ignoring domain mywork.com for DHCP host name worklaptop
May  6 20:19:36 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)
May  6 20:24:36 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)
May  6 20:29:37 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)
May  6 20:34:37 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)
May  6 20:39:37 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)
May  6 20:44:37 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)
May  6 20:49:37 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)

 

[dave14305]

Here's an excerpt after reboot

How about checking these iptables?

iptables -t mangle -nvL

 

[solstyce]

Will bypassing the gateway entirely resolve this issue?

https://www.dslreports.com/forum/r32491796-bypass-att-pace-gateway

Thanks for the pointer! Unfortunately, my setup is FTTN not FTTH - so the fiber goes to my neighborhood and then it's VDSL2 to my home so I just have the Pace 5268ac gateway which handles all the DSL, no ONT I can connect directly to.

I could try to get my own VDSL gateway that may handle bridged mode better to my AC68U (or replace the AC68U also to just have 1 device) but AT&T requires their own hardware so I'd be concerned either it wouldn't work due to auth / incompatibility issues or they'd recognize my unauthorized hardware and shut it down.

 

[solstyce]

How about checking these iptables?

iptables -t mangle -nvL

Here you go:

/tmp/home/root# iptables -t mangle -nvL
Chain PREROUTING (policy ACCEPT 726K packets, 217M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain INPUT (policy ACCEPT 170K packets, 27M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 553K packets, 189M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MARK       all  --  *      br0     192.168.2.0/24       192.168.2.0/24       MARK xset 0x1/0x7

Chain OUTPUT (policy ACCEPT 132K packets, 263M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 684K packets, 452M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain BWDPI_FILTER (0 references)
 pkts bytes target     prot opt in     out     source               destination

 

[maxbraketorque]

Thanks for the pointer! Unfortunately, my setup is FTTN not FTTH - so the fiber goes to my neighborhood and then it's VDSL2 to my home so I just have the Pace 5268ac gateway which handles all the DSL, no ONT I can connect directly to.

I could try to get my own VDSL gateway that may handle bridged mode better to my AC68U (or replace the AC68U also to just have 1 device) but AT&T requires their own hardware so I'd be concerned either it wouldn't work due to auth / incompatibility issues or they'd recognize my unauthorized hardware and shut it down.

One other work-around that I saw was a suggestion of disabling DMZ+ and then setting up a permanent VPN from the AC68U to a well-known VPN provider.

 

[dave14305]

Here you go:

What is most suspect now is the BWDPI_FILTER chain added when Adaptive QoS is enabled. It explicitly drops the DHCP traffic that @RMerlin allowed a few years ago in that thread we already talked about. I don't know the reasoning to block this, but since mangle gets processed before filter, it's a problem.

https://github.com/RMerl/asuswrt-merlin.ng/blob/master/release/src/router/rc/firewall.c#L5518

We could experiment with adding an ACCEPT in mangle PREROUTING before the the BWDPI_FILTER gets the traffic, but I don't know all the downsides.

 

[RMerlin]

The BWDPI_FILTER rules are from Asus, not from me.

 

[dave14305]

@solstyce If you want to run the experiment, enable Adaptive QoS and then run this command to log to syslog what is going to be dropped by the BWDPI_FILTER chain:

iptables -t mangle -I BWDPI_FILTER 2 -i eth0 -p udp -m udp --sport 67 --dport 68 -j LOG --log-prefix "[BWDPI - DHCP] " --log-tcp-sequence --log-tcp-options --log-ip-options

You can remove it with either

iptables -t mangle -D BWDPI_FILTER -i eth0 -p udp -m udp --sport 67 --dport 68 -j LOG --log-prefix "[BWDPI - DHCP] " --log-tcp-sequence --log-tcp-options --log-ip-options

or just

service restart_firewall

Since these are just temporary rules not yet put into firewall-start, they will also be reset if your WAN connection drops like it has so far with QoS on. Before that happens, if you see log messages being blocked every 5 minutes from your ISP, then you have a couple options to either delete these rules or insert an ACCEPT rule above these. I'd rather see some of the log messages first to see if we can limit the incoming IP range to your ISP.
Option 1: Delete the DROP rule from BWDPI_FILTER

iptables -t mangle -D BWDPI_FILTER -i eth0 -p udp -m udp --sport 67 --dport 68 -j DROP

Option 2: Insert an ACCEPT rule into the PREROUTING chain

iptables -t mangle -I PREROUTING 1 -i eth0 -p udp -m udp --sport 67 --dport 68 -j ACCEPT

Hopefully I've got the traffic flow right from port 67 to port 68. I don't often worry about DHCP.

 

[solstyce]

@solstyce If you want to run the experiment, enable Adaptive QoS and then run this command to log to syslog what is going to be dropped by the BWDPI_FILTER chain:

iptables -t mangle -I BWDPI_FILTER 2 -i eth0 -p udp -m udp --sport 67 --dport 68 -j LOG --log-prefix "[BWDPI - DHCP] " --log-tcp-sequence --log-tcp-options --log-ip-options

I'm no expert, but that's one weird MAC address in the dropped packets.

08:62:66:97:XX:XX = my AC68U
f8:2c:18:4a:XX:XX = 5268ac gateway
No idea where the ":08:00" comes from
192.168.1.254 is the IP address I access my gateway admin interface from, presumably DHCP server also
108.228.12.XXX = my WAN IP served from AT&T DHCP possibly being passed by a DHCP on the gateway since it's in DMZ+ mode

May  7 18:56:48 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
May  7 18:56:48 dhcp_client: bound 108.228.12.XXX/255.255.252.0 via 108.228.12.1 for 600 seconds.
May  7 18:56:49 adaptive QOS: Delayed Start Canceled
May  7 18:56:50 adaptive QOS: Applying - Iptable Down Rules
May  7 18:56:51 adaptive QOS: Applying - Iptable Up   Rules (eth0)
May  7 18:56:51 adaptive QOS: TC Modification Delayed Start (5min)
May  7 19:01:20 kernel: [BWDPI - DHCP] IN=eth0 OUT= MAC=08:62:66:97:XX:XX:f8:2c:18:4a:XX:XX:08:00 SRC=192.168.1.254 DST=108.228.12.XXX LEN=572 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=552 MARK=0x83400000
May  7 19:01:54 adaptive QOS: Applying  TC Down Rules
May  7 19:01:54 adaptive QOS: Applying  TC Up   Rules
May  7 19:01:54 adaptive QOS: Modifying TC Class Rates
May  7 19:03:50 kernel: [BWDPI - DHCP] IN=eth0 OUT= MAC=08:62:66:97:XX:XX:f8:2c:18:4a:XX:XX:08:00 SRC=192.168.1.254 DST=108.228.12.XXX LEN=572 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=552
May  7 19:05:06 kernel: htb: htb qdisc 16: is non-work-conserving?
May  7 19:06:18 custom_script: Running /jffs/scripts/dhcpc-event (args: deconfig)
May  7 19:06:18 lldpd[294]: removal request for address of 108.228.12.XXX%4, but no knowledge of it
May  7 19:06:18 custom_script: Running /jffs/scripts/wan-event (args: 0 disconnected)
May  7 19:06:18 dnsmasq[231]: read /etc /hosts - 6 addresses
May  7 19:06:18 dnsmasq[231]: read /etc /hosts.dnsmasq - 6 addresses
May  7 19:06:18 dnsmasq[231]: using nameserver 8.8.8.8#53
May  7 19:06:18 dnsmasq[231]: using nameserver 208.67.222.222#53
May  7 19:06:18 custom_script: Running /jffs/scripts/wan-event (args: 0 stopped)
May  7 19:06:18 kernel: [BWDPI - DHCP] IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:f8:2c:18:4a:XX:XX:08:00 SRC=192.168.1.254 DST=255.255.255.255 LEN=572 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=552
May  7 19:06:18 kernel: [BWDPI - DHCP] IN=eth0 OUT= MAC=08:62:66:97:XX:XX:f8:2c:18:4a:XX:XX:08:00 SRC=192.168.1.254 DST=108.228.12.XXX LEN=572 TOS=0x00 PREC=0x00 TTL=64 ID=0 PROTO=UDP SPT=67 DPT=68 LEN=552
May  7 19:06:18 custom_script: Running /jffs/scripts/dhcpc-event (args: bound)
May  7 19:06:18 lldpd[294]: removal request for address of 108.228.12.XXX%4, but no knowledge of it
May  7 19:06:18 custom_script: Running /jffs/scripts/wan-event (args: 0 connected)
May  7 19:06:19 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
May  7 19:06:20 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
May  7 19:06:20 dnsmasq[231]: read /etc /hosts - 6 addresses
May  7 19:06:20 dnsmasq[231]: read /etc /hosts.dnsmasq - 6 addresses
May  7 19:06:20 dnsmasq[231]: using nameserver 8.8.8.8#53
May  7 19:06:20 dnsmasq[231]: using nameserver 208.67.222.222#53
May  7 19:06:20 wan: finish adding multi routes
May  7 19:06:21 adaptive QOS: Applying - Iptable Down Rules
May  7 19:06:21 adaptive QOS: Applying - Iptable Up   Rules (eth0)
May  7 19:06:22 adaptive QOS: TC Modification Delayed Start (5min)
May  7 19:06:41 BWDPI: fun bitmap = 83
May  7 19:06:41 A.QoS: qos_count=0, qos_check=0
May  7 19:06:44 rc_service: service 30905:notify_rc firewall-restart
May  7 19:06:45 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)

I've spent most of my free time today learning about DHCP and iptables, ending up searching for reports of DHCP problems on this Pace 5268ac and found several. This thread seems spot on - either set your DHCP address as static in the router, hack your iptables not to drop the garbled packet, or get a new gateway. EDIT: The thread also mentions adding a static route to 192.168.1.254 to make DHCP work, but that doesn't make sense to me - I'd expect it to fail all the time if a missing route were the problem, not just when A.QoS is on.

I'm going to push Sonic for a different gateway, but in the meantime, assuming that MAC address is a wrong as I think it is, would option 1 or option 2 be a better approach for a temporary workaround? Or something different based on the logs?

 

[dave14305]

would option 1 or option 2 be a better approach for a temporary workaround? Or something different based on the logs?

I would start by just running option 1 at the command line and confirming if DHCP renews properly. If so, then I would modify option 2 to include 192.168.1.254 as the source IP so it’s less permissive.

if [ "$(nvram get qos_enable)" = "1" ] && [ "$(nvram get qos_type)" = "1" ]; then
  iptables -t mangle -I PREROUTING 1 -i eth0 -s 192.168.1.254/32 -p udp -m udp --sport 67 --dport 68 -j ACCEPT
fi

You can add this to /jffs/scripts/firewall-start before any other scripts are called since it’s time-sensitive in your setup. See if it works.

 

[solstyce]

You're a genius @dave14305!

Couldn't sleep, so did some more digging and learned the formatting of that SRC address is correct, so it's not a corrupt DHCP request.

Tried option 1 above, and ASUS and FreshJR Adaptive QoS is working! I see the

May  8 03:49:15 custom_script: Running /jffs/scripts/dhcpc-event (args: renew)

events in the log, and the WAN connection isn't being dropped. Eureka!

I added the option 1 rule

iptables -t mangle -D BWDPI_FILTER -i eth0 -p udp -m udp --sport 67 --dport 68 -j DROP

to the end of the firewall-start script. My understanding is that disabling then enabling FreshJRQoS will add the call to that script at the bottom of the firewall-start script. I'm assuming the BWDPI_FILTER rules are set before FreshJRQoS so the order of this rule and FreshJRQoS shouldn't matter.

I tried option 2 also, and it worked as well!

I finally figured out "iptables -t mangle -L" to see the mangle rules, and can see the effect of both these options reflected in the output.

So questions:

• Which rule is safer / better? I'm assuming option 1 but I admit I don't fully understand the packet flow through the rules.
• Any thoughts on why other people aren't running into the same problem? I'm thinking either my gateway is misbehaving, or other people are seeing this problem but don't realize it because they have a longer DHCP lease (1+ days)
• Any idea why ASUS would block incoming and outgoing DHCP packets as part of QoS?
  
• How can I thank you for all your help? I have the best intentions to contribute to this thread but know how often I fail. I've already contributed to @FreshJR and @RMerlin to support their work. Do you have a favorite beverage fund as well?

Really looking forward to my Zoom meetings today and firing up a few file transfers, video streams and speed tests to see what happens!

-------

To help future searchers find this solution -- The command above fixed my WAN connection dropping every 10 minutes due to AT&T Uverse / Sonic Fusion IP Broadband having a short DHCP lease and iptables blocking DHCP renew requests whenever Asus adaptive QoS was enabled. This was with an Asus AC68U router and Pace 5268ac gateway.

 

[dave14305]

Which rule is safer / better? I'm assuming option 1 but I admit I don't fully understand the packet flow through the rules.

"Safer" is to explicitly allow only 192.168.1.254 which you know is your gateway. But that means if the source IP changes to something else in the future, you have to update the script. "Better" could be to not include any source IP in the rule so that it's "set and forget". But that's really "easier" instead of "better".

Any thoughts on why other people aren't running into the same problem? I'm thinking either my gateway is misbehaving, or other people are seeing this problem but don't realize it because they have a longer DHCP lease (1+ days)

As home internet speeds have increased with some ISPs, some people forgo QoS altogether. But we can only speculate.

Any idea why ASUS would block incoming and outgoing DHCP packets as part of QoS?

No, and Merlin didn't seem to have an opinion either.

How can I thank you for all your help?

Pay it forward (as you already are). Write a wiki article once you're sure of the stability and behavior.

FYI: I always go back to this flowchart when trying to remember iptables flow.

 

[ugandy]

sorry if off topic:
is it expected to see a big throughput reduction with QoS enabled?
I easily get my line down limit of 600Mbps with QoS disabled, but if I enable it, I only average 400Mbps.
is this big of a drop expected?

BTW, i only used QoS to prevent uplink saturation (which kills my downlink)

 

[solstyce]

sorry if off topic:
is it expected to see a big throughput reduction with QoS enabled?
I easily get my line down limit of 600Mbps with QoS disabled, but if I enable it, I only average 400Mbps.
is this big of a drop expected?

Adaptive QoS uses deep packet inspection to check the first packet of every new connection. The faster your connection, the more work for the router. In the past FreshJR had recommended for fast connections, especially gigabit, not to use QoS for this reason. He recommends a system that does separate bandwidth allocation per device. Microtek IIRC. Personally I like knowing my real time communication traffic has higher priority than my file downloads.

You could also check your cpu usage to see if it's maxed out which indicates a faster router is needed.

Are you configured the way the first few parts recommends? No device priority.Manual bandwidth setting. No app analysis.

 

[ugandy]

Adaptive QoS uses deep packet inspection to check the first packet of every new connection. The faster your connection, the more work for the router. In the past FreshJR had recommended for fast connections, especially gigabit, not to use QoS for this reason. He recommends a system that does separate bandwidth allocation per device. Microtek IIRC. Personally I like knowing my real time communication traffic has higher priority than my file downloads.

You could also check your cpu usage to see if it's maxed out which indicates a faster router is needed.

Are you configured the way the first few parts recommends? No device priority.Manual bandwidth setting. No app analysis.

using plain AdaptiveQoS+freshJR on an AX88. up/down limits manually set at 90%. nothing fancy. cpu not maxed. tested when no other clients are downloading.

 

[maxbraketorque]

sorry if off topic:
is it expected to see a big throughput reduction with QoS enabled?
I easily get my line down limit of 600Mbps with QoS disabled, but if I enable it, I only average 400Mbps.
is this big of a drop expected?

BTW, i only used QoS to prevent uplink saturation (which kills my downlink)

On my AC86U with a gigabit connection, I get 1 gbps with QOS off, and at best about 800 gbps with QOS enabled. With QoS disabled, I've tried to disrupt VoIP connections by running speed tests, and I've had no success even though ping times on the outbound connection of the computer do shoot up during the outbound portion of the speed test.

 

[solstyce]

Pay it forward (as you already are). Write a wiki article once you're sure of the stability and behavior.

FYI: I always go back to this flowchart when trying to remember iptables flow.

Thanks for the info on iptables. Love learning more.

Everything's been solid as a rock so far! Went through the nightly check for presence without issue. My first day of zoom meetings without a single "internet connection unstable" warning!

Happy to contribute to the wiki. What scope do you think is appropriate for a new article? I don't see an article about FreshJRQoS. Should I create one with links to the first 3 posts on this thread and the ones I shared a few days ago, along with a "problems" section that includes this DHCP problem?

 

[dave14305]

What scope do you think is appropriate for a new article? I don't see an article about FreshJRQoS. Should I create one with links to the first 3 posts on this thread and the ones I shared a few days ago, along with a "problems" section that includes this DHCP problem?

FreshJR didn’t really have anything to do with your issue. It was stock Adaptive QoS, so you can write it for that broader audience. I don’t think it’s common to write a wiki page specific to a third-party script (except AMTM which is now delivered with the firmware). But the great thing about wiki articles is that if someone doesn’t like it, they can edit it.

So better (IMO) to post the full solution in the wiki (which can be updated by others) versus links to posts in the forum which may become outdated and can’t be updated by anyone but the OP.