new target: -j TEE

Hi 
all,

The ROUTE targe seems to be finaly gone from pom-ng and we
need a
solution for the --tee function. So I deciced to use some
parts from the
ROUTE target, adaped the code to the current kernel and
implmemented a
new taget called TEE. The only function is packet
duplication and those
duplicate packets are routed the the given gateway (--gw
option).

We use this as a replacement for netwrk traffic taps, the
syntax is:
itpables -t mangle -A PREROUTING -p tcp --sport
<some-port> -j TEE --gw
<IP.of.mirror.box>

Is there any chance getting this into pom-ng?

Greets
  Sebastian.


-- 
Mit freundlichen Grüßen / Yours sincerely

Sebastian Claßen
Postmaster
------------------------------------------------------------
----------
Telefon: + 49 (0) 211 53087 522
Telefax: + 49 (0) 211 5381573
E-Mail:  sebastian.classenfreenet.ag
Website: www.freenet.de; www.mobilcom.de
------------------------------------------------------------
----------
freenet AG
Willstätterstr. 13
40549 Düsseldorf
------------------------------------------------------------
----------
Vorsitzender des Aufsichtsrates: Prof. Dr. Helmut Thoma
Vorstand: Eckhard Spoerr (Vors.), Axel Krieger, Stephan
Esch, Eric Berger
Sitz: Büdelsdorf
Amtsgericht Kiel HRB 7306 KI

On Aug 27 2007 14:08, Sebastian Classen wrote:
>
>The ROUTE targe seems to be finaly gone from pom-ng and
we need a
>solution for the --tee function. So I deciced to use
some parts from the
>ROUTE target, adaped the code to the current kernel and
implmemented a
>new taget called TEE. The only function is packet
duplication and those
>duplicate packets are routed the the given gateway (--gw
option).
>
>We use this as a replacement for netwrk traffic taps,
the syntax is:
>itpables -t mangle -A PREROUTING -p tcp --sport
<some-port> -j TEE --gw
><IP.of.mirror.box>
>
>Is there any chance getting this into pom-ng?

Here is an updated version first that uses xt:

	h
ttp://dev.computergmbh.de/wsvn/misc_kernel/xt_TEE/

it's not entirely POM-conformant, since, well, if a module
is good 
enough to go to POM, it is likely good enough to go into
mainline too.


A few questions:

* Is --gw 0.0.0.0 even supported/meaningful? It seems not,
so some 
  checks could be removed.
* Your route_gw() function returns something, but you do not
really use the
  result. Is this intended?




	Jan
-- 

Am Montag, den 27.08.2007, 16:21 +0200 schrieb Jan
Engelhardt:
> On Aug 27 2007 14:08, Sebastian Classen wrote:
> >
> >The ROUTE targe seems to be finaly gone from pom-ng
and we need a
> >solution for the --tee function. So I deciced to
use some parts from the
> >ROUTE target, adaped the code to the current kernel
and implmemented a
> >new taget called TEE. The only function is packet
duplication and those
> >duplicate packets are routed the the given gateway
(--gw option).
> >
> >We use this as a replacement for netwrk traffic
taps, the syntax is:
> >itpables -t mangle -A PREROUTING -p tcp --sport
<some-port> -j TEE --gw
> ><IP.of.mirror.box>
> >
> >Is there any chance getting this into pom-ng?
> 
> Here is an updated version first that uses xt:
> 
> 	h
ttp://dev.computergmbh.de/wsvn/misc_kernel/xt_TEE/

Thanks for this one, will have a closer look at it tomorow
;)

> it's not entirely POM-conformant, since, well, if a
module is good 
> enough to go to POM, it is likely good enough to go
into mainline too.
> 
> 
> A few questions:
> 
> * Is --gw 0.0.0.0 even supported/meaningful? It seems
not, so some 
>   checks could be removed.

No, theres no special meaning. I don't know which checks u
mean.

> * Your route_gw() function returns something, but you
do not really use the
>   result. Is this intended?

You are right, the value is not used anywhere, that's a left
over from
previous ROUTE target. Also the comment above route() does
mention a no
longer used return code.

Greets
  Sebastian.

