Debugging rules: How to determine what traffic is getting past?

  • Hello,
      Before the RELEASE, I was using the RC2, and it seemed that p2p traffic was being assigned correctly to the correct queues.  I'm unsure is something happened between RC2 and release, or if I goofed a rule, but now traffic seems to be bypassing my p2p and low-priority queues, and ending up in the default queue.  Actually now that I look at it, nothing at all is going into the low-priority queue at all anymore.

    So, in an effort to identify the traffic that is magically appearing in the default queue, so I can tune my rules properly, I've been searching for a command that will show me what traffic is actually entering the incorrect queue.

    So after running around Google for the past 4 hours and coming up empty-handed, can someone tell me how to do this?

    I tried using the packet capture in hopes that it would put the tag in there, tried pfctl (with the switches I could find on the net), pftop, etc, and can't seem to find one that suits this specific need.

    Basically I'd like to see something similar to this:
    IP_Source IP_Destination TCP Length SRCport DESTport Information [queueTag]

    Is there some command that I can use to get an output that tells me what queue the packets are tagged for?

  • Also, if there is some tool that does this – it would be absolutely freakin' awesome if it could be somehow merged into the Diag>States screen.  [drools]

  • Still trying to figure out what traffic is going through the queues and not being snatched up by the rules.  The box in question runs Tor and I2P relays (I'm one of THOSE people… believe in Open Internet for all), and I have the rules set correctly (I think).  I know the incoming destination port, and have the outbound port locked to transmit only from a selected range for each service; and the rules matching this, one each for tcp and udp where necessary.  So the traffic should be tagged for the right queue.  I'd just like to be able to see exactly what traffic is passing through and ending up in the default queue so I can do my 'good deed' and yet not have my connection drug to a crawl.

    Anyhow, if anyone knows how I can see what traffic is going through what ruleset, please let me know!  Thank you in advance.

  • If no such tool, switch, or command exists, then can someone say so?  I keep shooting in the dark deep pit called Google and coming up with empty hands.

    I'm really hoping that this exists though.  Would be extremely useful!

  • Rebel Alliance Developer Netgate

    pfctl -vvsr | grep -A1 match

  • Hey jimp, thanks for the response.  That command gives me some more information, but is there anything that could say, tell me what queue a state is in?
    Basically, something like the States status page, but with the specific state labelled with what queue it went to?
    Or will I have to shut everything down on the network, then work out what is ending up in the wrong queue by each device/application?
    I'm pretty sure it is either torrent or I2P/tor traffic, so I could turn each service on one at a time, but even then I'm not sure I'd be able to figure out why the traffic isn't going where I think it should, since there is just so much traffic generated in different streams.

  • Rebel Alliance Developer Netgate

    I'm not aware of a way to get that information out of pf. It may exist, I'm just not sure where it might be hiding.

  • Hi Liath.WW

    you are not alone on the deep black path. I am digging, too

    Regards, Valle

  • @jimp:

    I'm not aware of a way to get that information out of pf. It may exist, I'm just not sure where it might be hiding.

    Eh, well, I guess if pf doesn't really have a tool that does that, if you guys get bored… lol.  Big can of worms and probably lots of work.
    Would help a LOT though, and make managing a lot easier.

  • No help from me either im afraid, but the idea is awesome imo..

    Debugging queues and general traffic management with such a tool would indeed make things a LOT easier :)


Log in to reply