Project

General

Profile

Bug #8956

traffic shaper after upgrade to 2.4.4 not showing queue under each limiter

Added by khaled osama almost 2 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Traffic Shaper (ALTQ)
Target version:
Start date:
09/26/2018
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.4.4
Affected Architecture:
All

Description

traffic shaper after upgrade to 2.4.4 not showing queue under each limiter
i tried to create test limiter and added a queue but no change

the firewall system log shows the following

/rc.filter_configure_sync: SHAPER: Could not create queue uitygffyu on interface test because: Array ( [0] => Selected AQM not recognized. [1] => Selected AQM not recognized. [2] => Selected AQM not recognized. [3] => Selected AQM not recognized. [4] => Selected AQM not recognized. [5] => Selected AQM not recognized. [6] => Selected AQM not recognized. [7] => Selected AQM not recognized. )
/rc.filter_configure_sync: SHAPER: Could not create queue MW_down on interface MWdown_dontuse because: Array ( [0] => Selected AQM not recognized. [1] => Selected AQM not recognized. [2] => Selected AQM not recognized. [3] => Selected AQM not recognized. [4] => Selected AQM not recognized. [5] => Selected AQM not recognized. [6] => Selected AQM not recognized. [7] => Selected AQM not recognized. )
/rc.filter_configure_sync: SHAPER: Could not create queue MW_up on interface MWup_dontuse because: Array ( [0] => Selected AQM not recognized. [1] => Selected AQM not recognized. [2] => Selected AQM not recognized. [3] => Selected AQM not recognized. [4] => Selected AQM not recognized. [5] => Selected AQM not recognized. [6] => Selected AQM not recognized. )
1.jpg (46.4 KB) 1.jpg khaled osama, 09/26/2018 03:19 AM
config backup.txt (7.97 KB) config backup.txt khaled osama, 09/26/2018 03:20 AM
dnshaper before upgrade.txt (6.41 KB) dnshaper before upgrade.txt khaled osama, 10/01/2018 07:31 PM
dnshaper after upgrade.txt (7.97 KB) dnshaper after upgrade.txt khaled osama, 10/01/2018 07:31 PM
ipfw pipe show.txt (1.54 KB) ipfw pipe show.txt khaled osama, 10/01/2018 07:31 PM
rules.limiter.txt (630 Bytes) rules.limiter.txt khaled osama, 10/01/2018 07:31 PM
ipfw queue show.txt (121 Bytes) ipfw queue show.txt khaled osama, 10/01/2018 07:33 PM
2018-10-14_17-12.png (49.9 KB) 2018-10-14_17-12.png PRIQ shaper jake xanaro, 10/14/2018 07:16 PM
2018-10-14_17-18.png (55.1 KB) 2018-10-14_17-18.png Limiter jake xanaro, 10/14/2018 07:18 PM
2018-10-14_17-14.png (21.3 KB) 2018-10-14_17-14.png shaper and limiter applied to LAN rule jake xanaro, 10/14/2018 07:19 PM

Associated revisions

Revision cd3cde52 (diff)
Added by Jim Pingle over 1 year ago

Fix Limiter validation check, which allows old queues to display. Fixes #8956

The AQM defaults to droptail when empty, but empty was being rejected as
invalid even though it was handled in the code.

Revision df9aa538 (diff)
Added by Jim Pingle over 1 year ago

Fix Limiter validation check, which allows old queues to display. Fixes #8956

The AQM defaults to droptail when empty, but empty was being rejected as
invalid even though it was handled in the code.

(cherry picked from commit cd3cde526a9215e914c2f420c7e9c74b059a2ad0)

History

#1 Updated by Jim Pingle almost 2 years ago

  • Priority changed from High to Normal
  • Target version set to 2.4.4-GS
  • Affected Version set to 2.4.4
  • Affected Architecture All added
  • Affected Architecture deleted (amd64)

#2 Updated by Marco Jakobs almost 2 years ago

Priority "Normal"? This issue is a desaster for the QoS of the complete network! Is there any workaround which can be applied manually?

#3 Updated by Jim Pingle almost 2 years ago

This does not affect all users on 2.4.4, or all users who upgraded, and the priority reflects that. We intend to have it fixed either way.

As for a workaround, creating new limiters and queues appears to work perfectly fine for most.

If someone has a limiter problem where the queues DO NOT show up, we need to see the contents of the limiters from config.xml from before the upgrade as well as after the upgrade. The section we are looking for is the <dnshaper> ... </dnshaper> section. There should not be anything too private in there. We'd also like to see the contents of /tmp/rules.limiter, ipfw pipe show, and ipfw queue show.