-- 
Sebastian Claßen
Postmaster
------------------------------------------------------------
----------
Telefon: + 49 (0) 211 53087 522
Telefax: + 49 (0) 211 5381573
E-Mail:  sebastian.classenfreenet.ag
Website: www.freenet.de; www.mobilcom.de
------------------------------------------------------------
----------
freenet AG
Willstätterstr. 13
40549 Düsseldorf
------------------------------------------------------------
----------
Vorsitzender des Aufsichtsrates: Prof. Dr. Helmut Thoma
Vorstand: Eckhard Spoerr (Vors.), Axel Krieger, Stephan
Esch, Eric
Berger
Sitz: Büdelsdorf
Amtsgericht Kiel HRB 7306 KI

Jan Engelhardt wrote:
> On Aug 29 2007 21:03, Patrick McHardy wrote:
>> Please don't post gzipped patches (Sebastian) or
links if the
>> patch isn't excessively large. I don't look at
these things,
>> and I suspect a lot of others neither.
> 
> I hope you don't require unidiff patches in this stage.
It's just
> additionss anyway. Of course, if you'd like one, I
create one,
> for a git tree of your choice. Posted code below is for
2.6.22.


Thanks, just the file is fine.

>  * RETURN: -1 if an error occured
>  *          1 if the packet was succesfully routed to
the 
>  *            destination desired
>  *          0 if the kernel routing table could not
route the packet
>  *            according to the keys specified
>  */
> static int route(struct sk_buff *skb,
>                  const struct xt_TEE_info *info)
...
> 	/* Trying to route the packet using the standard
routing table. */
> 	if ((err = ip_route_output_key(&rt, &fl)) !=
0) {
> 		if (net_ratelimit()) 
> 			pr_debug(KBUILD_MODNAME
> 			         "could not route pkt (err: %d)",
err);
> 		return -1;
> 	}

Comment does not match behaviour. Suggest to change comment,
and make
function return 0/1 only.

> static inline void route_gw(const struct xt_TEE_info
*info, struct sk_buff *skb) 
> {
> 	if (route(skb, info) != 1)
> 		return;
> 	ip_direct_send(skb);
> }

Too small, and only called once, to warrant being a
function.

> 	/*
> 	 * If we are at PREROUTING or INPUT hook,
> 	 * the TTL is not decreased by the IP stack
> 	 */
> 	if (hooknum == NF_IP_PRE_ROUTING || hooknum ==
NF_IP_LOCAL_IN) {
...
> 		if (iph->ttl <= 1) {
...

I believe this case (the whole synthesizing an
ICMP_TIME_EXCEEDED) is not
neccessary for TEE.

The code is working on the original skb. With ROUTE, the
logic was that
the skb would be dropped soon due to exceeding TTL, and if
we reroute
and send directly now, that wouldn't happen.

With TEE (as well as the previous ROUTE --tee option), the
original
packet is not rerouted, and ICMP_TIME_EXCEEDED should be
generated
for it as usual. Right?

That would leave two questions:

Should we skb_copy+route for the above quoted conditions,
i.e. hook
PRE_ROUTING/LOCAL_IN and skb->ttl <= 1, although the
tee'd packet will
be dropped soon?

And if we decide to tee the packet regardless of the ttl
condition,
should the ttl be decremented after skb_copy on the teed
packet,
or not?

My gut feeling is to remove all ttl handling, and let the
next hop of
the teed packet handle ttl as if it were the original
recipient,
instead of our tee pot.

best regards
  Patrick

Am Donnerstag, den 13.09.2007, 09:37 +0200 schrieb Sebastian
Classen:
> I would also suggest to remove TTL handling completly
and already did
> so. Find the new xt_TEE.c attached.
> 
> Jan: Could you please add the new version to your SVN
repository.
> Thanks.
> 

Sorry, I forgot a pair of braces. Find corrected version
attached.

Sebastian.

-- 
Mit freundlichen Grüßen / Yours sincerely

Sebastian Claßen
Postmaster
------------------------------------------------------------
----------
Telefon: + 49 (0) 211 53087 522
Telefax: + 49 (0) 211 5381573
E-Mail:  sebastian.classenfreenet.ag
Website: www.freenet.de; www.mobilcom.de
------------------------------------------------------------
----------
freenet AG
Willstätterstr. 13
40549 Düsseldorf
------------------------------------------------------------
----------
Vorsitzender des Aufsichtsrates: Prof. Dr. Helmut Thoma
Vorstand: Eckhard Spoerr (Vors.), Axel Krieger, Stephan
Esch, Eric Berger
Sitz: Büdelsdorf
Amtsgericht Kiel HRB 7306 KI