On Tue, Oct 12, 2021 at 2:32 PM Paul Gofman pgofman@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@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