From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: ipv4 regression in 2.6.31 ?
Date: Mon, 14 Sep 2009 15:57:03 +0200
Message-ID: <4AAE4BAF.2010406@gmail.com>
References: <20090914150935.cc895a3c.skraw@ithnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: linux-kernel@vger.kernel.org, davem@davemloft.net,
	Linux Netdev List <netdev@vger.kernel.org>
To: Stephan von Krawczynski <skraw@ithnet.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from gw1.cosmosbay.com ([212.99.114.194]:50915 "EHLO
	gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753000AbZINN5G (ORCPT
	<rfc822;netdev@vger.kernel.org>); Mon, 14 Sep 2009 09:57:06 -0400
In-Reply-To: <20090914150935.cc895a3c.skraw@ithnet.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

Stephan von Krawczynski a =E9crit :
> Hello all,
>=20
> today we experienced some sort of regression in 2.6.31 ipv4 implement=
ation, or
> at least some incompatibility with former 2.6.30.X kernels.
>=20
> We have the following situation:
>=20
>                                        ---------- vlan1@eth0 192.168.=
2.1/24
>                                       /
> host A 192.168.1.1/24 eth0  -------<router>            host B
>                                       \
>                                        ---------- eth1 192.168.3.1/24
>=20
>=20
> Now, if you route 192.168.1.0/24 via interface vlan1@eth0 on host B a=
nd let
> host A ping 192.168.2.1 everything works. But if you route 192.168.1.=
0/24 via
> interface eth1 on host B and let host A ping 192.168.2.1 you get no r=
eply.
> With tcpdump we see the icmp packets arrive at vlan1@eth0, but no icm=
p echo
> reply being generated neither on vlan1 nor eth1.
> Kernels 2.6.30.X and below do not show this behaviour.
> Is this intended? Do we need to reconfigure something to restore the =
old
> behaviour?
>=20

Asymetric routing ?

Check your rp_filter settings

grep . `find /proc/sys/net -name rp_filter`

rp_filter - INTEGER
        0 - No source validation.
        1 - Strict mode as defined in RFC3704 Strict Reverse Path
            Each incoming packet is tested against the FIB and if the i=
nterface
            is not the best reverse path the packet check will fail.
            By default failed packets are discarded.
        2 - Loose mode as defined in RFC3704 Loose Reverse Path
            Each incoming packet's source address is also tested agains=
t the FIB
            and if the source address is not reachable via any interfac=
e
            the packet check will fail.

        Current recommended practice in RFC3704 is to enable strict mod=
e
        to prevent IP spoofing from DDos attacks. If using asymmetric r=
outing
        or other complicated routing, then loose mode is recommended.

        conf/all/rp_filter must also be set to non-zero to do source va=
lidation
        on the interface

        Default value is 0. Note that some distributions enable it
        in startup scripts.



From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephan von Krawczynski <skraw@ithnet.com>
Subject: Re: ipv4 regression in 2.6.31 ?
Date: Mon, 14 Sep 2009 17:10:01 +0200
Message-ID: <20090914171001.47371b3d.skraw@ithnet.com>
References: <20090914150935.cc895a3c.skraw@ithnet.com>
	<4AAE4BAF.2010406@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: linux-kernel@vger.kernel.org, davem@davemloft.net,
	Linux Netdev List <netdev@vger.kernel.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Return-path: <linux-kernel-owner+glk-linux-kernel-3=40m.gmane.org-S1755825AbZINPO3@vger.kernel.org>
In-Reply-To: <4AAE4BAF.2010406@gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: netdev.vger.kernel.org

On Mon, 14 Sep 2009 15:57:03 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> Stephan von Krawczynski a =E9crit :
> > Hello all,
> >=20
> > today we experienced some sort of regression in 2.6.31 ipv4 impleme=
ntation, or
> > at least some incompatibility with former 2.6.30.X kernels.
> >=20
> > We have the following situation:
> >=20
> >                                        ---------- vlan1@eth0 192.16=
8.2.1/24
> >                                       /
> > host A 192.168.1.1/24 eth0  -------<router>            host B
> >                                       \
> >                                        ---------- eth1 192.168.3.1/=
24
> >=20
> >=20
> > Now, if you route 192.168.1.0/24 via interface vlan1@eth0 on host B=
 and let
> > host A ping 192.168.2.1 everything works. But if you route 192.168.=
1.0/24 via
> > interface eth1 on host B and let host A ping 192.168.2.1 you get no=
 reply.
> > With tcpdump we see the icmp packets arrive at vlan1@eth0, but no i=
cmp echo
> > reply being generated neither on vlan1 nor eth1.
> > Kernels 2.6.30.X and below do not show this behaviour.
> > Is this intended? Do we need to reconfigure something to restore th=
e old
> > behaviour?
> >=20
>=20
> Asymetric routing ?
>=20
> Check your rp_filter settings
>=20
> grep . `find /proc/sys/net -name rp_filter`
>=20
> rp_filter - INTEGER
>         0 - No source validation.
>         1 - Strict mode as defined in RFC3704 Strict Reverse Path
>             Each incoming packet is tested against the FIB and if the=
 interface
>             is not the best reverse path the packet check will fail.
>             By default failed packets are discarded.
>         2 - Loose mode as defined in RFC3704 Loose Reverse Path
>             Each incoming packet's source address is also tested agai=
nst the FIB
>             and if the source address is not reachable via any interf=
ace
>             the packet check will fail.
>=20
>         Current recommended practice in RFC3704 is to enable strict m=
ode
>         to prevent IP spoofing from DDos attacks. If using asymmetric=
 routing
>         or other complicated routing, then loose mode is recommended.
>=20
>         conf/all/rp_filter must also be set to non-zero to do source =
validation
>         on the interface
>=20
>         Default value is 0. Note that some distributions enable it
>         in startup scripts.

Problem is this:
Kernel 2.6.30.X and below work flawlessly in this setup, only kernel 2.=
6.31
acts different. Is this an intended change in policy?

--=20
Regards,
Stephan

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: ipv4 regression in 2.6.31 ?
Date: Mon, 14 Sep 2009 17:21:18 +0200
Message-ID: <4AAE5F6E.3030008@gmail.com>
References: <20090914150935.cc895a3c.skraw@ithnet.com>	<4AAE4BAF.2010406@gmail.com> <20090914171001.47371b3d.skraw@ithnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: linux-kernel@vger.kernel.org, davem@davemloft.net,
	Linux Netdev List <netdev@vger.kernel.org>
To: Stephan von Krawczynski <skraw@ithnet.com>
Return-path: <linux-kernel-owner+glk-linux-kernel-3=40m.gmane.org-S1755424AbZINPVW@vger.kernel.org>
In-Reply-To: <20090914171001.47371b3d.skraw@ithnet.com>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: netdev.vger.kernel.org

Stephan von Krawczynski a =E9crit :
> On Mon, 14 Sep 2009 15:57:03 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>=20
>> Stephan von Krawczynski a =E9crit :
>>> Hello all,
>>>
>>> today we experienced some sort of regression in 2.6.31 ipv4 impleme=
ntation, or
>>> at least some incompatibility with former 2.6.30.X kernels.
>>>
>>> We have the following situation:
>>>
>>>                                        ---------- vlan1@eth0 192.16=
8.2.1/24
>>>                                       /
>>> host A 192.168.1.1/24 eth0  -------<router>            host B
>>>                                       \
>>>                                        ---------- eth1 192.168.3.1/=
24
>>>
>>>
>>> Now, if you route 192.168.1.0/24 via interface vlan1@eth0 on host B=
 and let
>>> host A ping 192.168.2.1 everything works. But if you route 192.168.=
1.0/24 via
>>> interface eth1 on host B and let host A ping 192.168.2.1 you get no=
 reply.
>>> With tcpdump we see the icmp packets arrive at vlan1@eth0, but no i=
cmp echo
>>> reply being generated neither on vlan1 nor eth1.
>>> Kernels 2.6.30.X and below do not show this behaviour.
>>> Is this intended? Do we need to reconfigure something to restore th=
e old
>>> behaviour?
>>>
>> Asymetric routing ?
>>
>> Check your rp_filter settings
>>
>> grep . `find /proc/sys/net -name rp_filter`
>>
>> rp_filter - INTEGER
>>         0 - No source validation.
>>         1 - Strict mode as defined in RFC3704 Strict Reverse Path
>>             Each incoming packet is tested against the FIB and if th=
e interface
>>             is not the best reverse path the packet check will fail.
>>             By default failed packets are discarded.
>>         2 - Loose mode as defined in RFC3704 Loose Reverse Path
>>             Each incoming packet's source address is also tested aga=
inst the FIB
>>             and if the source address is not reachable via any inter=
face
>>             the packet check will fail.
>>
>>         Current recommended practice in RFC3704 is to enable strict =
mode
>>         to prevent IP spoofing from DDos attacks. If using asymmetri=
c routing
>>         or other complicated routing, then loose mode is recommended=
=2E
>>
>>         conf/all/rp_filter must also be set to non-zero to do source=
 validation
>>         on the interface
>>
>>         Default value is 0. Note that some distributions enable it
>>         in startup scripts.
>=20
> Problem is this:
> Kernel 2.6.30.X and below work flawlessly in this setup, only kernel =
2.6.31
> acts different. Is this an intended change in policy?
>=20

Here, it only depends on rp_filter settings, kernel 2.6.30 or 2.6.31

Please give your settings for further investigations, for all hosts inv=
olved.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephan von Krawczynski <skraw@ithnet.com>
Subject: Re: ipv4 regression in 2.6.31 ?
Date: Mon, 14 Sep 2009 17:55:05 +0200
Message-ID: <20090914175505.a3f132ee.skraw@ithnet.com>
References: <20090914150935.cc895a3c.skraw@ithnet.com>
	<4AAE4BAF.2010406@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: linux-kernel@vger.kernel.org, davem@davemloft.net,
	Linux Netdev List <netdev@vger.kernel.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Return-path: <linux-kernel-owner+glk-linux-kernel-3=40m.gmane.org-S1755886AbZINPzM@vger.kernel.org>
In-Reply-To: <4AAE4BAF.2010406@gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: netdev.vger.kernel.org

On Mon, 14 Sep 2009 15:57:03 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:

> Stephan von Krawczynski a =E9crit :
> > Hello all,
> >=20
> > today we experienced some sort of regression in 2.6.31 ipv4 impleme=
ntation, or
> > at least some incompatibility with former 2.6.30.X kernels.
> >=20
> > We have the following situation:
> >=20
> >                                        ---------- vlan1@eth0 192.16=
8.2.1/24
> >                                       /
> > host A 192.168.1.1/24 eth0  -------<router>            host B
> >                                       \
> >                                        ---------- eth1 192.168.3.1/=
24
> >=20
> >=20
> > Now, if you route 192.168.1.0/24 via interface vlan1@eth0 on host B=
 and let
> > host A ping 192.168.2.1 everything works. But if you route 192.168.=
1.0/24 via
> > interface eth1 on host B and let host A ping 192.168.2.1 you get no=
 reply.
> > With tcpdump we see the icmp packets arrive at vlan1@eth0, but no i=
cmp echo
> > reply being generated neither on vlan1 nor eth1.
> > Kernels 2.6.30.X and below do not show this behaviour.
> > Is this intended? Do we need to reconfigure something to restore th=
e old
> > behaviour?
> >=20
>=20
> Asymetric routing ?
>=20
> Check your rp_filter settings
>=20
> grep . `find /proc/sys/net -name rp_filter`
>=20
> rp_filter - INTEGER
>         0 - No source validation.
>         1 - Strict mode as defined in RFC3704 Strict Reverse Path
>             Each incoming packet is tested against the FIB and if the=
 interface
>             is not the best reverse path the packet check will fail.
>             By default failed packets are discarded.
>         2 - Loose mode as defined in RFC3704 Loose Reverse Path
>             Each incoming packet's source address is also tested agai=
nst the FIB
>             and if the source address is not reachable via any interf=
ace
>             the packet check will fail.
>=20
>         Current recommended practice in RFC3704 is to enable strict m=
ode
>         to prevent IP spoofing from DDos attacks. If using asymmetric=
 routing
>         or other complicated routing, then loose mode is recommended.
>=20
>         conf/all/rp_filter must also be set to non-zero to do source =
validation
>         on the interface
>=20
>         Default value is 0. Note that some distributions enable it
>         in startup scripts.

Ok, here you can see 2.6.31 values from the discussed box:
(remember, no ping reply in this setup)

/proc/sys/net/ipv4/conf/all/rp_filter:1
/proc/sys/net/ipv4/conf/default/rp_filter:0
/proc/sys/net/ipv4/conf/lo/rp_filter:0
/proc/sys/net/ipv4/conf/eth2/rp_filter:0
/proc/sys/net/ipv4/conf/eth0/rp_filter:0
/proc/sys/net/ipv4/conf/eth1/rp_filter:0
/proc/sys/net/ipv4/conf/vlan1/rp_filter:0


And these are from the same box with 2.6.30.5:
(ping reply works)

/proc/sys/net/ipv4/conf/all/rp_filter:1
/proc/sys/net/ipv4/conf/default/rp_filter:0
/proc/sys/net/ipv4/conf/lo/rp_filter:0
/proc/sys/net/ipv4/conf/eth2/rp_filter:0
/proc/sys/net/ipv4/conf/eth0/rp_filter:0
/proc/sys/net/ipv4/conf/eth1/rp_filter:0
/proc/sys/net/ipv4/conf/vlan1/rp_filter:0

As you can see they're all the same. Does this mean that rp_filter neve=
r
really worked as intended before 2.6.31 ? Or does it mean that rp_filte=
r=3D0
(eth1 and vlan1) gets overriden by all/rp_filter=3D1 in 2.6.31 and not =
before?

--
Regards,
Stephan

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eric Dumazet <eric.dumazet@gmail.com>
Subject: Re: ipv4 regression in 2.6.31 ?
Date: Mon, 14 Sep 2009 18:10:21 +0200
Message-ID: <4AAE6AED.1070609@gmail.com>
References: <20090914150935.cc895a3c.skraw@ithnet.com>	<4AAE4BAF.2010406@gmail.com> <20090914175505.a3f132ee.skraw@ithnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Stephen Hemminger <shemminger@vyatta.com>,
	linux-kernel@vger.kernel.org, davem@davemloft.net,
	Linux Netdev List <netdev@vger.kernel.org>
To: Stephan von Krawczynski <skraw@ithnet.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from gw1.cosmosbay.com ([212.99.114.194]:39473 "EHLO
	gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751078AbZINQKY (ORCPT
	<rfc822;netdev@vger.kernel.org>); Mon, 14 Sep 2009 12:10:24 -0400
In-Reply-To: <20090914175505.a3f132ee.skraw@ithnet.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

Stephan von Krawczynski a =E9crit :
> On Mon, 14 Sep 2009 15:57:03 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>=20
>> Stephan von Krawczynski a =E9crit :
>>> Hello all,
>>>
>>> today we experienced some sort of regression in 2.6.31 ipv4 impleme=
ntation, or
>>> at least some incompatibility with former 2.6.30.X kernels.
>>>
>>> We have the following situation:
>>>
>>>                                        ---------- vlan1@eth0 192.16=
8.2.1/24
>>>                                       /
>>> host A 192.168.1.1/24 eth0  -------<router>            host B
>>>                                       \
>>>                                        ---------- eth1 192.168.3.1/=
24
>>>
>>>
>>> Now, if you route 192.168.1.0/24 via interface vlan1@eth0 on host B=
 and let
>>> host A ping 192.168.2.1 everything works. But if you route 192.168.=
1.0/24 via
>>> interface eth1 on host B and let host A ping 192.168.2.1 you get no=
 reply.
>>> With tcpdump we see the icmp packets arrive at vlan1@eth0, but no i=
cmp echo
>>> reply being generated neither on vlan1 nor eth1.
>>> Kernels 2.6.30.X and below do not show this behaviour.
>>> Is this intended? Do we need to reconfigure something to restore th=
e old
>>> behaviour?
>>>
>> Asymetric routing ?
>>
>> Check your rp_filter settings
>>
>> grep . `find /proc/sys/net -name rp_filter`
>>
>> rp_filter - INTEGER
>>         0 - No source validation.
>>         1 - Strict mode as defined in RFC3704 Strict Reverse Path
>>             Each incoming packet is tested against the FIB and if th=
e interface
>>             is not the best reverse path the packet check will fail.
>>             By default failed packets are discarded.
>>         2 - Loose mode as defined in RFC3704 Loose Reverse Path
>>             Each incoming packet's source address is also tested aga=
inst the FIB
>>             and if the source address is not reachable via any inter=
face
>>             the packet check will fail.
>>
>>         Current recommended practice in RFC3704 is to enable strict =
mode
>>         to prevent IP spoofing from DDos attacks. If using asymmetri=
c routing
>>         or other complicated routing, then loose mode is recommended=
=2E
>>
>>         conf/all/rp_filter must also be set to non-zero to do source=
 validation
>>         on the interface
>>
>>         Default value is 0. Note that some distributions enable it
>>         in startup scripts.
>=20
> Ok, here you can see 2.6.31 values from the discussed box:
> (remember, no ping reply in this setup)
>=20
> /proc/sys/net/ipv4/conf/all/rp_filter:1
> /proc/sys/net/ipv4/conf/default/rp_filter:0
> /proc/sys/net/ipv4/conf/lo/rp_filter:0
> /proc/sys/net/ipv4/conf/eth2/rp_filter:0
> /proc/sys/net/ipv4/conf/eth0/rp_filter:0
> /proc/sys/net/ipv4/conf/eth1/rp_filter:0
> /proc/sys/net/ipv4/conf/vlan1/rp_filter:0
>=20
>=20
> And these are from the same box with 2.6.30.5:
> (ping reply works)
>=20
> /proc/sys/net/ipv4/conf/all/rp_filter:1
> /proc/sys/net/ipv4/conf/default/rp_filter:0
> /proc/sys/net/ipv4/conf/lo/rp_filter:0
> /proc/sys/net/ipv4/conf/eth2/rp_filter:0
> /proc/sys/net/ipv4/conf/eth0/rp_filter:0
> /proc/sys/net/ipv4/conf/eth1/rp_filter:0
> /proc/sys/net/ipv4/conf/vlan1/rp_filter:0
>=20
> As you can see they're all the same. Does this mean that rp_filter ne=
ver
> really worked as intended before 2.6.31 ? Or does it mean that rp_fil=
ter=3D0
> (eth1 and vlan1) gets overriden by all/rp_filter=3D1 in 2.6.31 and no=
t before?
>

Yes, previous kernels ignored /proc/sys/net/ipv4/conf/all/rp_filter val=
ue, it was a bug.

commit 27fed4175acf81ddd91d9a4ee2fd298981f60295
Author: Stephen Hemminger <shemminger@vyatta.com>
Date:   Mon Jul 27 18:39:45 2009 -0700

    ip: fix logic of reverse path filter sysctl

    Even though reverse path filter was changed from simple boolean to
    trinary control, the loose mode only works if both all and device a=
re
    configured because of this logic error.

    Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>


In your case, you *need*
echo 0 >/proc/sys/net/ipv4/conf/all/rp_filter
or
echo 2 >/proc/sys/net/ipv4/conf/all/rp_filter


From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <shemminger@vyatta.com>
Subject: Re: ipv4 regression in 2.6.31 ?
Date: Mon, 14 Sep 2009 09:31:28 -0700
Message-ID: <20090914093128.4d709ff6@nehalam>
References: <20090914150935.cc895a3c.skraw@ithnet.com>
	<4AAE4BAF.2010406@gmail.com>
	<20090914175505.a3f132ee.skraw@ithnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
	linux-kernel@vger.kernel.org, davem@davemloft.net,
	Linux Netdev List <netdev@vger.kernel.org>
To: Stephan von Krawczynski <skraw@ithnet.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail.vyatta.com ([76.74.103.46]:36967 "EHLO mail.vyatta.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750867AbZINQbb convert rfc822-to-8bit (ORCPT
	<rfc822;netdev@vger.kernel.org>); Mon, 14 Sep 2009 12:31:31 -0400
In-Reply-To: <20090914175505.a3f132ee.skraw@ithnet.com>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Mon, 14 Sep 2009 17:55:05 +0200
Stephan von Krawczynski <skraw@ithnet.com> wrote:

> On Mon, 14 Sep 2009 15:57:03 +0200
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>=20
> > Stephan von Krawczynski a =C3=A9crit :
> > > Hello all,
> > >=20
> > > today we experienced some sort of regression in 2.6.31 ipv4 imple=
mentation, or
> > > at least some incompatibility with former 2.6.30.X kernels.
> > >=20
> > > We have the following situation:
> > >=20
> > >                                        ---------- vlan1@eth0 192.=
168.2.1/24
> > >                                       /
> > > host A 192.168.1.1/24 eth0  -------<router>            host B
> > >                                       \
> > >                                        ---------- eth1 192.168.3.=
1/24
> > >=20
> > >=20
> > > Now, if you route 192.168.1.0/24 via interface vlan1@eth0 on host=
 B and let
> > > host A ping 192.168.2.1 everything works. But if you route 192.16=
8.1.0/24 via
> > > interface eth1 on host B and let host A ping 192.168.2.1 you get =
no reply.
> > > With tcpdump we see the icmp packets arrive at vlan1@eth0, but no=
 icmp echo
> > > reply being generated neither on vlan1 nor eth1.
> > > Kernels 2.6.30.X and below do not show this behaviour.
> > > Is this intended? Do we need to reconfigure something to restore =
the old
> > > behaviour?
> > >=20
> >=20
> > Asymetric routing ?
> >=20
> > Check your rp_filter settings
> >=20
> > grep . `find /proc/sys/net -name rp_filter`
> >=20
> > rp_filter - INTEGER
> >         0 - No source validation.
> >         1 - Strict mode as defined in RFC3704 Strict Reverse Path
> >             Each incoming packet is tested against the FIB and if t=
he interface
> >             is not the best reverse path the packet check will fail=
=2E
> >             By default failed packets are discarded.
> >         2 - Loose mode as defined in RFC3704 Loose Reverse Path
> >             Each incoming packet's source address is also tested ag=
ainst the FIB
> >             and if the source address is not reachable via any inte=
rface
> >             the packet check will fail.
> >=20
> >         Current recommended practice in RFC3704 is to enable strict=
 mode
> >         to prevent IP spoofing from DDos attacks. If using asymmetr=
ic routing
> >         or other complicated routing, then loose mode is recommende=
d.
> >=20
> >         conf/all/rp_filter must also be set to non-zero to do sourc=
e validation
> >         on the interface
> >=20
> >         Default value is 0. Note that some distributions enable it
> >         in startup scripts.
>=20
> Ok, here you can see 2.6.31 values from the discussed box:
> (remember, no ping reply in this setup)
>=20
> /proc/sys/net/ipv4/conf/all/rp_filter:1
> /proc/sys/net/ipv4/conf/default/rp_filter:0
> /proc/sys/net/ipv4/conf/lo/rp_filter:0
> /proc/sys/net/ipv4/conf/eth2/rp_filter:0
> /proc/sys/net/ipv4/conf/eth0/rp_filter:0
> /proc/sys/net/ipv4/conf/eth1/rp_filter:0
> /proc/sys/net/ipv4/conf/vlan1/rp_filter:0
>=20
>=20
> And these are from the same box with 2.6.30.5:
> (ping reply works)
>=20
> /proc/sys/net/ipv4/conf/all/rp_filter:1
> /proc/sys/net/ipv4/conf/default/rp_filter:0
> /proc/sys/net/ipv4/conf/lo/rp_filter:0
> /proc/sys/net/ipv4/conf/eth2/rp_filter:0
> /proc/sys/net/ipv4/conf/eth0/rp_filter:0
> /proc/sys/net/ipv4/conf/eth1/rp_filter:0
> /proc/sys/net/ipv4/conf/vlan1/rp_filter:0
>=20
> As you can see they're all the same. Does this mean that rp_filter ne=
ver
> really worked as intended before 2.6.31 ? Or does it mean that rp_fil=
ter=3D0
> (eth1 and vlan1) gets overriden by all/rp_filter=3D1 in 2.6.31 and no=
t before?

RP filter did not work correctly in 2.6.30. The code added to to the lo=
ose
mode caused a bug; the rp_filter value was being computed as:
  rp_filter =3D interface_value & all_value;
So in order to get reverse path filter both would have to be set.

In 2.6.31 this was change to:
   rp_filter =3D max(interface_value, all_value);

This was the intended behaviour, if user asks all interfaces to have rp
filtering turned on, then set /proc/sys/net/ipv4/conf/all/rp_filter =3D=
 1
or to turn on just one interface, set it for just that interface.

Sorry for any confusion this caused.



--=20

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Julian Anastasov <ja@ssi.bg>
Subject: Re: ipv4 regression in 2.6.31 ?
Date: Tue, 15 Sep 2009 03:01:47 +0300 (EEST)
Message-ID: <Pine.LNX.4.58.0909150159580.3947@u.domain.uli>
References: <20090914150935.cc895a3c.skraw@ithnet.com> <4AAE4BAF.2010406@gmail.com>
 <20090914175505.a3f132ee.skraw@ithnet.com> <20090914093128.4d709ff6@nehalam>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: Stephan von Krawczynski <skraw@ithnet.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	linux-kernel@vger.kernel.org, davem@davemloft.net,
	Linux Netdev List <netdev@vger.kernel.org>
To: Stephen Hemminger <shemminger@vyatta.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from ja.ssi.bg ([217.79.71.194]:60078 "EHLO u.domain.uli"
	rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP
	id S1755394AbZIOABg (ORCPT <rfc822;netdev@vger.kernel.org>);
	Mon, 14 Sep 2009 20:01:36 -0400
In-Reply-To: <20090914093128.4d709ff6@nehalam>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>


	Hello,

On Mon, 14 Sep 2009, Stephen Hemminger wrote:

> RP filter did not work correctly in 2.6.30. The code added to to the loose
> mode caused a bug; the rp_filter value was being computed as:
>   rp_filter = interface_value & all_value;
> So in order to get reverse path filter both would have to be set.

	May be we can add IN_DEV_MASKCONF as a better
option (all & dev). All loose-mode fans just need to set
all/rp_filter to 3 to allow both strict and loose mode and then 
DEV/rp_filter will be restricted to the allowed modes. By this way 
compatibility is preserved (all/rp_filter will mean "allowed modes")
and you can add other loose-mode variants as explained in RFC 3704.
Then strict mode will have priority to all loose modes when checking
the sender address. Or if we really want to help asymmetric routing
we should not play with loose modes but with solutions like 
rp_filter_mask:

http://www.ssi.bg/~ja/#rp_filter_mask

where we can use the DEV/medium_id knowledge for rp_filter, not
just for proxy_arp. The drawback is that currently it is
limited to 31 mediums. Still, it serves the main goal of
RFC 3704: 2.3. Feasible Path Reverse Path Forwarding.
Then users can use loose mode to fight against martians
or rp_filter_mask for setups with asymmetric routing.

Regards

--
Julian Anastasov <ja@ssi.bg>

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jarek Poplawski <jarkao2@gmail.com>
Subject: Re: ipv4 regression in 2.6.31 ?
Date: Tue, 15 Sep 2009 08:13:55 +0000
Message-ID: <20090915081354.GA10037@ff.dom.local>
References: <20090914093128.4d709ff6@nehalam>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Stephan von Krawczynski <skraw@ithnet.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	linux-kernel@vger.kernel.org, davem@davemloft.net,
	Linux Netdev List <netdev@vger.kernel.org>
To: Stephen Hemminger <shemminger@vyatta.com>
Return-path: <linux-kernel-owner+glk-linux-kernel-3=40m.gmane.org-S1757067AbZIOIOJ@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20090914093128.4d709ff6@nehalam>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: netdev.vger.kernel.org

On 14-09-2009 18:31, Stephen Hemminger wrote:
> On Mon, 14 Sep 2009 17:55:05 +0200
> Stephan von Krawczynski <skraw@ithnet.com> wrote:
> 
>> On Mon, 14 Sep 2009 15:57:03 +0200
>> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>
>>> Stephan von Krawczynski a A~(c)crit :
>>>> Hello all,
...
>>> rp_filter - INTEGER
>>>         0 - No source validation.
>>>         1 - Strict mode as defined in RFC3704 Strict Reverse Path
>>>             Each incoming packet is tested against the FIB and if the interface
>>>             is not the best reverse path the packet check will fail.
>>>             By default failed packets are discarded.
>>>         2 - Loose mode as defined in RFC3704 Loose Reverse Path
>>>             Each incoming packet's source address is also tested against the FIB
>>>             and if the source address is not reachable via any interface
>>>             the packet check will fail.
...
> RP filter did not work correctly in 2.6.30. The code added to to the loose
> mode caused a bug; the rp_filter value was being computed as:
>   rp_filter = interface_value & all_value;
> So in order to get reverse path filter both would have to be set.
> 
> In 2.6.31 this was change to:
>    rp_filter = max(interface_value, all_value);
> 
> This was the intended behaviour, if user asks all interfaces to have rp
> filtering turned on, then set /proc/sys/net/ipv4/conf/all/rp_filter = 1
> or to turn on just one interface, set it for just that interface.

Alas this max() formula handles also cases where both values are set
and it doesn't look very natural/"user friendly" to me. Especially
with something like this: all_value = 2; interface_value = 1
Why would anybody care to bother with interface_value in such a case?

"All" suggests "default" in this context, so I'd rather expect
something like:
    rp_filter = interface_value ? : all_value;
which gives "the inteded behaviour" too, plus more...

We'd only need to add e.g.:
 0 - Default ("all") validation. (No source validation if "all" is 0).
 3 - No source validation on this interface.

Jarek P.

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <shemminger@vyatta.com>
Subject: Re: ipv4 regression in 2.6.31 ?
Date: Tue, 15 Sep 2009 15:57:19 -0700
Message-ID: <20090915155719.22bae41e@nehalam>
References: <20090914093128.4d709ff6@nehalam>
	<20090915081354.GA10037@ff.dom.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Stephan von Krawczynski <skraw@ithnet.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	linux-kernel@vger.kernel.org, davem@davemloft.net,
	Linux Netdev List <netdev@vger.kernel.org>
To: Jarek Poplawski <jarkao2@gmail.com>,
	David Miller <davem@davemloft.net>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail.vyatta.com ([76.74.103.46]:60956 "EHLO mail.vyatta.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751163AbZIOW7Y (ORCPT <rfc822;netdev@vger.kernel.org>);
	Tue, 15 Sep 2009 18:59:24 -0400
In-Reply-To: <20090915081354.GA10037@ff.dom.local>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Tue, 15 Sep 2009 08:13:55 +0000
Jarek Poplawski <jarkao2@gmail.com> wrote:

> On 14-09-2009 18:31, Stephen Hemminger wrote:
> > On Mon, 14 Sep 2009 17:55:05 +0200
> > Stephan von Krawczynski <skraw@ithnet.com> wrote:
> > 
> >> On Mon, 14 Sep 2009 15:57:03 +0200
> >> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >>
> >>> Stephan von Krawczynski a A~(c)crit :
> >>>> Hello all,
> ...
> >>> rp_filter - INTEGER
> >>>         0 - No source validation.
> >>>         1 - Strict mode as defined in RFC3704 Strict Reverse Path
> >>>             Each incoming packet is tested against the FIB and if the interface
> >>>             is not the best reverse path the packet check will fail.
> >>>             By default failed packets are discarded.
> >>>         2 - Loose mode as defined in RFC3704 Loose Reverse Path
> >>>             Each incoming packet's source address is also tested against the FIB
> >>>             and if the source address is not reachable via any interface
> >>>             the packet check will fail.
> ...
> > RP filter did not work correctly in 2.6.30. The code added to to the loose
> > mode caused a bug; the rp_filter value was being computed as:
> >   rp_filter = interface_value & all_value;
> > So in order to get reverse path filter both would have to be set.
> > 
> > In 2.6.31 this was change to:
> >    rp_filter = max(interface_value, all_value);
> > 
> > This was the intended behaviour, if user asks all interfaces to have rp
> > filtering turned on, then set /proc/sys/net/ipv4/conf/all/rp_filter = 1
> > or to turn on just one interface, set it for just that interface.
> 
> Alas this max() formula handles also cases where both values are set
> and it doesn't look very natural/"user friendly" to me. Especially
> with something like this: all_value = 2; interface_value = 1
> Why would anybody care to bother with interface_value in such a case?
> 
> "All" suggests "default" in this context, so I'd rather expect
> something like:
>     rp_filter = interface_value ? : all_value;
> which gives "the inteded behaviour" too, plus more...
> 
> We'd only need to add e.g.:
>  0 - Default ("all") validation. (No source validation if "all" is 0).
>  3 - No source validation on this interface.

More values == more confusion.
I chose the maxconf() method to make rp_filter consistent with other
multi valued variables (arp_announce and arp_ignore).

--------
Subject: [PATCH] Document rp_filter behaviour

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>


--- a/Documentation/networking/ip-sysctl.txt	2009-09-15 15:54:25.844934373 -0700
+++ b/Documentation/networking/ip-sysctl.txt	2009-09-15 15:55:40.709205883 -0700
@@ -744,6 +744,8 @@ rp_filter - INTEGER
 	Default value is 0. Note that some distributions enable it
 	in startup scripts.
 
+	The max value from conf/{all,interface}/rp_filter is used.
+
 arp_filter - BOOLEAN
 	1 - Allows you to have multiple network interfaces on the same
 	subnet, and have the ARPs for each interface be answered







-- 

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jarek Poplawski <jarkao2@gmail.com>
Subject: Re: ipv4 regression in 2.6.31 ?
Date: Wed, 16 Sep 2009 05:23:04 +0000
Message-ID: <20090916052304.GA4894@ff.dom.local>
References: <20090914093128.4d709ff6@nehalam> <20090915081354.GA10037@ff.dom.local> <20090915155719.22bae41e@nehalam>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: David Miller <davem@davemloft.net>,
	Stephan von Krawczynski <skraw@ithnet.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	linux-kernel@vger.kernel.org,
	Linux Netdev List <netdev@vger.kernel.org>
To: Stephen Hemminger <shemminger@vyatta.com>
Return-path: <linux-kernel-owner+glk-linux-kernel-3=40m.gmane.org-S1754970AbZIPFXX@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <20090915155719.22bae41e@nehalam>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: netdev.vger.kernel.org

On Tue, Sep 15, 2009 at 03:57:19PM -0700, Stephen Hemminger wrote:
> On Tue, 15 Sep 2009 08:13:55 +0000
> Jarek Poplawski <jarkao2@gmail.com> wrote:
> 
> > On 14-09-2009 18:31, Stephen Hemminger wrote:
> > > On Mon, 14 Sep 2009 17:55:05 +0200
> > > Stephan von Krawczynski <skraw@ithnet.com> wrote:
> > > 
> > >> On Mon, 14 Sep 2009 15:57:03 +0200
> > >> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > >>
> > >>> Stephan von Krawczynski a A~(c)crit :
> > >>>> Hello all,
> > ...
> > >>> rp_filter - INTEGER
> > >>>         0 - No source validation.
> > >>>         1 - Strict mode as defined in RFC3704 Strict Reverse Path
> > >>>             Each incoming packet is tested against the FIB and if the interface
> > >>>             is not the best reverse path the packet check will fail.
> > >>>             By default failed packets are discarded.
> > >>>         2 - Loose mode as defined in RFC3704 Loose Reverse Path
> > >>>             Each incoming packet's source address is also tested against the FIB
> > >>>             and if the source address is not reachable via any interface
> > >>>             the packet check will fail.
> > ...
> > > RP filter did not work correctly in 2.6.30. The code added to to the loose
> > > mode caused a bug; the rp_filter value was being computed as:
> > >   rp_filter = interface_value & all_value;
> > > So in order to get reverse path filter both would have to be set.
> > > 
> > > In 2.6.31 this was change to:
> > >    rp_filter = max(interface_value, all_value);
> > > 
> > > This was the intended behaviour, if user asks all interfaces to have rp
> > > filtering turned on, then set /proc/sys/net/ipv4/conf/all/rp_filter = 1
> > > or to turn on just one interface, set it for just that interface.
> > 
> > Alas this max() formula handles also cases where both values are set
> > and it doesn't look very natural/"user friendly" to me. Especially
> > with something like this: all_value = 2; interface_value = 1
> > Why would anybody care to bother with interface_value in such a case?
> > 
> > "All" suggests "default" in this context, so I'd rather expect
> > something like:
> >     rp_filter = interface_value ? : all_value;
> > which gives "the inteded behaviour" too, plus more...
> > 
> > We'd only need to add e.g.:
> >  0 - Default ("all") validation. (No source validation if "all" is 0).
> >  3 - No source validation on this interface.
> 
> More values == more confusion.
> I chose the maxconf() method to make rp_filter consistent with other
> multi valued variables (arp_announce and arp_ignore).

This additional value is not necessary (it'd give as superpowers).
Max seems logical to me only when values are sorted (especially if
max is the strictest).

Jarek P.

> 
> --------
> Subject: [PATCH] Document rp_filter behaviour
> 
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> 
> 
> --- a/Documentation/networking/ip-sysctl.txt	2009-09-15 15:54:25.844934373 -0700
> +++ b/Documentation/networking/ip-sysctl.txt	2009-09-15 15:55:40.709205883 -0700
> @@ -744,6 +744,8 @@ rp_filter - INTEGER
>  	Default value is 0. Note that some distributions enable it
>  	in startup scripts.
>  
> +	The max value from conf/{all,interface}/rp_filter is used.
> +
>  arp_filter - BOOLEAN
>  	1 - Allows you to have multiple network interfaces on the same
>  	subnet, and have the ARPs for each interface be answered
> 
> 
> 
> 
> 
> 
> 
> -- 

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephen Hemminger <shemminger@vyatta.com>
Subject: Re: ipv4 regression in 2.6.31 ?
Date: Wed, 16 Sep 2009 10:00:28 -0700
Message-ID: <20090916100028.654f7893@nehalam>
References: <20090914093128.4d709ff6@nehalam>
	<20090915081354.GA10037@ff.dom.local>
	<20090915155719.22bae41e@nehalam>
	<20090916052304.GA4894@ff.dom.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: David Miller <davem@davemloft.net>,
	Stephan von Krawczynski <skraw@ithnet.com>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	linux-kernel@vger.kernel.org,
	Linux Netdev List <netdev@vger.kernel.org>
To: Jarek Poplawski <jarkao2@gmail.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail.vyatta.com ([76.74.103.46]:49443 "EHLO mail.vyatta.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753283AbZIPRAb (ORCPT <rfc822;netdev@vger.kernel.org>);
	Wed, 16 Sep 2009 13:00:31 -0400
In-Reply-To: <20090916052304.GA4894@ff.dom.local>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Wed, 16 Sep 2009 05:23:04 +0000
Jarek Poplawski <jarkao2@gmail.com> wrote:

> On Tue, Sep 15, 2009 at 03:57:19PM -0700, Stephen Hemminger wrote:
> > On Tue, 15 Sep 2009 08:13:55 +0000
> > Jarek Poplawski <jarkao2@gmail.com> wrote:
> > 
> > > On 14-09-2009 18:31, Stephen Hemminger wrote:
> > > > On Mon, 14 Sep 2009 17:55:05 +0200
> > > > Stephan von Krawczynski <skraw@ithnet.com> wrote:
> > > > 
> > > >> On Mon, 14 Sep 2009 15:57:03 +0200
> > > >> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > >>
> > > >>> Stephan von Krawczynski a A~(c)crit :
> > > >>>> Hello all,
> > > ...
> > > >>> rp_filter - INTEGER
> > > >>>         0 - No source validation.
> > > >>>         1 - Strict mode as defined in RFC3704 Strict Reverse Path
> > > >>>             Each incoming packet is tested against the FIB and if the interface
> > > >>>             is not the best reverse path the packet check will fail.
> > > >>>             By default failed packets are discarded.
> > > >>>         2 - Loose mode as defined in RFC3704 Loose Reverse Path
> > > >>>             Each incoming packet's source address is also tested against the FIB
> > > >>>             and if the source address is not reachable via any interface
> > > >>>             the packet check will fail.
> > > ...
> > > > RP filter did not work correctly in 2.6.30. The code added to to the loose
> > > > mode caused a bug; the rp_filter value was being computed as:
> > > >   rp_filter = interface_value & all_value;
> > > > So in order to get reverse path filter both would have to be set.
> > > > 
> > > > In 2.6.31 this was change to:
> > > >    rp_filter = max(interface_value, all_value);
> > > > 
> > > > This was the intended behaviour, if user asks all interfaces to have rp
> > > > filtering turned on, then set /proc/sys/net/ipv4/conf/all/rp_filter = 1
> > > > or to turn on just one interface, set it for just that interface.
> > > 
> > > Alas this max() formula handles also cases where both values are set
> > > and it doesn't look very natural/"user friendly" to me. Especially
> > > with something like this: all_value = 2; interface_value = 1
> > > Why would anybody care to bother with interface_value in such a case?
> > > 
> > > "All" suggests "default" in this context, so I'd rather expect
> > > something like:
> > >     rp_filter = interface_value ? : all_value;
> > > which gives "the inteded behaviour" too, plus more...
> > > 
> > > We'd only need to add e.g.:
> > >  0 - Default ("all") validation. (No source validation if "all" is 0).
> > >  3 - No source validation on this interface.
> > 
> > More values == more confusion.
> > I chose the maxconf() method to make rp_filter consistent with other
> > multi valued variables (arp_announce and arp_ignore).
> 
> This additional value is not necessary (it'd give as superpowers).
> Max seems logical to me only when values are sorted (especially if
> max is the strictest).

The values had to be unsorted because of the requirement to retain
interface compatibility with older releases.
-- 

From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stephan von Krawczynski <skraw@ithnet.com>
Subject: Re: ipv4 regression in 2.6.31 ?
Date: Fri, 18 Sep 2009 10:30:15 +0200
Message-ID: <20090918103015.9e7ee289.skraw@ithnet.com>
References: <20090914093128.4d709ff6@nehalam>
	<20090915081354.GA10037@ff.dom.local>
	<20090915155719.22bae41e@nehalam>
	<20090916052304.GA4894@ff.dom.local>
	<20090916100028.654f7893@nehalam>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Jarek Poplawski <jarkao2@gmail.com>,
	David Miller <davem@davemloft.net>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	linux-kernel@vger.kernel.org,
	Linux Netdev List <netdev@vger.kernel.org>
To: Stephen Hemminger <shemminger@vyatta.com>
Return-path: <netdev-owner@vger.kernel.org>
Received: from mail-a02.ithnet.com ([217.64.83.97]:48256 "HELO ithnet.com"
	rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with SMTP
	id S1751506AbZIRInj (ORCPT <rfc822;netdev@vger.kernel.org>);
	Fri, 18 Sep 2009 04:43:39 -0400
In-Reply-To: <20090916100028.654f7893@nehalam>
Sender: netdev-owner@vger.kernel.org
List-ID: <netdev.vger.kernel.org>

On Wed, 16 Sep 2009 10:00:28 -0700
Stephen Hemminger <shemminger@vyatta.com> wrote:

> On Wed, 16 Sep 2009 05:23:04 +0000
> Jarek Poplawski <jarkao2@gmail.com> wrote:
> 
> > On Tue, Sep 15, 2009 at 03:57:19PM -0700, Stephen Hemminger wrote:
> > > On Tue, 15 Sep 2009 08:13:55 +0000
> > > Jarek Poplawski <jarkao2@gmail.com> wrote:
> > > 
> > > > On 14-09-2009 18:31, Stephen Hemminger wrote:
> > > > > On Mon, 14 Sep 2009 17:55:05 +0200
> > > > > Stephan von Krawczynski <skraw@ithnet.com> wrote:
> > > > > 
> > > > >> On Mon, 14 Sep 2009 15:57:03 +0200
> > > > >> Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > > > >>
> > > > >>> Stephan von Krawczynski a A~(c)crit :
> > > > >>>> Hello all,
> > > > ...
> > > > >>> rp_filter - INTEGER
> > > > >>>         0 - No source validation.
> > > > >>>         1 - Strict mode as defined in RFC3704 Strict Reverse Path
> > > > >>>             Each incoming packet is tested against the FIB and if the interface
> > > > >>>             is not the best reverse path the packet check will fail.
> > > > >>>             By default failed packets are discarded.
> > > > >>>         2 - Loose mode as defined in RFC3704 Loose Reverse Path
> > > > >>>             Each incoming packet's source address is also tested against the FIB
> > > > >>>             and if the source address is not reachable via any interface
> > > > >>>             the packet check will fail.
> > > > ...
> > > > > RP filter did not work correctly in 2.6.30. The code added to to the loose
> > > > > mode caused a bug; the rp_filter value was being computed as:
> > > > >   rp_filter = interface_value & all_value;
> > > > > So in order to get reverse path filter both would have to be set.
> > > > > 
> > > > > In 2.6.31 this was change to:
> > > > >    rp_filter = max(interface_value, all_value);
> > > > > 
> > > > > This was the intended behaviour, if user asks all interfaces to have rp
> > > > > filtering turned on, then set /proc/sys/net/ipv4/conf/all/rp_filter = 1
> > > > > or to turn on just one interface, set it for just that interface.
> > > > 
> > > > Alas this max() formula handles also cases where both values are set
> > > > and it doesn't look very natural/"user friendly" to me. Especially
> > > > with something like this: all_value = 2; interface_value = 1
> > > > Why would anybody care to bother with interface_value in such a case?
> > > > 
> > > > "All" suggests "default" in this context, so I'd rather expect
> > > > something like:
> > > >     rp_filter = interface_value ? : all_value;
> > > > which gives "the inteded behaviour" too, plus more...
> > > > 
> > > > We'd only need to add e.g.:
> > > >  0 - Default ("all") validation. (No source validation if "all" is 0).
> > > >  3 - No source validation on this interface.
> > > 
> > > More values == more confusion.
> > > I chose the maxconf() method to make rp_filter consistent with other
> > > multi valued variables (arp_announce and arp_ignore).
> > 
> > This additional value is not necessary (it'd give as superpowers).
> > Max seems logical to me only when values are sorted (especially if
> > max is the strictest).
> 
> The values had to be unsorted because of the requirement to retain
> interface compatibility with older releases.

The parameters are the same (I guess this is what you call interface
compatibility), but the function came out different, meaning you broke
functional compatibility with 2.6.31 instead. Just to mention that - though
the argument is leight-weight for the compatibility broke because the whole
thing was broken somehow before the bugfix.

-- 
Regards,
Stephan


