[PATCH] server: Use SO_BINDTODEVICE in bind_to_index() if possible.

[Erich E. Hoover]

On Tue, Oct 12, 2021 at 2:32 PM Paul Gofman <pgofman at codeweavers.com> wrote:
>
> On 10/12/21 23:21, Erich E. Hoover wrote:
> > On Tue, Oct 12, 2021 at 1:34 PM Paul Gofman <pgofman at codeweavers.com> wrote:
> >> ...
> >> Hm... I am a bit unsure anymore what exactly is 33008, I read there that
> >> it is claimed incorrect to have some 1.2.3.4->0.0.0.0 per se as it
> >> breaks some NAT rules. But if it is strictly about two Wine processes
> >> binding UDP to different interfaces, same port, I think my patch should
> >> be fixing that.
> > One process is a Wine process and the other is not, but the problem is
> > that the Wine process is gobbling the packets meant for the other
> > process (packets for the other process come to us since we bind
> > second, and we're dropping all packets that are not part of our
> > interface bind).  Your patch will fix the issue for newer kernels,
> > though it's also possible to fix it for older kernels with an
> > incredibly complicated SO_ATTACH_REUSEPORT_CBPF rule (you can make a
> > list of your sockets, match against that list, and return the ID that
> > corresponds to the correct socket in the list or return -1 for the
> > regular Linux behavior if it's not on the list).
>
> Yes, we would need to maintain the ordered 'reuse groups' in the
> wineserver and update the filters on sockets bind and close. That's for
> Wine only operation within a single prefix. As for another non-Wine (or
> other Wine prefix processes) I am not sure how we can track that at all,
> at least I could not find a way to query 'reuse group' information from
> the system.

Yes, my understanding is that we would need to coordinate "amongst
ourselves" and we would assume that nobody else tries to make a
conflicting reuse group (probably a fair assumption).

> I don't see how returning -1 would make sense as falling
> back to the plain SO_REUSEPORT mechanism can still leave the other app
> without packets routed instead to our (wrongly bound) sockets.

That's a fair point.

> Even
> without the non-Wine processes part this seems rather complicated and
> given there seems to be a simple and sure way to do what we need since
> Linux 5.7 I don't see why would we need to implement a nontrivial
> intermediate step to be obsoleted anyway.

Agreed, "back in the day" this was the only way to solve the problem
and the complexity kept me from proposing a proper fix.  Fortunately
things are much easier now and all the issues should be resolved on
newer kernels with your patch.

Best,
Erich