netdev - Re: [IPV4] LVS: Allow to send ICMP unreachable responses when real-servers are removed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <464C85C6.1090903@trash.net>
Date:	Thu, 17 May 2007 18:41:42 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Janusz Krzysztofik <jkrzyszt@....icnet.pl>
CC:	Julian Anastasov <ja@....bg>, Simon Horman <horms@...ge.net.au>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [IPV4] LVS: Allow to send ICMP unreachable responses when real-servers
 are removed

Janusz Krzysztofik wrote:
> Julian Anastasov wrote:
> 
>> If icmp_send is changed to use inet_addr_type() then ICMP will leave
>> with saddr != VIP and that is not nice.
>> ...
>>
>>> I'm not familiar with the IPVS terms, but as far as I understand,
>>> it is _not_ going to return RTN_LOCAL, so we get the desired
>>> behaviour of selecting a local address as source.
>>
>>
>>     But what is preferred is to use VIP in ICMP.
>>
>> ip route add local VIP dev lo table user_defined
>>
>>     returns RTCF_LOCAL but inet_addr_type() does not return RTN_LOCAL,
>> we fix one thing but break another :)
> 
> 
> Well, I have promissed you to give some feedback after I test the patch
> proposed by Patrick, but after Julian's post I can only confirm that it
> works exactly as Julian said, what is not what I would expect.


It will pick a local source address and use that. I don't see why
it matters whether its the VIP address or some other.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html