Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Dec 2009 16:38:51 -0800
From:      Julian Elischer <julian@elischer.org>
To:        Luigi Rizzo <rizzo@iet.unipi.it>
Cc:        Ian Smith <smithi@nimnet.asn.au>, net@freebsd.org
Subject:   Re: RFC: documented and actual behaviour of "ipfw tee"
Message-ID:  <4B3BF29B.2040607@elischer.org>
In-Reply-To: <20091231003616.GA73067@onelab2.iet.unipi.it>
References:  <20091230002447.GA55727@onelab2.iet.unipi.it> <4B3AA290.8000508@elischer.org> <20091230221119.L81420@sola.nimnet.asn.au> <4B3BC659.7010707@elischer.org> <20091230225705.GC64766@onelab2.iet.unipi.it> <4B3BE85B.6080309@elischer.org> <20091231003616.GA73067@onelab2.iet.unipi.it>

next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote:
> On Wed, Dec 30, 2009 at 03:55:07PM -0800, Julian Elischer wrote:
>> Luigi Rizzo wrote:
> ...
>>>>> Which is what happens now, right?  Same behaviour on tee reinjection as 
>>>>> divert does seem consistent.  So if there is a problem, it's only with 
>>>>> the original packet continuing with the next rule if same-numbered?
>>> >from Luigi's description I'm not sure what happens now.. :-)
>>>
>>> fair enough, let me explain again:
>>> A. with "divert" the packet is passed to the divert
>>>  socket, and when/if reinjected processing continues no earlier
>>>  than the the NEXT NUMBERED rule. This is a restriction due to the
>>>  current divert socket API that I have no intention to change.
>>>  
>>> B. with "tee", the copy of the packet that goes to the socket
>>>   behaves the same as above. The original, which remains in
>>>   the kernel, continues processing from the NEXT NUMBERED RULE.
>> This is unexpected. It should  continue at the next rule
>> are you sure?
> 
> yes. this happens because the original has the same mtag as the
> reinjected 'diverted' packet. I can fix it easily now that we
> have rule_id. In the past it cold be fixed too, but needed more
> restructuring of code.

I had code somewhere where tee didn't leave firewall, but just sent
the other packet out, so it could just continue on.

at Ironport I had to hack on divert/tee a bit to make it work well 
with L2 packets.
so that got rewritten a bit.


> 
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B3BF29B.2040607>