[Bug 33008] New: UDP listening on specific IP address does not work properly
http://bugs.winehq.org/show_bug.cgi?id=33008 Bug #: 33008 Summary: UDP listening on specific IP address does not work properly Product: Wine Version: 1.5.24 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: decimusmaximus(a)seznam.cz Classification: Unclassified Wine updated from 1.5.6 to 1.5.24. My app uses UDP listening on specific address (not 0.0.0.0). It is running on machine with NAT, there are two interfaces with IP A.A.A.A (public) and IP B.B.B.B (private) My app is set to listen only on one IP address, IP A.A.A.A It works properly on Wine 1.5.6. Traffic from subnet B.B.B.B is NATed to A.A.A.A interface and application running in wine receives it correctly. After update to 1.5.24 it does not work anymore. Application does not receive data from private subnet B.B.B.B, however it works properly for traffic incoming on A.A.A.A interface. Please see attached schema. results of "netstat --listening" with Wine 1.5.6 it is listening on A.A.A.A address correctly. with Wine 1.5.24 it is listening on 0.0.0.0 (obviously incorrect, socket binding is set to A.A.A.A address in application and although it is saying 0.0.0.0 app does not receive any data from B.B.B.B network) This application has to be listening only on one interface and do not mix public and private addresses. In this case it is not accessible for clients in private network, so it is critical bug. Main strange thing is, that it is listening on all addresses 0.0.0.0 although socket binding in application is set to address A.A.A.A -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #1 from decimusmaximus(a)seznam.cz 2013-02-18 13:53:58 CST --- Created attachment 43617 --> http://bugs.winehq.org/attachment.cgi?id=43617 Traffic schema -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal --- Comment #2 from Bruno Jesus <00cpxxx(a)gmail.com> 2013-02-18 15:19:50 CST --- Not critical, read http://bugs.winehq.org/page.cgi?id=fields.html#importance Please attach the console log: http://wiki.winehq.org/FAQ#get_log AFAIK specific IP binding was not present in 1.5.6, it was introduced in 1.5.15. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #3 from decimusmaximus(a)seznam.cz 2013-02-19 13:07:30 CST --- Sorry for bad "Importance" value, I thought that this bug is critical, because all applications using specific IP (interface) binding will not work. In my case I had to downgrade to Wine 1.5.6 (version available from openSuse 12.2 repository) You said that Wine 1.5.6 does not have implementation for specific IP binding, but it works correctly there. It does not work in Wine 1.5.24 There is nothing in console, no error (fixme etc) message. As I have mentioned above, I can just check it via "netstat --listening": Tested again on another system (openSuse), there is NAT (masquerade) from B to A, simple test application created. Interface A, IP 10.0.0.1 Interface B, IP 192.168.0.1 TestApp: Binding (UDP) is set to 10.0.0.1:999 netstat shows: Wine 1.5.6: 10.0.0.1:999 Wine 1.5.24: 0.0.0.0:999 It could look that it is not problem, but it is critical issue on systems with NAT. Wine 1.5.24 problem: although it is saying 0.0.0.0, app does not receive any data from 192.168.0.1 interface (somehow internally blocked in Wine?). From app point of view it looks ok, data are received only from 10.0.0.x, but system can see that it is listening on all addresses (0.0.0.0) and traffic from 192.168.0.x with target 10.0.0.1 is not NATed, but directly sent to 0.0.0.0:999 - however data from 192.168.0.x are blocked. So clients in 192.168.0.x network are not able to connect to app. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx(a)gmail.com --- Comment #4 from Bruno Jesus <00cpxxx(a)gmail.com> 2013-02-19 13:14:17 CST --- Please attach a +winsock log if possible for both cases (1.5.6 and 1.5.24). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #5 from decimusmaximus(a)seznam.cz 2013-02-19 14:38:10 CST --- Created attachment 43642 --> http://bugs.winehq.org/attachment.cgi?id=43642 WinSock log for Wine 1.5.6 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #6 from decimusmaximus(a)seznam.cz 2013-02-19 14:38:50 CST --- Created attachment 43643 --> http://bugs.winehq.org/attachment.cgi?id=43643 WinSock log for Wine 1.5.24 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ehoover(a)mines.edu -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #7 from Erich Hoover <ehoover(a)mines.edu> 2013-02-19 14:54:49 CST --- This sounds like Wine is now properly implementing the behavior that the application should have under Windows in a similar circumstance. So, I would guess that how you're routing the traffic is responsible for Wine dropping the packet. However, it is possible that something needs to be done in the packet filter to address your rather peculiar use case. What I read of how you're trying to setup things is that you want it to work like so: B.B.B.x -> A.A.A.Address -> Wine If your NAT rule is not changing the source information (I believe that's the "MASQUERADE" option) then the packet is being dropped because Wine is detecting that the packet is coming in on the wrong interface. That is how an interface-specific bind on Windows is supposed to work. How Wine used to behave is to make a Unix-like interface-specific bind (which works differently than on Windows), which would allow that packet from the wrong interface. To operate in a Windows-like way Wine now binds to 0.0.0.0 and uses a Linux Socket Filter to screen packets that come in to make sure they're on the correct interface. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #8 from Erich Hoover <ehoover(a)mines.edu> 2013-02-19 15:24:24 CST --- Sorry I forgot to say this in my earlier message, but if you send me your iptables configuration then I can use that to help figure out the problem. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #9 from Bruno Jesus <00cpxxx(a)gmail.com> 2013-04-20 22:16:14 CDT --- Invalid then? Since wine now implements the same behavior from windows. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #10 from Erich Hoover <ehoover(a)mines.edu> 2013-05-06 15:55:39 CDT --- (In reply to comment #9)
Invalid then? Since wine now implements the same behavior from windows.
Unless we can get some more information then I would say so, it would be nice to go over his routing rules and make sure that we can get it to work though. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #11 from Erich Hoover <erich.e.hoover(a)gmail.com> --- Note: It's also possible that this bug was fixed by commit 74010aa0e774b8b4e32455e6a42306f714ee66dd. If this is still an issue I would like to know. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #12 from decimusmaximus(a)seznam.cz --- Hello, unfortunately bug is not fixed, even after a year. Tested on Wine 1.7.16 Problem is in the fact, that wine is listening on all interfaces (0.0.0.0) but traffic is filtered. Two interfaces: IF-A and IF-B, there is NAT (masquerading) running. IF-A is LAN, IF-B is interface with public IP. I have created testing application to reproduce and investigate the problem. Application is listening on IF-B (public) only. When UDP datagram is sent from LAN (private) to IF-B (public) address, it is received on IF-A, NAT-ed to IF-B and received by application. Application is receiving UDP datagrams properly. Then the response is generated and sent back to client, but this response is filtered out by wine. Nothing is sent back. Application writes in log that UDP is received (from client's IP address) to 0.0.0.0 even it is listening only on specific IP (of IF-B). And this is the problem. Response is sent from binding 0.0.0.0 to target address from LAN (IF-A), but "it is not configured" to listen on this IF-A). (filtered!) If I understand it correctly, wine is listening on 0.0.0.0 and filters UDP datagrams according to bindings that are set by application. So if application does not want to listen on some interface, this traffic is filtered, but in this specific case (two interfaces, NAT) also the response is filtered out. Destination address of response belongs to network of IF-A (where application is not listening), but in this case response should be sent via IF-B, translated back in NAT and flow via IF-A to LAN network. But such UDP datagram is blocked by wine. I am afraid it is bad solution. When you check this in Windows, it is correctly listening on specific interface only, not on the all interfaces. Maybe there is another behaviour that prevents some applications to work properly in wine/linux (the reason why this filtering was added), but I am afraid this is also not correct solution and now another applications are/could be incompatible. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #13 from Erich Hoover <erich.e.hoover(a)gmail.com> --- (In reply to decimusmaximus from comment #12)
... If I understand it correctly, wine is listening on 0.0.0.0 and filters UDP datagrams according to bindings that are set by application. So if application does not want to listen on some interface, this traffic is filtered, but in this specific case (two interfaces, NAT) also the response is filtered out. Destination address of response belongs to network of IF-A (where application is not listening), but in this case response should be sent via IF-B, translated back in NAT and flow via IF-A to LAN network. But such UDP datagram is blocked by wine. ...
If you help me to do some testing I'd be happy to help fix this. This means that Wine is dropping the packet with the BPF that we're using to screen for interface-specific packets. Would it be possible for you to capture the packet meant for Wine with Wireshark and send me the packet? Also, what version of Wine are you running? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #14 from Erich Hoover <erich.e.hoover(a)gmail.com> --- (In reply to decimusmaximus from comment #12)
... Two interfaces: IF-A and IF-B, there is NAT (masquerading) running. IF-A is LAN, IF-B is interface with public IP. ...
I'd also like to reiterate that I need to know how you setup your masquerading to help with this issue. For the type of behavior it seems that you're expecting you need to be using "Destination NAT" instead of "Source NAT". For details on the distinction between the two this article may be helpful: http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO-6.html -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 facoptere(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |facoptere(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #15 from facoptere(a)gmail.com --- (copied from https://github.com/mirrors/wine/issues/8 ) I just updated my Debian and compiled latest wine version. What I can reproduce with Wine version 1.7.16-91-ged51082 : 1/ on Linux 3.13-1, an UDP server does not bind the IP address specified, but binds 0.0.0.0. 2/ on the same machine, but if the IP address is a virtual one (eth0:1 for example), Wine works properly and binds the IP address specified. 3/ there is no issue whatsoever with Linux kernel 2.6.32-5 for example. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #16 from Erich Hoover <erich.e.hoover(a)gmail.com> --- (In reply to facoptere from comment #15)
(copied from https://github.com/mirrors/wine/issues/8 )
I just updated my Debian and compiled latest wine version. What I can reproduce with Wine version 1.7.16-91-ged51082 : 1/ on Linux 3.13-1, an UDP server does not bind the IP address specified, but binds 0.0.0.0. 2/ on the same machine, but if the IP address is a virtual one (eth0:1 for example), Wine works properly and binds the IP address specified. 3/ there is no issue whatsoever with Linux kernel 2.6.32-5 for example.
Hi facoptere, this is intentional behavior to allow broadcast packets on sockets that are "bound" to a specific interface (broadcast packets only work when binding to 0.0.0.0). The new code will set a kernel option (not available on old kernels) that sets the packet to go out through the interface associated with the specified address. There's also a packet filter to only accept packets that come in through (or are destined for) the provided address. Could you give more detail on the specific problem you are running into? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #17 from Erich Hoover <erich.e.hoover(a)gmail.com> --- (In reply to facoptere from comment #15)
... 1/ on Linux 3.13-1, an UDP server does not bind the IP address specified, but binds 0.0.0.0. ...
This brings something to mind, is your application possibly trying to use getsockname() on these sockets? (I really need a lot more information to help you, but this would be something to look for in the log) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #18 from facoptere(a)gmail.com --- Hello, I did some further tests on another machine, I can reproduce the problem. With 2.6 linux kernel: ~$ uname -a Linux ... 2.6.32-5-686 #1 SMP Sun May 6 04:01:19 UTC 2012 i686 GNU/Linux ~$ wine --version wine-1.7.17-175-gc1bf61e ~$ sudo ifconfig eth0 Link encap:Ethernet HWaddr 00:13:a9:8f:f0:e0 inet addr:10.0.0.11 Bcast:10.0.0.255 Mask:255.255.255.0 ... ** I start the server with WINEDEBUG=+winsock,+winediag,+iphlpapi,+wininet,+icmp,+rpc,+ole ** (I put all debug flags where a least a bind() is done in the respective code) ~$ sudo lsof -P -n -i udp|grep -P '(wine|arma)' wineserve 5349 fab 304u IPv4 14973 0t0 UDP 10.0.0.11:2304 wineserve 5349 fab 310u IPv4 15131 0t0 UDP 10.0.0.11:2302 wineserve 5349 fab 319u IPv4 15555 0t0 UDP *:44237 arma2oase 5415 fab 231u IPv4 14973 0t0 UDP 10.0.0.11:2304 arma2oase 5415 fab 234u IPv4 14973 0t0 UDP 10.0.0.11:2304 arma2oase 5415 fab 238u IPv4 15131 0t0 UDP 10.0.0.11:2302 arma2oase 5415 fab 241u IPv4 15131 0t0 UDP 10.0.0.11:2302 arma2oase 5415 fab 249u IPv4 15555 0t0 UDP *:44237 So the server bound 10.0.0.11:2302 (the main UDP port) properly. Wine dump in winedebug-linux2.6.dmp.gz as attachment. Now with 3.13 linux kernel: ~$ uname -a Linux ... 3.13-1-686-pae #1 SMP Debian 3.13.7-1 (2014-03-25) i686 GNU/Linux ~$ wine --version wine-1.7.17-175-gc1bf61e ~$ sudo ifconfig eth0 Link encap:Ethernet HWaddr 00:13:a9:8f:f0:e0 inet addr:10.0.0.11 Bcast:10.0.0.255 Mask:255.255.255.0 ... ** I start the server with WINEDEBUG=+winsock,+winediag,+iphlpapi,+wininet,+icmp,+rpc,+ole ** ~$ sudo lsof -P -n -i udp|grep -P '(wine|arma)' wineserve 5126 fab 304u IPv4 13166 0t0 UDP *:2304 wineserve 5126 fab 310u IPv4 13167 0t0 UDP *:2302 wineserve 5126 fab 319u IPv4 14716 0t0 UDP *:43667 arma2oase 5193 fab 231u IPv4 13166 0t0 UDP *:2304 arma2oase 5193 fab 238u IPv4 13167 0t0 UDP *:2302 arma2oase 5193 fab 239u IPv4 13167 0t0 UDP *:2302 arma2oase 5193 fab 241u IPv4 13166 0t0 UDP *:2304 arma2oase 5193 fab 249u IPv4 14716 0t0 UDP *:43667 This time, the server bound * . Wine dump in winedebug-linux3.13.dmp.gz -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #19 from facoptere(a)gmail.com --- Created attachment 48355 --> http://bugs.winehq.org/attachment.cgi?id=48355 Wine-1.7.17 - Linux 2.6 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 facoptere(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #48355|Wine-1.7.17 - Linux 2.6 |Logs of Wine-1.7.17 with description| |Linux 2.6 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #20 from facoptere(a)gmail.com --- Created attachment 48356 --> http://bugs.winehq.org/attachment.cgi?id=48356 Logs of Wine-1.7.17 with Linux 3.13 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #21 from Erich Hoover <erich.e.hoover(a)gmail.com> --- (In reply to facoptere from comment #18)
... This time, the server bound * . Wine dump in winedebug-linux3.13.dmp.gz
Is the program not working properly or is it just that the application bound to "*"? Because that's the new intended behavior, other kernel options make it effectively bound to the requested address but it's bound to "*" to support broadcast packets. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #22 from facoptere(a)gmail.com --- The application works, but not properly since 0.0.0.0 is bound ;) Consequence of which I can't start 2 UDP servers on the same machine... If you know some sysctl options, assuming it's a Linux "feature", that tell Linux kernel to bind the IP address specified instead of the whole interfaces, please give them. I can't find them. If you know some Wine options that tell to respect arguments given in bind(), I would like to know them either. The application does not process any broadcast packets, and if it does I would have written 0.0.0.0 in the startup parameters since it seems to be a Windows prerequisite. According to me, it's a bug that can leads to some security issue, since a server can be accessed from some interfaces it does not meant to be. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #23 from Erich Hoover <erich.e.hoover(a)gmail.com> --- (In reply to facoptere from comment #22)
The application works, but not properly since 0.0.0.0 is bound ;) Consequence of which I can't start 2 UDP servers on the same machine...
You should be able to bind as many servers as you want to 0.0.0.0, when Wine activates this codepath it turns on SO_REUSEADDR on the socket so that other binds are not prohibited. What exactly happens when you try to start another UDP server?
If you know some sysctl options, assuming it's a Linux "feature", that tell Linux kernel to bind the IP address specified instead of the whole interfaces, please give them. I can't find them. If you know some Wine options that tell to respect arguments given in bind(), I would like to know them either.
At the moment you have to edit the Wine source to disable the option due to a problem with glibc not properly updating a header. If you edit dlls/ws2_32/socket.c line 166 by adding "#undef IP_UNICAST_IF" then it will go back to the old behavior.
The application does not process any broadcast packets, and if it does I would have written 0.0.0.0 in the startup parameters since it seems to be a Windows prerequisite.
Unfortunately we don't know at bind-time whether the application needs broadcast packets, so this option is enabled on all UDP sockets that are bound to a specific interface.
According to me, it's a bug that can leads to some security issue, since a server can be accessed from some interfaces it does not meant to be.
Wine sets the kernel option IP_UNICAST_IF to ensure that outbound packets go out the requested interface and it also configures a Linux Packet Filter to only accept packets on the interface you requested. Unless you are doing something really screwy with your routing table then the application is only going to see packets from the interface that was specified (this included broadcast packets, broadcast packets that come in on the wrong interface will be dropped). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #24 from facoptere(a)gmail.com --- (In reply to Erich Hoover from comment #23)
(In reply to facoptere from comment #22)
The application works, but not properly since 0.0.0.0 is bound ;) Consequence of which I can't start 2 UDP servers on the same machine...
You should be able to bind as many servers as you want to 0.0.0.0, when Wine activates this codepath it turns on SO_REUSEADDR on the socket so that other binds are not prohibited. What exactly happens when you try to start another UDP server?
The server that binds the primary IP, binds obviously 0.0.0.0 and so catches all the UDP traffic. The other server, which bound properly the second (virtual) IP, does not work anymore after that. BTW, the 2 servers run in separate unix accounts, separate windows "c:" drives, and there are 2 /usr/local/bin/wineserver running, that may explain the situation. The 2 servers need some regular restarts at different times. ...
If you know some Wine options that tell to respect arguments given in bind(), I would like to know them either.
At the moment you have to edit the Wine source to disable the option due to a problem with glibc not properly updating a header. If you edit dlls/ws2_32/socket.c line 166 by adding "#undef IP_UNICAST_IF" then it will go back to the old behavior.
Thanks a lot for the tip. I will have a look at this. ...
Wine sets the kernel option IP_UNICAST_IF to ensure that outbound packets go out the requested interface and it also configures a Linux Packet Filter to only accept packets on the interface you requested. Unless you are doing something really screwy ...
I use shorewall as firewall. I don't know whether this meets the "screwy" definition. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #25 from Erich Hoover <erich.e.hoover(a)gmail.com> --- (In reply to facoptere from comment #24)
... The server that binds the primary IP, binds obviously 0.0.0.0 and so catches all the UDP traffic. The other server, which bound properly the second (virtual) IP, does not work anymore after that. BTW, the 2 servers run in separate unix accounts, separate windows "c:" drives, and there are 2 /usr/local/bin/wineserver running, that may explain the situation. The 2 servers need some regular restarts at different times.
I'll have to look into this a little bit, it's possible that you're encountering an edge case that we didn't consider.
... I use shorewall as firewall. I don't know whether this meets the "screwy" definition.
Nope, that's fine. You would know if you were doing screwy things with your routing table :) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #26 from Bruno Jesus <00cpxxx(a)gmail.com> --- Can anyone provide sample source code to reproduce the issue here? With proper steps also. This would help other people to reproduce and study it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=33008 --- Comment #27 from Austin English <austinenglish(a)gmail.com> --- This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.51 or newer) wine? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=33008 tokktokk <fdsfgs(a)krutt.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs(a)krutt.org -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=33008 James <James(a)superbug.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |50499 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=33008 arisu+winebz(a)arisu.eu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |arisu+winebz(a)arisu.eu.org -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 KRosUser <kyle.kcsoftwares@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle.kcsoftwares@gmail.com --- Comment #28 from KRosUser <kyle.kcsoftwares@gmail.com> --- Seems related to bug50499 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=33008 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.winehq.org/show | |_bug.cgi?id=59682 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (3)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla
-
WineHQ Bugzilla