http://bugs.winehq.org/show_bug.cgi?id=19493
Summary: socket option IP_PKTINFO is not implemented Product: Wine Version: 1.1.12 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winsock AssignedTo: wine-bugs@winehq.org ReportedBy: johannes.gajdosik@gmx.at
The socket option IP_PKTINFO is not implemented:
the source code setsockopt(fd,IPPROTO_IP,IP_PKTINFO,(const char*)(&yes),sizeof(int)); gives the error fixme:winsock:WS_setsockopt Unknown IPPROTO_IP optname 0x00000013
This prevents a multicast client from distinguishing the incoming multicast packets by their multicast group.
http://bugs.winehq.org/show_bug.cgi?id=19493
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
--- Comment #1 from André H. nerv@dawncrow.de 2009-07-28 14:12:54 --- can you please supply a complete test-source as Attachment?
http://bugs.winehq.org/show_bug.cgi?id=19493
--- Comment #2 from johannes.gajdosik@gmx.at 2009-07-30 10:56:54 --- Created an attachment (id=22715) --> (http://bugs.winehq.org/attachment.cgi?id=22715) receive 2 mcast streams and distinguish the packets by mcast group
This program binds a socket to port 10000. It joins the multicast groups 239.239.239.0 and 239.239.239.2 and enters a receive-print loop. The destination address of each packet is printed. The program works well on linux (compiled with gcc) and windows (compiled with gcc, using mingw). But is does not work with wine 1.1.12 on linux.
The error message is: fixme:winsock:WS_setsockopt Unknown IPPROTO_IP optname 0x00000013
And there is also another error: when WSAIoctl would be called at the beginning, I would get:
fixme:winsock:WSAIoctl SIO_GET_EXTENSION_FUNCTION_POINTER {f689d7c8-6f1f-436b-8a53-e54fe351c322}: stub
http://bugs.winehq.org/show_bug.cgi?id=19493
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source Status|UNCONFIRMED |NEW CC| |xerox_xerox2000@yahoo.co.uk Ever Confirmed|0 |1
--- Comment #3 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2009-11-21 15:46:40 --- confirm. Would it be possible for you to add test to wine-test suite?
http://bugs.winehq.org/show_bug.cgi?id=19493
Erich Hoover ehoover@mines.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover@mines.edu
--- Comment #4 from Erich Hoover ehoover@mines.edu 2010-10-08 10:08:01 CDT --- (In reply to comment #2)
This program binds a socket to port 10000. It joins the multicast groups 239.239.239.0 and 239.239.239.2 and enters a receive-print loop. The destination address of each packet is printed. The program works well on linux (compiled with gcc) and windows (compiled with gcc, using mingw). But is does not work with wine 1.1.12 on linux.
I discovered this bug while searching for something else and it is relevant to a bug that I am directly working on (Bug #7929). Are you entirely certain that this functionality can be enabled on Windows? MSDN indicates that IP_PKTINFO is only supported for getsockopt() and not setsockopt(), so I have previously ignored the possibility that a user application could set the IP_PKTINFO option.
Adjusting for this scenario should be a simple matter in what I'm working on, but if you really can set this option then I will have to do some additional work. So, if you could confirm this (and preferably provide links to some applications that use this feature) then I would greatly appreciate it.
http://bugs.winehq.org/show_bug.cgi?id=19493
--- Comment #5 from johannes.gajdosik@gmx.at 2010-10-08 13:35:16 CDT --- Dear Erich Hoover: This is a confirmed bug. The functionality is provided in M$-Windows, but not in Wine, at least on 2009-11-21. Maybe it has been implemented in Wine by now, I do not know, but I suppose not.
If you still do not believe what I have written last year, and what I confirm now, and what has been confirmed by André H, please have I look into my attached test program and try it by yourself.
What does this mean: "preferably provide links to some applications that use this feature"? Is my test program no application that uses that feature? I for myself do not use windows or windows programs. I am a software developer, and the reason why I use wine is that I can test my cross-compiled window$ binaries.
Any application that simultanousely receives many multicast streams on the same UDP port will suffer from this wine bug. Perhaps peer-to-peer applications. In my case it is a video displaying application that can display many multicast streams at once.
http://bugs.winehq.org/show_bug.cgi?id=19493
--- Comment #6 from Erich Hoover ehoover@mines.edu 2010-10-09 16:51:22 CDT --- (In reply to comment #5)
If you still do not believe what I have written last year, and what I confirm now, and what has been confirmed by André H, please have I look into my attached test program and try it by yourself.
I don't own any Windows PCs anymore, so I'm just double checking this before I put a bunch of additional work into the patchset I'm working on. Usually when MSDN says something is not supported it's accurate, apparently that is not the case for this particular feature.
What does this mean: "preferably provide links to some applications that use this feature"? Is my test program no application that uses that feature? I for myself do not use windows or windows programs. I am a software developer, and the reason why I use wine is that I can test my cross-compiled window$ binaries.
I apologize if I have offended you here, occasionally there are reports of things working on Windows that are not quite accurate. What I was getting at here is that it would be nice to have an application that supports this feature to list on the bug report. Having that information when I submit the patch I can then say "this patch fixes Bug #19493, which affects applications X, Y, and Z." This kind of information can sometimes help a patch get accepted, as a list of affected applications can show the importance of the patch.
Since I am familiar with this functionality, and the fix for this is rather trivial, I will look into writing a patch to get this feature implemented and show its validity with the automated test system. I cannot guarantee that I will be able to get such a patch accepted any time soon (or ever), but I will do my best to get this fixed for you.
http://bugs.winehq.org/show_bug.cgi?id=19493
--- Comment #7 from johannes.gajdosik@gmx.at 2010-10-10 18:47:57 CDT ---
Usually when MSDN says something is not supported it's accurate, apparently that is not the case for this particular feature.
You probably refer to http://msdn.microsoft.com/en-us/library/ms738586%28VS.85%29.aspx where in the line IP_PKTINFO there is no "yes" in the column "Set". I assume this is a typo, because: 1) setsockopt works fine with IP_PKTINFO, at least in version Windows XP, as proved by my test program 2) Because the description "Indicates that packet information _should_ _be_ returned in the WSARecvMsg function" makes sense only for setsockopt. When only getsockopt would be working with IP_PKTINFO, the description should be: "Indicates that packet information _is_ returned in the WSARecvMsg function".
I apologize if I have offended you here
No offense is done.
occasionally there are reports of things working on Windows that are not quite accurate.
I can assure you that my test program worked fine in WindowsXP, and the actual application that uses setsockopt with IP_PKTINFO still works fine in WindowsXP.
What I was getting at here is that it would be nice to have an application that supports this feature to list on the bug report. Having that information when I submit the patch I can then say "this patch fixes Bug #19493, which affects applications X, Y, and Z."
I cannot help here, since the actual application is a commercial product of the company I am working for, and it is not adequate for public use.
Since I am familiar with this functionality, and the fix for this is rather trivial, I will look into writing a patch to get this feature implemented and show its validity with the automated test system.
This would be very nice, thank you! I am neigther familiar with wine code, nor with the automatic test system, this is the reason why I did not produce a patch by myself. Perhaps my test program can be used for the automatic test system.
I cannot guarantee that I will be able to get such a patch accepted any time soon (or ever), but I will do my best to get this fixed for you.
Thanks again!
http://bugs.winehq.org/show_bug.cgi?id=19493
--- Comment #8 from Erich Hoover ehoover@mines.edu 2010-10-10 19:30:45 CDT --- (In reply to comment #7)
... I cannot help here, since the actual application is a commercial product of the company I am working for, and it is not adequate for public use.
Then I'll just have to make the case with a good set of tests.
... I am neigther familiar with wine code, nor with the automatic test system, this is the reason why I did not produce a patch by myself.
Are you familiar with patching and compiling Wine? I have a patch for this that is ready for testing, if you are interested I can post it here. It is possible that I'll have to find a slightly different way to approach this before it gets accepted, but I'll have to submit it to wine-devel for people to take a look before I'll know.
Perhaps my test program can be used for the automatic test system.
The test application you attached would not really work within the framework of the testing system. Since you're joining a multicast group and waiting for packets from an external source there's no way the test system could guarantee a response would be received that it can then test for IP_PKTINFO headers. I've got some tests put together now though, so it isn't a big deal.
http://bugs.winehq.org/show_bug.cgi?id=19493
--- Comment #9 from johannes.gajdosik@gmx.at 2010-10-11 03:51:33 CDT ---
Are you familiar with patching and compiling Wine? I have a patch for this that is ready for testing, if you are interested I can post it here.
I think I will be able to patch and compile wine, although I have not done this for some years. I would definitely be interested in the patch, and I would try it.
It is possible that I'll have to find a slightly different way to approach this before it gets accepted, but I'll have to submit it to wine-devel for people to take a look before I'll know.
Perhaps my test program can be used for the automatic test system.
The test application you attached would not really work within the framework of the testing system. Since you're joining a multicast group and waiting for packets from an external source there's no way the test system could guarantee a response would be received that it can then test for IP_PKTINFO headers.
I know nothing of the test suite. I just think that: 1) the test should produce the same result in windows and wine 2) the test in this case must involve receiving and distinguishing multicast packets from 2 different multicast groups. Of course a sender program is required, but this is really easy.
I've got some tests put together now though, so it isn't a big deal.
Thats fine.
http://bugs.winehq.org/show_bug.cgi?id=19493
--- Comment #10 from Erich Hoover ehoover@mines.edu 2010-10-11 09:33:41 CDT --- (In reply to comment #9)
I think I will be able to patch and compile wine, although I have not done this for some years. I would definitely be interested in the patch, and I would try it.
I've posted a Request For Comments on wine-devel, here is a direct link to the patch: http://www.winehq.org/pipermail/wine-devel/attachments/20101010/27590113/att...
If you need them, there are some instructions for compiling and patching Wine here (though they're not very specific): http://wiki.winehq.org/FAQ#head-7ed3c3163e2b932ee2030a48f9c5e553dc41817b
I know nothing of the test suite. I just think that:
- the test should produce the same result in windows and wine
This is part of the point of the test system, the other point being able to check for regressions. The new test bot system (https://testbot.winehq.org/index.pl) actually allows developers to run tests on a variety of Windows versions.
- the test in this case must involve receiving and distinguishing multicast
packets from 2 different multicast groups. Of course a sender program is required, but this is really easy.
At the very least this should be a separate test, as IP_PKTINFO and multicasting are independent features (though this might also be a good test to add). I don't have a lot of experience with multicast (my interest in IP_PKTINFO is for a completely different application), but you have to be careful when constructing tests to not require a network card. Can you send and receive packets for a multicast group using only the local adapter?
http://bugs.winehq.org/show_bug.cgi?id=19493
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|nerv@dawncrow.de |
http://bugs.winehq.org/show_bug.cgi?id=19493
--- Comment #11 from Erich Hoover ehoover@mines.edu 2010-12-07 12:22:19 CST --- If you could, please retest your application against the latest version of git - this bug should be fixed by commit 54b4f836fd9df485d4b0c83a749da22f8c1de25a.
http://bugs.winehq.org/show_bug.cgi?id=19493
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #12 from Jerome Leclanche adys.wh@gmail.com 2011-02-05 00:49:05 CST --- Ping. Anyone able to retest?
http://bugs.winehq.org/show_bug.cgi?id=19493
--- Comment #13 from Erich Hoover ehoover@mines.edu 2011-02-07 10:14:58 CST --- (In reply to comment #12)
Ping. Anyone able to retest?
I know from some off-list discussions with Emerson Prado that the patches for this fixed a problem with FileMaker Pro. However, we have not heard back on whether the patch fixed the reporter's problem.
http://bugs.winehq.org/show_bug.cgi?id=19493
Emerson Prado emerson.prado.eng@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |emerson.prado.eng@gmail.com
--- Comment #14 from Emerson Prado emerson.prado.eng@gmail.com 2011-04-29 12:00:56 CDT --- I should have done this before, but here goes my feedback. With older Wine versions, FileMaker Pro couldn't see remote databases at all. With Wine 1.3.8, FileMaker can see remote databases stored in servers if we manually add those servers in FileMaker settings*. I could do a reverse regression testing to make sure this is the patch that made it, but I don't know the pre/post versions involved - if someone will tell, I can do it. I'll add this bug to FileMaker AppDB entry, just while the bug is opened. But I hope we can get it closed soon. I'm willing to run johannes test software, but I can't compile it (tried with make and thru Geany, to no success). If someone can tell me how to do it, I'll test (for our rejoicing).
*FileMaker will find servers automatically, as it should be, with Erich's patches to Bug 7929, which I look forward seeing closed too.
http://bugs.winehq.org/show_bug.cgi?id=19493
--- Comment #15 from Jerome Leclanche adys.wh@gmail.com 2011-04-29 12:13:38 CDT --- This bug is fixed, then. Any other issue should be dealt with in bug 7929 or have a new bug opened.
http://bugs.winehq.org/show_bug.cgi?id=19493
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #16 from Austin English austinenglish@gmail.com 2011-04-29 12:17:39 CDT --- (In reply to comment #15)
This bug is fixed, then. Any other issue should be dealt with in bug 7929 or have a new bug opened.
Fixed.
http://bugs.winehq.org/show_bug.cgi?id=19493
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #17 from Alexandre Julliard julliard@winehq.org 2011-04-29 13:15:22 CDT --- Closing bugs fixed in 1.3.19.
-
wine-bugs＠winehq.org