Hi David and everybody:
Thank you also David for your reply.
I like the idea of using the ping command as you test Monowall. I'll keep
that in mind as I test.
I had someone on another forum remote into my Monowall to see what I was
doing wrong for my VoIP outbound data setting. I goofed and had the TOS Low
Delay flag checked. I erroneously thought that should be turned on, since I
wanted low delay. I didn't realize that my VoIP provider must have that TOS
low delay flag set at their end for the data they were sending to me. So
what happened was my rule with TOS low delay didn't match, and so did not
take that pipe I had set up for it.
On the other hand my PAP2 ATA must be setting TOS low delay flags, cause I
have that checked off for my outgoing data. So my outgoing rule matches the
data my ATA is sending out, and so my VoIP outgoing pipe is being used.
Wow. This stuff is really tedious...lol. And interesting.
It is so neat that we all can get on here and help each other out. (My wife
says I need a lot of help...but that's a different matter...lol...Just
Thank you for the information on the interfaces and directions. I'll keep
that in mind.
Thank you all,
From: David W. Hess [mailto:dwhess at banishedsouls dot org]
Sent: Sunday, August 06, 2006 5:22 AM
To: Bob Young
Cc: m0n0wall at lists dot m0n0 dot ch
Subject: Re: [m0n0wall] VoIP voice quality surprise
On Sun, 6 Aug 2006 00:51:31 -0400, you wrote:
>I had someone from a forum remote into my Monowall and noticed I had "low
>delay" set for TOS for the incoming data. For some reason that low delay
>TOS setting overrode my low BW setting. I just assumed I was supposed to
>have the low delay set for VoIP. But that is what was causing my incoming
>audio data to still sound good and made me think the pipe wasn't working.
>Interestingly enough, the low delay setting for outgoing data did not over
>ride the low BW setting. Even with TOS low delay on, when I set the
>outgoing data to 25 Kbs, I had stuttering audio.
>Low delay TOS seemed to override the BW setting for incoming VoIP data, but
>not for outgoing VoIP data. I don't know why. So the question is, since
>this is for VoIP, should I have TOS low delay on or off for VoIP data?
So far as I know, the ToS flag are just like the TCP flags. They are used
selectively apply a rule to specific packets and do not actually change any
the flags. I always left them set to "don't care". In order to select my
traffic, I used the internal IP address of my VoIP client which is fixed.
If the traffic shaping rules only apply to traffic incoming on the interface
rules is written on and your rules were all on the WAN interface, then none
them applied to your outgoing traffic. See below.
>"To shape outgoing traffic, the rule has to be on the LAN or OPT interface.
>To shape incoming traffic, the rule has to be on the WAN interface. In
>practice this means the direction field has to always
>be set to "In" and the rule has to be placed on a specific interface to set
>Dave, regarding what you said about the outgoing and incoming traffic and
>the interfaces, I have been confused on this also.
>I saw something where a couple writers say all the shaper rules were to be
>on the WAN interface. But what you say about using the LAN and OPT1
>interfaces makes sense too. It's sometimes difficult to know for sure what
>interfaces to use for the shaper rules. Would be good to hear from other
I have read statements saying both that all rules need to be on the WAN
interface and that rules only apply to packets incoming on the interface the
rule is attached to so I was also confused. It would be easier if all rules
could be written for both directions and on one interface but I was never
to get it to work that way.
Originally when I tested this, I was using the system as a filtering bridge
only had to deal with one OPT interface. To test it, I used PING to measure
latency to the gateway on the other end of the DSL link. Then I adjusted
incoming and outgoing queue delays separately and made sure they were both
reflected in the PING latency. Originally with all rules on the WAN
as recommended, the outgoing rule did not work. Moving the outgoing rule to
OPT interface and setting its direction to incoming fixed it and gave the
intended result of independent traffic filtering on incoming and outgoing
I am using pfsense now but even with a different traffic shaper I found the
setup to be very similar if more complicated. I lament the loss of
queue delay though which made testing easier.