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: <55a4f86e0910140250o45532dabr33707c025dfa25f9@mail.gmail.com>
Date:	Wed, 14 Oct 2009 02:50:47 -0700
From:	Maciej Żenczykowski <zenczykowski@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	steve@...gwyn.com, atis@...rotik.com, netdev@...r.kernel.org,
	panther@...abit.hu, eric.dumazet@...il.com, brian.haley@...com
Subject: Re: [PATCH] Add sk_mark route lookup support for IPv4 listening 
	sockets, and for IPv4 multicast forwarding

Problem is the primary purpose of the mark is to enable matching on
the mark in the routing tables.

See 'ip rule  ... fwmark X ...'

ie. that fails due to circular dependency.


On Wed, Oct 14, 2009 at 02:15, David Miller <davem@...emloft.net> wrote:
> From: steve@...gwyn.com
> Date: Wed, 14 Oct 2009 08:23:19 +0100
>
>> On Wed, Oct 14, 2009 at 12:51:56AM -0700, Maciej Żenczykowski wrote:
>>> I'm thinking that the mark should be a tunnel parameter with values of
>>> inherit or a constant.
>>>
>> Why not do this on a per-route basis (i.e. lets suppose we add a
>> "setmark" parameter to each route) and this would allow changing
>> a mark when a packet matches the route. This not only solves the
>> tunnel case, but would be generically useful as well.
>>
>> Since we have to look up routes anyway, it shouldn't add any
>> real overhead to the routing process and we can benefit from
>> all the existing infrastructure (route cache, etc).
>
> This idea, I like :-)
>
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