[SOLVED] traffic shaper queues bug
-
in the recent snaps have noticed that my VoIP traffic doesn't go in proper queues for some reason, at the download side doesn't, the upload side does fine, i have tried reapplying settings etc but still on the download side all the traffics ends up in the default p2p queue.
-
Did you by chance manually create any LAN queues instead of cloning a WAN queue? This is something I struggled with for the past two months since installing the 2.0 beta. Then just this past Thursday, I tried deleting all of my LAN queues and saw incoming traffic being routed to the WAN queue that corresponded to the LAN queue I wanted to use. So I cloned all of the WAN queues to LAN, didn't touch anything else and voila, traffic was reaching the desired LAN queues instead of the default LAN queue. As soon as I manually created a LAN queue, it broke the shaper for incoming traffic. I had to create the WAN side queue first, then clone it to the LAN side to get it to work.
-
i have all my rules etc on the floating tab and regarding the queues etc i havent changed any settings since ages and was working fine untill recently i noticed the download traffic going to the default queue so that put me in doubt if a bug was introduced in recent snaps
-
i tried cloning the queues also and even the rules on floating tab i tried changing from queue to pass but its still the same
-
I fooled around with the rules in the Floating, LAN, and WAN tabs a bit last week after having my Eureka moment. I don't remember exactly what the results were, but I ended up only needing the queuing rules under the LAN tab (source = LAN side address/port, destination = WAN side address/ports), with nothing in the Floating tab. Rules in the WAN tab are only set to allow for new incoming connections to be initiated from the WAN side - I have corresponding rules in the LAN tab to define the queuing, and no queues are defined in the WAN rules. So far everything seems to be working the way I had it set up in 1.2.2.
-
i have the below rules set under floating tab with Apply the action immediately on match ticked and mysip being the sip server alias and it used to work till some recent snaps but now i the voip queues on wan side works for upload but on downlaod side all goes to p2p queue, mayb the developers need to have a look at this
-
I have the same problem. Outgoing VoIP traffic go in the right queue, but incoming traffic goes in the wrong one (default queue).
-
so that makes 2 of us then, mayb if Ermal could look into it
-
Im having a similar problem here http://forum.pfsense.org/index.php/topic,36766.0.html devs should open a ticket for this…
-
I upgraded to RC2 last week. I only have traffic shaping for WAN. Everything seems to work fine except for VoIP. The traffic originating from my VoIP phone's IP should go to the VoIP queue but ends up in the default queue. I'm pretty sure the exact same setup worked with a previous snapshot (March or may April).
-
to narrow it down further, i think its got to do with selecting UDP as protocol coz i created new rules under floating tab and assigned same queue and those work fine for some reason, image below
-
Is definitely something with UDP traffic, i opened a ticket on the bug tracker. http://redmine.pfsense.org/issues/1546
Lets wait for a answer.
-
this issue still remains, i cleared all rules and recreated them along with queues based on the reply i got
http://redmine.pfsense.org/issues/1582
-
any1 willing to have a look at my config file in order to help me sort out this issue if it is really config related coz my voip phone seems to be almost unusable at high traffic and might have to switch to a old snap to make the queues work properly?
-
You seem to be having the exact behavior I see. Unfortunate the ticket just got closed, but this is supposedly be addressed by a pre-GA change (or so I seem to recall reading…)
-
Some peoples prefer to call it a feature or config issue, not a bug. In my view this should be termed a design bug/error as this violates the principle of stateful traffic processing.
In a stateful firewall/router/shaper users must be able to filter/route/shape traffic simply by specifying the behavior with respect to the session-initiating packet. Take for example NTP, the administrator must be able to pass, to route and to shape incoming NTP requests to the correct NTP server and the outgoing NTP replies from that server as well without special care of the 'outgoing' direction.
-
can u plz elaborate whats wrong as having a UDP queue which as a matter of fact used to work perfect earlier but something broke it, if i only knew which commit was it then would manually revert those changes on my box.
-
I can't tell. I just guess that it cannot be undone simply by reverting a single patch.
-
wouldnt it be possible to edit the config file manually to change the behavior temporarily till its fixed?
-
I have no clue on manual config file editing. A temporary workaround (that appears to work for me) is to simply ignore the Floating tab and to select queues directly on LAN, WAN and all OPTx tabs. It is not comfortable, but doable.
-
i have the below rule which i tried match as well as pass but still download traffic doesnt go to the proper queue
<rule><id><type>pass</type> <tag><tagged><direction>out</direction> <quick>yes</quick> <floating>yes</floating> <max><max-src-nodes><max-src-conn><max-src-states><statetimeout><statetype>keep state</statetype> <os><protocol>udp</protocol> <source> <any><destination><address>mysip</address></destination> <defaultqueue>qVoIP</defaultqueue></any></os></statetimeout></max-src-states></max-src-conn></max-src-nodes></max></tagged></tag></id></rule> <rule><id><type>pass</type> <tag><tagged><direction>in</direction> <quick>yes</quick> <floating>yes</floating> <max><max-src-nodes><max-src-conn><max-src-states><statetimeout><statetype>keep state</statetype> <os><protocol>udp</protocol> <source> <address>mysip</address> <destination><any></any></destination> <defaultqueue>qVoIP</defaultqueue></os></statetimeout></max-src-states></max-src-conn></max-src-nodes></max></tagged></tag></id></rule>can u plz mention this above rules how do i recreate using wan and lan tabs to make it work
-
Following is my config for a teleconference device that use TCP for control channels and UDP for data channels. Not sure if it works for you.
– on the LAN interface add new pass rules before the default rule with source IP = any, destination IP = any, destination port = 1720 TCP and 3230-3279 UDP. Select queue = qVoIP.
– repeat the same procedure on the WAN and OPTx interfaces. (Note: my WAN + OPTx are all connected to Internet. I've started setting up the shaper using the single-LAN-multi-WAN wizard.)
I've configured the shaper this way only for teleconference. In my system there are so many Internet links and so many types of traffics that I must rely on the (now unreliable) Floating Tab for the other traffic types. At least untill we replace pfsense with an other shaper.
-
i think it wont work as im using rules that match based on the server ip rather than any particular or range of ports but ill still give it a try
-
I am posting here but this is in general.
Traffic shaper behaviour should be ok on latest snapshots.
-
@ermal:
I am posting here but this is in general.
Traffic shaper behaviour should be ok on latest snapshots.I updated to the latest available (built on Mon Jul 4 16:48:37 EDT 2011) but didint change nothing to me.
-
Thanks, Ermal. I will try to update tonight after my wife goes to bed :) Currently running snap from June 22nd. This is one reason I love having pfsense virtualized on my ESXi server.
1. Take snapshot of virtual machine on the ESXi box.
2. Do the upgrade, and reboot pfsense.
3. Test things out.
4a. If all is well, delete the snapshot.
4b. If something is pooched, roll back to the snapshot and reboot pfsense.
-
@Ermal: I updated to Mon Jul 4 16:48:37 EDT 2011 snapshot but still it does not seem to work. I have an NTP server for testing. With the Floating Tab alone using pass out on any interface rules (with queueing), only NTP requests to my server are shaped, NTP replies are not.
-
No detectable change at all. I wiped the shaper. Created the same trivial shaper config as before. e.g. 10.0.0.7 is the voip host. Set for PRIQ. Save the config. Call my office phone and leave a message. No activity on the qVOIP queue. Finally, out of desperation, I deleted the 10.0.0.7, and saw the one floating rule replaced by two rules: one for the SIP ports and one for the RTP ports. I called my office phone again, and started leaving a voicemail. Looking at the queues as I did, I saw about 86kb/sec going out via qVOIP, so it is clearly the source IP address matching that was hosing me. Sigh…
-
Oh yeah, and the failure to use qACK at all outbound is still there…
-
i guess the last snapshot built was 04-Jul-2011 18:11 and in that its not fixed but mayb if a new snap is built then need to test on that
-
You have to wait for a new snapshot to have those changes :)
-
@ermal:
You have to wait for a new snapshot to have those changes :)
I tried the last snapshot (built on Thu Jul 7 00:25:19 EDT 2011) but didnt work…
nevermind, is working on the last snapshot (built on Thu Jul 7 16:08:10 EDT 2011) , tnx ermal :D
-
same here, finally works fine
-
Wish I could say the same. The two issues I've been reporting all along are still in the snapshot from 22:58 last night. e.g. VOIP with a host IP: still broken. qACK not being used: still broken :(
-
mayb u could post ur rule set if that might have some issue, try also ticking the quick match box for the rule.
-
No rule set other than created by the wizard. This is an absolutely trivial config. PRIQ. 22mb/sec inbound and outbound. Stepping thru the wizard, I default everything except for the voip section, where I selected "generic (lowdelay)" and put 10.0.0.7 (my asterisk box) as the IP. I get no LAN queues, and nothing goes into the qACK queue (occasional packets do go into qVOIP, but none of the audio, since the bit rate never gets more than a couple of kb/sec).
-
mayb u could post ur rule set if that might have some issue, try also ticking the quick match box for the rule.
This seems wrong. The shaper rules are non-quick (I thought) because all they do is queue the packet, there is no pass, which is handled (presumably) by the default LAN outbound rule, no? If I marked this as quick, wouldn't it not to be processed by the LAN out rule? Or am I confused? Besides which, the change I made yesterday (which does work, specifying asterisk/vonage, causing a rule for the SIP packets and a rule for the RTP packets), doesn't have quick and it works :(
-
No rule set other than created by the wizard. This is an absolutely trivial config. PRIQ. 22mb/sec inbound and outbound. Stepping thru the wizard, I default everything except for the voip section, where I selected "generic (lowdelay)" and put 10.0.0.7 (my asterisk box) as the IP. I get no LAN queues, and nothing goes into the qACK queue (occasional packets do go into qVOIP, but none of the audio, since the bit rate never gets more than a couple of kb/sec).
VoIP traffic is UDP, UDP does not generate acks
-
Sigh. I know that. I said there were two issues with the shaper wizard: 1) voip traffic from the specified host is not going to qVOIP, and 2) no traffic ever goes to qACK (and it used to - as far as I can tell, the shaper wizard is never generating any rules to do so, but this used to work.) I never said the two issues were related.
-
firstly i think the wizard has ahd issues recently so i wouldnt consider that a safe bet, secondly msot of the rules it might have generated would be on ur floating tab as i use that only to put traffic in specific queues, now to match voip traffic there needs to be a rule on the floating tab for out as well as for in and if ur going to match based on remote SIP server ip then u have to use the quick tickbox and if ur using a local machine ip to match then also use the quick tickbox but if ur matching a remote server port then u dont need to tick that quick tickbox. now dont ask me y to tick and y not because im not a firewall expert but i just managed to get my rules working over time with some trial and error and some help from this forum.
u can have a look at my rules from the floating tab, all rules r queues and not pass and the voip rules have quick match ticked but not for the http ones