Re: [patch] fix statd -n

[Wendy Cheng <wcheng@netapp.com>]

J. Bruce Fields wrote:
> On Mon, Apr 21, 2008 at 10:10:03AM -0400, Jeff Layton wrote:
>   
>> On Mon, 21 Apr 2008 09:39:40 -0400
>> "J. Bruce Fields" <bfields@fieldses.org> wrote:
>>
>>     
>>> On Mon, Apr 21, 2008 at 07:01:07AM -0400, Jeff Layton wrote:
>>>       
>>>> On Sun, 20 Apr 2008 22:11:53 -0400
>>>> "J. Bruce Fields" <bfields@fieldses.org> wrote:
>>>>
>>>>         
>>>>> On Sun, Apr 20, 2008 at 08:49:52PM -0400, Janne Karhunen wrote:
>>>>>           
>>>>>> Yes, but loopback can also be spoofed.
>>>>>>             
>>>>> Is that true?  I thought the kernel discarded packets from interfaces
>>>>> other than lo claiming to be from 127.*.*.*.
>>>>>
>>>>>           
>>>> I think that's the case only if you have rp_filter turned on. It
>>>> usually is these days, but there are some situations where it doesn't
>>>> do what's expected (vlans, for instance), and has to be disabled.
>>>>         
>>> Well, if you believe Documentation/filesystems/proc.txt on rp_filter:
>>>
>>> 	"Integer value determines if a source validation should be made.
>>> 	1 means yes, 0 means no.  Disabled by default, but
>>> 	local/broadcast address spoofing is always on."
>>>
>>> But I haven't tested this or looked at the code.
>>>
>>> --b.
>>>       
>> I think that's basically correct, but most modern distros turn it on by
>> default. From the default /etc/sysctl.conf on my fedora box:
>>
>> net.ipv4.conf.default.rp_filter = 1
>>
>> ...it's generally a good thing to enable, but there are places where it
>> needs to be disabled. For instance, my Linksys WRT54g is doing firewall
>> duties and has it disabled because the switch ports on it are segmented
>> with VLANs and rp_filter interferes with that.
>>     
>
> Actually, the specific question here is: say you have an ethernet
> interface 192.168.0.1.  Will the kernel deliver a packet that comes from
> the network and has source address 192.168.0.1?
>   

I doubt it will. Remember one of my old patches (patch 3 & 4) ?
https://www.redhat.com/archives/cluster-devel/2007-April/msg00028.html
https://www.redhat.com/archives/cluster-devel/2007-April/msg00032.html 
(patch 3)
https://www.redhat.com/archives/cluster-devel/2007-April/msg00031.html 
(patch 4)

I think you have to specifically hack the kernel (as I did) but I don't 
have linux source code in front of me at this moment.

-- Wendy