Well do not hope this will ever work.

The problem is pretty simple, there are 2 action applied to the same
packet while this happens:
1- redirect changes the destination address
2- dummynet which just keeps the packet according to preconfigured
conditions and than reloops the packet.

IE a packet from 192.168.1.1 to www.yahoo.com enters the WAN interface
in ip_input() it hits a pf rdr rule which changes www.yahoo.com to
www.internal.yahoo.com after that the packet hits a ipfw dummynet rule
which after doing its QoS reloops the packet to ip_input() which again
sends it to pf which again hits the rdr rule which in case of tcp
drops the packet since a state already exists or the packet loops in
the stack forever exausting it with udp this might not happen but you
also might get a recursion in some cases.

Teh solution is just 2 flags to the pf tag or 2 new mbuf flags which
state that the packet has already been processed by pf and all this
would get fixed.

Why i haven't fixed this as of now well it is on the list :S

Greetings,
Ermal


On Thu, May 1, 2008 at 10:30 PM, Scott Ullrich <[EMAIL PROTECTED]> wrote:
> On 5/1/08, Luiz Vaz <[EMAIL PROTECTED]> wrote:
>
>
> > Well,
>  >
>  >   in my tests, "any to any" pipes hanged all the time.
>  >   And the "via" setting don't worked well too.
>  >
>  >   The pipe creation order are a problem too.
>  >   The manual don't talk about this, but you need to create the pipe before
>  > apply the mask.
>  >    Using the way you are trying, the pipe is created in the first command
>  > and again on the second. This can cause the hang on wan, because the mask
>  > will be set but the queue don't.
>  >
>  >   Taking a deep look, a saw that the mask combination used in your script
>  > you are matching the last byte of wan client address.
>  >    So if a client with address 64.233.167.99 and other 200.221.2.99 are
>  > matched as the same.
>  >    If you want to fix the bandwidth for a internet address you need to use 
> a
>  > full 0xffffffff mask.
>  >     Otherwise, Pipe 101 and 102 src-ip and dst-ip are in inverse order.
>  >
>  >    I will rewrite your script using my approach either for LAN and WAN.
>  >
>  >    When it´s ok i will send it to you!
>
>  Yes, please do, and I will add the package back and you will make a
>  lot of ppl happy.  Including a angry user from Lake of Egypt.   /me
>  ducks
>
>
>
>
>  Scott
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to