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  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]
Date:	Sat, 28 Nov 2009 18:07:26 +0100
From:	Patrick McHardy <>
CC:	KOVACS Krisztian <>,
	KOVACS Krisztian <>,
	Andreas Schultz <>,,
Subject: Re: [tproxy,regression] tproxy broken in 2.6.32

jamal wrote:
> On Sat, 2009-11-28 at 16:46 +0100, Patrick McHardy wrote:
>> The root cause seems to be an invalid assumption, marks are often not
>> used in a symetric fashion as required by RPF.
> The only assumption is: if you set set up a mark on incoming, you are
> asking the reverse validation that is to be used to consider that mark.
> This has nothing to do with RPF really;-> RPF is off. There is a legit
> bug in the old setup that has a table programmed with a route that is
> not unicast. 

Right, its source validation. But the setup is valid, its asking for
specifically marked packets to be delivered locally for transparent
proxying. There's no requirement that rules using marks must resolve

>> Since this patch has already proven to break existing setups, I think
>> it should be reverted or the behaviour made optional with a default to
>> off.
> I disagree. What other setup is broken? ;->

Isn't one setup usually considered enough? :)
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists