pfSense

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

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.

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.

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

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

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

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.

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

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.

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.

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.

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.