Mailing List Archive

On Jul 30 2007 16:42, Ludovic wrote:
>Hi guys,
>
>sorry if there is already some patches about this but i've searched
>one week how to make the ROUTE target work well.
>
>Here are two patches (one for ipv4 and one for ipv6) which change
>ipt_register and ipt_unregister to xt_register and xt_unregister and
>which add .family = AF_INET in the xt_target structure declaration.

Somehow this feels like déjà-vu. ipt_ROUTE is, well, a hack
and the proper solution to it is policy routing; e.g. based on fwmark.


Jan
--

Jan Engelhardt wrote:
> On Jul 30 2007 16:42, Ludovic wrote:
>
>>sorry if there is already some patches about this but i've searched
>>one week how to make the ROUTE target work well.
>>
>>Here are two patches (one for ipv4 and one for ipv6) which change
>>ipt_register and ipt_unregister to xt_register and xt_unregister and
>>which add .family = AF_INET in the xt_target structure declaration.
>
>
> Somehow this feels like déjà-vu. ipt_ROUTE is, well, a hack
> and the proper solution to it is policy routing; e.g. based on fwmark.


Fully agreed (well, I made that argument for ages), I think we
should simply remove it from pomng to avoid misleading users
into thinking it would be the proper way to do things.

On Jul 30 2007 16:47, Patrick McHardy wrote:
>Jan Engelhardt wrote:
>> On Jul 30 2007 16:42, Ludovic wrote:
>>
>>>sorry if there is already some patches about this but i've searched
>>>one week how to make the ROUTE target work well.
>>>
>>>Here are two patches (one for ipv4 and one for ipv6) which change
>>>ipt_register and ipt_unregister to xt_register and xt_unregister and
>>>which add .family = AF_INET in the xt_target structure declaration.
>>
>>
>> Somehow this feels like déjà-vu. ipt_ROUTE is, well, a hack
>> and the proper solution to it is policy routing; e.g. based on fwmark.
>
>
>Fully agreed (well, I made that argument for ages), I think we
>should simply remove it from pomng to avoid misleading users
>into thinking it would be the proper way to do things.
>
I second that idea.


Jan
--

Jan Engelhardt wrote:
> On Jul 30 2007 16:47, Patrick McHardy wrote:
>
>>Fully agreed (well, I made that argument for ages), I think we
>>should simply remove it from pomng to avoid misleading users
>>into thinking it would be the proper way to do things.
>>
>
> I second that idea.


Its gone now ..

On Mon, 30 Jul 2007, Patrick McHardy wrote:

> Jan Engelhardt wrote:
>> On Jul 30 2007 16:47, Patrick McHardy wrote:
>>
>>> Fully agreed (well, I made that argument for ages), I think we
>>> should simply remove it from pomng to avoid misleading users
>>> into thinking it would be the proper way to do things.
>>>
>>
>> I second that idea.
>
>
> Its gone now ..

1. ROUTE has a very usefull option --tee. AFAIK it is not possible to do
it other way.
2. Policy routing based on fwmark is not always an option if you use
marks for other purposes.

So, if it is going to be removed from pom-ng I would like to keep it in my
external pomng-repository.

Best regards,


Krzysztof Olêdzki

Krzysztof Oledzki wrote:
> 1. ROUTE has a very usefull option --tee. AFAIK it is not possible to do
> it other way.


Thats true. Not sure in what practical situation it is used though.

> 2. Policy routing based on fwmark is not always an option if you use
> marks for other purposes.


Maybe (trying to avoid getting into discussion about too small mark
values again :)).

> So, if it is going to be removed from pom-ng I would like to keep it in
> my external pomng-repository.


Please go ahead.

Just FYI: One more reason for removing it is that its broken wrt.
IPsec handling and the duplicated functions from ip_output are out
of sync (and I think there were a few smaller problems as well).
If there really is a need for something like the tee functionality
I'm not opposed to considering merging a clean patch without these
problems for that.

> > 1. ROUTE has a very usefull option --tee. AFAIK it is not possible to do
> > it other way.
>
> Thats true. Not sure in what practical situation it is used though.

iptables -A INPUT -p tcp --dport 25 -j ROUTE --tee --gw lawful.inspection.box

In other words: network traffic taps.

If the feature is removed from POM, I'll probably be forced by
colleagues to maintain it in some other form. Sigh.

