Maybe I'm missing something, but the only case I found that required extra wineserver work was for handling asynchronous ReadFile requests (since these requests don't go through the ws2_32 path, see patch 6). Using ReadFile like that is technically something you're not supposed to do, but we all know that means that someone's done it anyway. For everything else (send, recv, select) the proposed technique just requires a check to see if IP_PKTINFO is enabled so it can throw out the packet if it doesn't match the socket's interface. The kernel developers have made it clear that they're not going to do anything to change the situation (and even if they did, it wouldn't work under BSD or Mac OS X), so it seems to me like the change has to be in Wine. It would also be possible to override the appropriate calls by replacing the different dynamically loaded symbols, though doing so seems like an awkward approach since Wine is already meant to be a compatibility layer. I would really like to see this issue get resolved, so I'm willing to put whatever work into fixing this that's necessary to get it done right. Erich Hoover ehoover(a)mines.edu On Sat, Oct 10, 2009 at 2:31 AM, Alexandre Julliard <julliard(a)winehq.org>wrote:
Erich Hoover <ehoover(a)mines.edu> writes:
The maintainer has pretty much "put his foot down" on the matter (several times actually, here's a nicer one): http://www.mail-archive.com/linux-net(a)vger.kernel.org/msg01306.html
This is rather embarrasing, but apparently I left server/protocol.def out of the patchset. I could have sworn I tested these patches on a clean git, but apparently I made a mistake. Is there any chance that this mistake is the reason for the rejection? The additional code in these patches is only utilized (sans a call to getsockopt) on UDP broadcast sockets that have been bound to a specific interface. According to the kernel devs, this behavior is what IP_PKTINFO is meant to do and that they have no intention of adding an additional feature that does exactly the same thing.
I don't think you can do that reliably in user space, at least not in the Wine architecture. You'd have to put all the network I/O in the wineserver, and performance would suck. The kernel devs objection would work if it could be done directly inside the app, but I don't see a way to do that cleanly inside the Wine network layer.
-- Alexandre Julliard julliard(a)winehq.org