From: Konstantinos Agouros on
Hi,

I have a setup where I do policy routing based on a mangle-table with
ip rule fwmark. This worked until 2.6.30 with 2.6.31 ip rule does work
eg with a source address
ip rule from 1.2.3.4 lookup 1
but not with
ip rule from all fwmark 0x01 lookup 1
The problem is, that the answer packets are dropped. I use CONNMARK in the
iptables rules. Anybody has an idea if there was a change from 2.6.30 to
2.6.31?

Konstantin
--
Dipl-Inf. Konstantin Agouros aka Elwood Blues. Internet: elwood(a)agouros.de
Altersheimerstr. 1, 81545 Muenchen, Germany. Tel +49 89 69370185
----------------------------------------------------------------------------
"Captain, this ship will not survive the forming of the cosmos." B'Elana Torres
From: Pascal Hambourg on
Hello,

Konstantinos Agouros a �crit :
>
> I have a setup where I do policy routing based on a mangle-table with
> ip rule fwmark. This worked until 2.6.30 with 2.6.31 ip rule does work
> eg with a source address
> ip rule from 1.2.3.4 lookup 1
> but not with
> ip rule from all fwmark 0x01 lookup 1
> The problem is, that the answer packets are dropped. I use CONNMARK in the
> iptables rules. Anybody has an idea if there was a change from 2.6.30 to
> 2.6.31?

Maybe you have been hit by the same as this :
<http://www.spinics.net/lists/netfilter/msg47119.html>

If reverse path filtering is enabled (sysctl
net.ipv4.conf.<interface>.rp_filter=1), try to disable it for both "all"
and the involved interfaces.
From: Konstantinos Agouros on
In <hgo23i$2ssv$1(a)saria.nerim.net> Pascal Hambourg <boite-a-spam(a)plouf.fr.eu.org> writes:

>Hello,

>Konstantinos Agouros a �crit :
>>
>> I have a setup where I do policy routing based on a mangle-table with
>> ip rule fwmark. This worked until 2.6.30 with 2.6.31 ip rule does work
>> eg with a source address
>> ip rule from 1.2.3.4 lookup 1
>> but not with
>> ip rule from all fwmark 0x01 lookup 1
>> The problem is, that the answer packets are dropped. I use CONNMARK in the
>> iptables rules. Anybody has an idea if there was a change from 2.6.30 to
>> 2.6.31?

>Maybe you have been hit by the same as this :
><http://www.spinics.net/lists/netfilter/msg47119.html>

>If reverse path filtering is enabled (sysctl
>net.ipv4.conf.<interface>.rp_filter=1), try to disable it for both "all"
>and the involved interfaces.
I already fell back to 2.6.30 but will try in a VM if this is the issue
but it would make perfect sense, as the behaviour described in the link
matches perfectly what I have seen here. Was there a change in 2.6.31
on the default setting of this parameter?

Konstantin
--
Dipl-Inf. Konstantin Agouros aka Elwood Blues. Internet: elwood(a)agouros.de
Altersheimerstr. 1, 81545 Muenchen, Germany. Tel +49 89 69370185
----------------------------------------------------------------------------
"Captain, this ship will not survive the forming of the cosmos." B'Elana Torres
From: Pascal Hambourg on
Konstantinos Agouros a �crit :
>
>> <http://www.spinics.net/lists/netfilter/msg47119.html>
>
>> If reverse path filtering is enabled (sysctl
>> net.ipv4.conf.<interface>.rp_filter=1), try to disable it for both "all"
>> and the involved interfaces.
>
> I already fell back to 2.6.30 but will try in a VM if this is the issue
> but it would make perfect sense, as the behaviour described in the link
> matches perfectly what I have seen here. Was there a change in 2.6.31
> on the default setting of this parameter?

Not AFAIK. But some distribution startup scripts may modify it, e.g.
through /etc/sysctl.conf (as a remainder, note that the current value
and changes of net.ipv4.conf.default.rp_filter are applied to newly
created and existing inactive, i.e. not UP, interfaces).

As I wrote in the last message of the thread, the change was in the way
net.ipv4.conf.<interface>.rp_filter and net.ipv4.conf.all.rp_filter are
combined to produce the functional value. It was a logical AND,
requiring that both are set to enable the feature on <interface>, and
became an arithmetic MAX, requiring that either is set to enable the
feature on <interface>. As a result, if only one is set, then changing
from kernel 2.6.30 to kernel 2.6.31 changes the functional behaviour.