best regards
Patrick

Patrick Schaaf wrote:
>>>1. ROUTE has a very usefull option --tee. AFAIK it is not possible to do
>>>it other way.
>>
>>Thats true. Not sure in what practical situation it is used though.
>
>
> iptables -A INPUT -p tcp --dport 25 -j ROUTE --tee --gw lawful.inspection.box
>
> In other words: network traffic taps.


Yeah, I was already thinking of that, but bonding allows to do
that on a per-device base. Not sure if that helps ..

> If the feature is removed from POM, I'll probably be forced by
> colleagues to maintain it in some other form. Sigh.

Krzysztof expressed interest in maintaining it ..

On Mon, 30 Jul 2007, Patrick McHardy wrote:

> Krzysztof Oledzki wrote:
>> 1. ROUTE has a very usefull option --tee. AFAIK it is not possible to do
>> it other way.
>
>
> Thats true. Not sure in what practical situation it is used though.
>
>> 2. Policy routing based on fwmark is not always an option if you use
>> marks for other purposes.
>
>
> Maybe (trying to avoid getting into discussion about too small mark
> values again :)).
>
>> So, if it is going to be removed from pom-ng I would like to keep it in
>> my external pomng-repository.
>
>
> Please go ahead.

So I added it to my pom-ng repository for now, with fixes for
2.6.21/2.6.22.

> Just FYI: One more reason for removing it is that its broken wrt.
> IPsec handling

Could you explain it a bit? What is wrong and maybe some clue how it
should be fixed?

> and the duplicated functions from ip_output are out
> of sync

OK, found it. This is a easy part to fix. :)

> (and I think there were a few smaller problems as well).

For example?

> If there really is a need for something like the tee functionality
> I'm not opposed to considering merging a clean patch without these
> problems for that.

OK. I'll do my best. :)

Best regards,

Krzysztof Olêdzki

On Aug 29 2007 13:23, Krzysztof Oledzki wrote:
>
>> Just FYI: One more reason for removing it is that its broken wrt.
>> IPsec handling
>
> Could you explain it a bit? What is wrong and maybe some clue how it should be
> fixed?

ip_direct_send does not do IPSEC IIRC.


Jan
--

On Wed, 29 Aug 2007, Jan Engelhardt wrote:

>
> On Aug 29 2007 13:23, Krzysztof Oledzki wrote:
>>
>>> Just FYI: One more reason for removing it is that its broken wrt.
>>> IPsec handling
>>
>> Could you explain it a bit? What is wrong and maybe some clue how it should be
>> fixed?
>
> ip_direct_send does not do IPSEC IIRC.

Neither ip_finish_output2 which is a place from this code comes from.
Anyway, I found that indeed ip_finish_output, which calls
ip_finish_output2, contains xfrm code:

#if defined(CONFIG_NETFILTER) && defined(CONFIG_XFRM)
/* Policy lookup after SNAT yielded a new policy */
if (skb->dst->xfrm != NULL) {
IPCB(skb)->flags |= IPSKB_REROUTED;
return dst_output(skb);
}
#endif

Is that all?

So, how it should work with ROUTE? I assume that teed packets shouldn't
go via xfrm, neither directly (--gw, --oif) routed packets if there is no
tee, right?

Best regards,

Krzysztof Olêdzki

Krzysztof Oledzki wrote:
> On Wed, 29 Aug 2007, Jan Engelhardt wrote:
>
>>
>> On Aug 29 2007 13:23, Krzysztof Oledzki wrote:
>>>
>>>> Just FYI: One more reason for removing it is that its broken wrt.
>>>> IPsec handling
>>>
>>> Could you explain it a bit? What is wrong and maybe some clue how it
>>> should be
>>> fixed?
>>
>> [...]
>
> Is that all?


Can you point me to the latest source please?

On Aug 30 2007 08:46, Patrick McHardy wrote:
>> > > > Just FYI: One more reason for removing it is that its broken wrt.
>> > > > IPsec handling
>> > >
>> > > Could you explain it a bit? What is wrong and maybe some clue how it
>> > > should be
>> > > fixed?
>> >
>> > [...]
>>
>> Is that all?
>
> Can you point me to the latest source please?
>
See the xt_TEE thread; the mail with the plain files I sent.



Jan
--