Found a limiter issue and possible bug
-
I've tried searching through the bug database, and I couldn't seem to find anything relevant. I'm starting out by posting here. I'm currently on pfsense 2.3.2-RELEASE-p1. I've been using pfsense for a while now. Probably around 2 years, and I think this issue has always been there. I bring this up because I've read that pfsense 2.3.x is supposed to be somewhat buggy as far as limiters go, however, I've had this issue since before 2.3.
I have 2 sets of limiters. The first set is my regular down & up stream at 84.85/17 mbps, which isn't far off from my actual bandwidth.
My other set of limiters are set much slower. The down & up are set at 300/240 kbps respectively.
The first set set of limiters (84.85/17 mbits) have always worked fine. The 2nd set never really worked… I was able to download at about 1.89 MB/s, which is certainly slower than 84.85 mbits, but also much faster than 300 kbps.
Anyway, the TL;DR is that pfsense was using the same pipe id for my regular upstream limiter (17 mbps, which seems to work out to about 1.89 MB/s), as well as for my slow down & up limiters (supposed to be 300/240 kbps).
I ssh'ed into the router itself, and at the command line, I found the following contents in /tmp/rules.limiter:
# My regular downstream limiter: pipe 4 config bw 84.85Mb queue 1 config pipe 4 ... queue 2 config pipe 4 ... queue 3 config pipe 4 ... # My slow downstream limiter. pipe 5 config bw 300Kb queue 4 config pipe 5 ... # My slow upstream limiter. pipe 5 config bw 240Kb queue 5 config pipe 5 ... # My regular upstream limiter: pipe 5 config bw 17Mb queue 6 config pipe 5 ... queue 7 config pipe 5 ... queue 8 config pipe 5 ... ]
As you can see, it was using pipe ID 5 for 3/4 of my limiters. My regular upstream limiter was defined last, so that seems to be the definition that took precedence. I didn't see anyway to change the ID in the pfsense web UI.
I fixed this by taking a backup, and editing the numeric ID's in the XML backup file and giving them unique id's. This fixed the issue. Now my /tmp/rules.limiter file looks like this (comments inserted for clarity):
# My regular downstream limiter: pipe 4 config bw 84.85Mb queue 1 config pipe 4 ... queue 2 config pipe 4 ... queue 3 config pipe 4 ... # My slow downstream limiter: pipe 6 config bw 300Kb queue 4 config pipe 6 ... # My slow upstream limiter: pipe 7 config bw 240Kb queue 5 config pipe 7 ... # My regular upstream limiter: pipe 5 config bw 17Mb queue 6 config pipe 5 ... queue 7 config pipe 5 ... queue 8 config pipe 5 ...
Now all of my limiters are working exactly as expected.
As I've had this issue for some time, it's most likely been around since 2.3.x. Therefore, it's very possible has already been put into place to catch this issue, but no validation was done on existing values, which is why I'm hesitant to file a bug report unless this is a current bug and/or it makes sense to check the current values for conflicts (but it is nice that you can set arbitrary values in a backup in case you're trying something).
Thoughts anyone? Even if no one ends up responding, hopefully this will help someone googling about this same issue. ;)
-
For anyone unsure how to change a limiter's ID, just take an XML backup, open the XML backup, and find the parent limiter you're looking for by name, and change only the "number" field.
Here's an example to change the id from 5:
<queue><name>limit_name</name> <number>5</number></queue>
to 7:
<queue><name>limit_name</name> <number>7</number></queue>
I chose numbers 6 and 7 when fixing my issue above because they were the next unused/available numbers numerically.