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).
On Tue, Oct 12, 2021 at 1:49 PM Paul Gofman pgofman@codeweavers.com wrote:
On 10/12/21 21:50, Erich E. Hoover wrote:
On 10/12/21 21:06, Paul Gofman wrote:
Bug 50499 is not related, that one is about SO_REUSEADDR explicitly used by an app (and not set by us to workaround broadcast issue) and behaving differently on Windows and Linux WRT which socket receives packets.
This is correct, though the solution is "the same". The SO_REUSEADDR behavior is easier to implement though, it just involves applying a SO_ATTACH_REUSEPORT_CBPF rule that always returns zero (zero is oldest).
I am afraid it might be not that simple. If you close the oldest socket the last one will take its place which is probably not the one which should now start receiving all the packets.
I suppose that's true, we probably would cover 99.99% of use cases with return 0 - but 100% proper implementation likely requires record keeping which socket is the oldest and returning the correct number.
Best, Erich