Traffic Rules … 2 Targets?



  • In the Traffic shaper rules, each rule has two targets. From the wizard rules there are Up and down targets.

    ie.  If  Proto Source          Destination                Target                          Description
            LAN TCP LAN net     *  Port: 6881 - 6999 qP2PUp/qP2PDown m_P2P BitTorrent outbound

    What and why are they there? Shouldn't there only be a single queue for each packet after it has meet the definded source/dest and ports? I'm just trying to understand the behaviour of the rules and that is about the only thing I cant seem to get my head around.

    in an effort to understand this I have gone through and disabled all the rules and enabled single ones to see their effect (except default queues).

    How is it possible to get traffic into a queue with all the rules that put traffic into that queue disabled? How can this happen?
    I disabled all the  qP2P rules but there is still traffic being classified and being put into the qP2PDown queue. I have applied rule changes after each rule edit. The queue status page updates ~ 20-30 seconds later with the changed.

    The rules -> http://img382.imageshack.us/img382/1710/rules18ru.gif

    The traffic queues -> http://img382.imageshack.us/img382/198/rules21xz.gif

    Thanks

    Koops



  • Yeah I have the same exact problems. Yesterday I let the wizard created simple queues for priotorizing http traffic. I deleted the rules to see the behaviour of the queues and classifications. Packets where still being pushed into the http queues and ptctl -s rules showed that the rules where still there after all. I when ahead and deleted the queues, unfortunately that dont seem to work either pfcl -s queues showed they were still there. After rebooting pfSense everything related to the queues were erased even though I didnt deleted the root queues.

    If it is any help to the team, I'm still in the process of learning php, I wouldnt mind helping sorting out these problems.



  • I've found that just doing a disable then enable fixes it. Still don't know what the two targets are for though.



  • been doing some reading on altq and came upon this:

    http://www.benzedrine.cx/ackpri.html

    Finally, the rules passing the relevant connections (statefully) are extended to specify what queues to assign the matching packets to. The first queue specified in the parentheses is used for all packets by default, while the second (and optional) queue is used for packets with ToS (type of service) 'lowdelay' (for instance interactive ssh sessions) and TCP ACKs without payload.

    not sure if it has the same binings to the gui in pfSense. but my guess is that its related.



  • @Leoandru:

    been doing some reading on altq and came upon this:

    http://www.benzedrine.cx/ackpri.html

    Finally, the rules passing the relevant connections (statefully) are extended to specify what queues to assign the matching packets to. The first queue specified in the parentheses is used for all packets by default, while the second (and optional) queue is used for packets with ToS (type of service) 'lowdelay' (for instance interactive ssh sessions) and TCP ACKs without payload.

    not sure if it has the same binings to the gui in pfSense. but my guess is that its related.

    We invisibly create the ACK queue.  ALTQ only shapes outbound on an interface, we create rules for BOTH interfaces and that's what the queues relate to.  An inbound (on the internal interface) and an outbound (on the external interface).

    –Bill


Locked