Attach all of those in a text file here.

And as always, make sure you reset states between any limiter config change or test.

#5 Updated by Steve Beaver almost 2 years ago

  • Assignee set to Jim Pingle
  • Target version changed from 2.4.4-GS to 2.4.4-p1

#6 Updated by Samir Patel almost 2 years ago

Happened to me as well... really screwed here. Cannot see previous queues in the GUI (under Limiters) and cannot apply queues to firewall rules, though the queues are there in the XML file of the config. Cannot create new queues.

UPDATE: Deleted all limiters and started over. Was then able to create queues.

#7 Updated by sib iqb almost 2 years ago

I reinstall 2.4.4 from the scratch did everything no changes now using 2.3.5 again until problems solved because i am using in production environment hopefully this issue will be fixed soon ... best regards

#8 Updated by Matt _ almost 2 years ago

I think we should null-coalesce to "taildrop" for the AQM field to solve this issue, as that would be the default AQM of these limiters if they are not already set.

I can probably make a patch for this soon

#9 Updated by jake xanaro over 1 year ago

I just wanted to add that I am experiencing an issue with my limiter as well after upgrading to 2.4.4, but im not sure if its directly the same issue or not.

So I have both a PRIQ shaper, with bandwidth configured, and all children are using codel.
On top of that I also use limiters for cases where I want to further limit the speed to a fixed amount.

Watching the traffic monitor it almost looks like its jumping between the two bandwidths designated in the shaper and the limiter.

Prior to 2.4.4 I could specify on a LAN rule both the shaper and the limiter, and the speed of the limiter would always be honoured.

What i am seeing now while watching the traffic monitor is that the traffic occassionally dips down to the specified Limiter speed for a split second, but then Shoots up to the defined speed in the shaper.

I confirmed this by adjusting the limiter higher and lower.

Viewing Diagnostic -> limiter does show activity, but it seems maybe the speed of the limiter is not being honored, and is instead overwritten by the speed of the shaper.

my PRIQ shaper parents are LAN 49,000 Kbit Download, and WAN 19,000 Kbit upload

my limiters are LAN 20,000 Kbit Download, and WAN 5,000 Kbit upload

My connection speed is cable 50 down, 20 up.

I have been using this configuration since 2.3.0 and have not changed anything other than the recent upgrade from 2.4.3 to 2.4.4

#10 Updated by Jim Pingle over 1 year ago

Please re-read https://redmine.pfsense.org/issues/8956#note-3 and gather the requested information.

#11 Updated by Jim Pingle over 1 year ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#12 Updated by Terence Kent over 1 year ago

Hey Jim. Glad to see this issue is getting fixed - that's great!

However, I want to be sure you've seen #8973, which is related to this. Once the queues are specified correctly in the configuration, you immediately hit the issue described there.

#13 Updated by Jim Pingle over 1 year ago

I've seen it but it isn't directly relevant to this specific bug. This was only about the queues not showing.

#14 Updated by Terence Kent over 1 year ago

Ok, great - I'm glad you've seen it.

FWIW, I would vote for those two issues to go out together. While fixing the configuration makes the migrated Taildrop/FIFO limiter queues show up in the UI, they still aren't functional once they are visible.

#15 Updated by Jim Pingle over 1 year ago

They are unrelated, the only thing they have in common is that they are both limiter issues. One is a GUI parsing problem, the other is much deeper in dummynet. They have no direct association.

#16 Updated by Terence Kent over 1 year ago

Yes, of course! I might not have been clear, I totally understand that these are bugs in two different areas of code.

What I'm trying to communicate (albeit, poorly) is not that the same code is responsible for both issues, but that the feature supported by the code in this issue remains broken until both are addressed. The logic path is:

Premise: Why are limiter queues shown in the UI? To use the dummynet limiter queues, that is the sole reason the UI shows them.
Conclusion: If dummynet limiter queues are shown in the UI, but do not actually work, the situation has not be substantially improved from a feature standpoint.

So the ask here is to have fixes for both issues be released together. Though, if the premise is wrong, then fixing them independently makes sense.

#17 Updated by Jim Pingle over 1 year ago

Just because two bugs affect the same subsystem doesn't mean they are related, though. Limiters work fine for many people despite that other issue.

You're trying to make an association that doens't hold logically. Keep the discussion about that other issue on that issue. I only want comments here from people who have tested this specific issue to know if it's fixed. Anything else is not helpful.

#18 Updated by Steve Beaver over 1 year ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF