Project

General

Profile

Bug #3998

Duplicated limiter numbers

Added by Reto Strub almost 4 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Traffic Shaper
Target version:
Start date:
11/09/2014
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.1.5
Affected Architecture:

Description

I’ve 19 limiters (number 1 to 20, expect 13)
If I add a new one, he gets an already occupied number, 15. After that I’ve two limiters with the same number 15 … so the first one isn’t working anymore (overwritten).

Possible fix on file /etc/inc/shaper.inc : 4412

-: $dnnumber = $dnnum + 1;
+: $dnnumber = $dnnum - 1;

Associated revisions

Revision 89cf3dc0 (diff)
Added by Renato Botelho almost 4 years ago

Fix logic to find available next number for limiters and queues. It fixes #3998

Revision 8105ffa6 (diff)
Added by Renato Botelho almost 4 years ago

Fix logic to find available next number for limiters and queues. It fixes #3998

History

#1 Updated by Phillip Davis almost 4 years ago

On 2.2 I tried adding a few limiters and children and then deleting ones in the middle of the list... It seems that current code rewrites the limiter numbers after each delete/disable so that there is no gap. Actually those numbers do not seem to be in the config like that anyway, they are generated on the fly. I was executing this bit of code to see what was happening to the numbers:
include_once("shaper.inc");
read_dummynet_config();
$nextnum = dnqueue_find_nextnumber();
var_dump($nextnum);

$dnused = array();
if (is_array($dummynet_pipe_list)) {
foreach ($dummynet_pipe_list as $dn) {
$tmplist =& $dn->get_queue_list();
foreach ($tmplist as $qname => $link) {
var_dump($qname);
var_dump($link);
if ($link[0] == "?")
$dnused[$qname] = substr($link, 1);
}
}
}
var_dump($dnused);

And ended up with this result:
int(3)
string(9) "MyLimiter"
string(1) "1"
string(4) "MyL2"
string(1) "2"
string(5) "Lim21"
string(2) "?1"
string(4) "Lim3"
string(1) "3"
string(5) "Lim31"
string(2) "?2"
array(2) {
["Lim21"]=>
string(1) "1"
["Lim31"]=>
string(1) "2"
}

And during the testing I had the last array with more entries in it, always with numbers "1" "2" "3" ... in order.
So I suspect that is why not everyone is seeing this bug. It only happens if you somehow have a limiter config that gets gaps in it.
In any case, if there is a gap, the code does not fill it in correctly, as you point out. The fix you suggest looks the right thing to do.
You could go to https://github.com/pfsense/pfsense and make the change and submit a pull request - it is very easy to do online for small changes like this.

#2 Updated by Renato Botelho almost 4 years ago

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

#4 Updated by Chris Buechler almost 4 years ago

  • Status changed from Feedback to Resolved

fixed

Also available in: Atom PDF