I'm not a BIRD developer, so I cannot decide hare what is the right direction for you to implement the patch. But it seems to me that it is the question that should be raised. As for implementation, I'm not sure, but from a quick glance at a code, it seem that vrf binding might be moved from sk_setup somewhere else. On Sat, Jul 27, 2024 at 2:18 PM Christian Svensson <christian@cmd.nu> wrote:
Hi Alexander,
On Sat, Jul 27, 2024 at 2:05 PM Alexander Zubkov <green@qrator.net> wrote:
I wonder if it is necessary at all to set a vrf on an accepted connection? It seems to me that setting or checking vrf should be avoided instead for an accepted connection. What do you think?
Indeed, this is what I set out to do in the beginning and is, if you boil this patch down, the actual implication when using VRFs.
The reason I chose to implement the patch as a get+set rather than a conditional set was that the existing code structure assumes that sk_setup is called on multiple types of sockets and I wasn't sure exactly how to guard for specifically sockets that are connected. In addition I tried to find a reference in the kernel to where exactly it inherits the bound interface when a new socket is created from accept() but I could not. It is evident from my experiments that it is inherited, and that is the only way accept() on a VRF bind() would make sense. Doing a get+set seems like the least risky change that I felt safe to propose.
That said, if you believe it is better implemented as a conditional and are able to nudge me how you'd want a check for the particular socket type to look, I'd be happy to do a v2 patch.
Regards,