netdev - Re: [PATCH net-next] net: ip6mr: add support for passing full packet on wrong mif

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] [day] [month] [year] [list]

Date:   Mon, 14 Feb 2022 17:00:06 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Mobashshera Rasool <mobash.rasool.linux@...il.com>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, kuznet@....inr.ac.ru,
        yoshfuji@...ux-ipv6.org, mrasool@...are.com,
        equinox@...nsourcerouting.org, mobash.rasool@...il.com
Subject: Re: [PATCH net-next] net: ip6mr: add support for passing full
 packet on wrong mif

On Tue, 15 Feb 2022 02:53:49 +0530 Mobashshera Rasool wrote:
> This patch adds support for MRT6MSG_WRMIFWHOLE which is used to pass
> full packet and real vif id when the incoming interface is wrong.
> While the RP and FHR are setting up state we need to be sending the
> registers encapsulated with all the data inside otherwise we lose it.
> The RP then decapsulates it and forwards it to the interested parties.
> Currently with WRONGMIF we can only be sending empty register packets
> and will lose that data.
> This behaviour can be enabled by using MRT_PIM with
> val == MRT6MSG_WRMIFWHOLE. This doesn't prevent MRT6MSG_WRONGMIF from
> happening, it happens in addition to it, also it is controlled by the same
> throttling parameters as WRONGMIF (i.e. 1 packet per 3 seconds currently).
> Both messages are generated to keep backwards compatibily and avoid
> breaking someone who was enabling MRT_PIM with val == 4, since any
> positive val is accepted and treated the same.
> 
> Signed-off-by: Mobashshera Rasool <mobash.rasool@...il.com>

Your patch got corrupted by your email client (line-wrapped), 
perhaps try git send-email?