Create a pipe ("checkpipe" or whatever) with a very small limit (e.g. 56kbit/s). Reference this pipe
with the traffic/shaperrule that you want to verify in your ruleset (http to destination xyz). Then
generate the traffic that should match this rule (for example surfing with your browser to adress
xyz). If it's very slow your rule matches your definition. Then change the assignment of that rule
to the originally desired queue or pipe. You can keep this "checkpipe" for later tests. Just don't
reference it and only do to test your ruledefinitions.
> -----Original Message-----
> From: Bob Young [mailto:bob at lavamail dot net]
> Sent: Tuesday, August 29, 2006 5:52 PM
> To: Holger Bauer
> Cc: m0n0wall at lists dot m0n0 dot ch
> Subject: RE: [m0n0wall] Is there logging for M0n0wall Traffic Shaper
> rules ?
> Hello Holger:
> Thank you for your reply. I'm not sure I understand.
> I do have a few queue/pipe rules that limit bandwidth and
> they work. I just
> change the BW of the pipe, and then I can go to a web site
> like Speak Easy
> that will allow me to check BW, when I'm no that particular
> computer for
> which the BW was changed. But BW is the only queue/pipe rule
> that I know how
> to check for.
> In this particular case I'm trying to pass incoming HTTP
> traffic through a
> mid-priority level queue, prior to my low priority
> "catch-all" queue. But
> even if I didn't have the "catch-all" queue, if none of my
> queues matched,
> the incoming HTTP traffic will still pass on to the output
> interface, at the
> regular speed of the pipe itself (if I understand all this
> I'm glad to see you do validate this problem. I figure I
> have three paths
> my incoming HTTP traffic can take. I just don't know how to
> tell which path
> it is taking: 1. My midlevel queue, 2. "catch-all" queue. Or
> 3. Bypassed
> all queues and just went out the pipe to the output interface.
> Maybe you are onto something there, but I don't think I
> understand. I'm not
> sure how I can stop all other traffic, but just try to pass
> my incoming HTTP
> traffic, via a particular queue.
> Could you go into a little more detail about how I can tell
> if a particular
> queue (like my queue for incoming http traffic) is passing
> through my mid
> level queue, as opposed to my catch all queue?
> Thanks much for your contribution,
> Bob Young
> -----Original Message-----
> From: Holger Bauer [mailto:Holger dot Bauer at citec dash ag dot de]
> Sent: Tuesday, August 29, 2006 10:37 AM
> To: Bob Young; m0n0wall at lists dot m0n0 dot ch
> Subject: RE: [m0n0wall] Is there logging for M0n0wall Traffic
> Shaper rules ?
> There is no such feature yet but I know the problem. I
> usually do it the
> following way:
> Create a rule&pipe that is limitting the traffic to some
> value that is lower
> than the expected bandwidthusage of that traffic. Then make all other
> traffic stop or try under low traffic condition and see if
> the traffic that
> should match this rule is actually limited. If so your
> ruledefinition is
> correct. You now can change the assignment to another queue/pipe that
> reflects the real usage. It's not a good solution but should
> at least show
> if your rule definition is correct.
> > -----Original Message-----
> > From: Bob Young [mailto:bob at lavamail dot net]
> > Sent: Tuesday, August 29, 2006 3:12 PM
> > To: m0n0wall at lists dot m0n0 dot ch
> > Subject: [m0n0wall] Is there logging for M0n0wall Traffic
> > Shaper rules ?
> > Does anyone know if there is logging for individual Traffic
> > Shaper rules?
> > I know M0n0wall has firewall logging. But Traffic Shaper
> > logging would be
> > great if M0n0wall has it.
> > It's easy to just assume a particular Traffic Shaper rule is
> > working, just
> > because we put it in as a Traffic Shaper rule. When in
> > reality maybe the
> > packets are passing our intended rule and going on to our
> > lower priority
> > "catch-all" rule.
> > Or...
> > If none of our Traffic Shaper rules are a match, then the
> > data still passes
> > out the pipe to the destination interface, using the full BW
> > that the pipe
> > is set for, with no queuing at all.
> > So in reality we may only "think" a Traffic Shaper rule we
> typed in is
> > working, when in reality it is being bypassed completely.
> > Thank you for any info on how to log the Traffic Shaper rules.
> > Respectfully,
> > Bob Young