Requesting comments on patchset to fix Bug 7929 (C&C 3 network does not work)

[Erich Hoover]

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 at mines.edu

On Sat, Oct 10, 2009 at 2:31 AM, Alexandre Julliard <julliard at winehq.org>wrote:

> Erich Hoover <ehoover at 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@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 at winehq.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20091010/c2dbe0a8/attachment.htm>