http://bugs.winehq.org/show_bug.cgi?id=24357
--- Comment #4 from michael 415fox@gmail.com 2010-09-13 18:11:16 CDT --- I'd like to point out that there are two separate bugs here:
1. Special permission bug. 2. IcmpSendEcho doesn't work in a thread.
The first bug is the cause of many problems. Another bug I'm working on is caused by ptrace requiring a special capability, CAP_SYS_PTRACE. For this bug, wineserver (and maybe wine-preloader) needs the capability CAP_NET_RAW.
Either way, if you run as root, or give the necessary capabilities to wine, you won't see the permissions problem reported by GyB.
However, even running as root or with capabilities, there is still this second bug. You can see it in the relay output like:
001f:Ret KERNEL32.GetCurrentThreadId() retval=0000001f ret=004029f9 001f:Call iphlpapi.IcmpSendEcho(0013c268,fdfe4150,00000000,00000000,00a4e9a0,00a4e9a8,0000001c,000007d0) ret=00402f61 001f:Ret iphlpapi.IcmpSendEcho() retval=00000000 ret=00402f61
This is the IcmpSendEcho call running inside of a thread. retval=0 means that it didn't get any replies after a timeout of 2000ms (2 seconds).
At this point the MSDN documentation says you should call GetLastError to see what went wrong. Unfortunately, whoever wrote Tracer.exe didn't bother to do that one so there's no way to see in the +relay dump why it thinks it didn't work out.
One other thing I thought was weird was the address: fdfe4150. This comes from an earlier call to:
0009:Call ws2_32.inet_addr(004367b0 "80.65.254.253") ret=00403b0b 0009:Ret ws2_32.inet_addr() retval=fdfe4150 ret=00403b0b
So it converted the string "80.65.254.253" to the hex value 0xfdfe4150. I would think that the hex value should be 0x5041fefd since 0x50 = 80 0x41 = 65 0xfe = 254 0xfd = 253 But maybe this is just my lack of understanding of windows. Maybe it just represents the addresses backwards from what's normal. I couldn't find any clear documentation on this. All I found was:
http://msdn.microsoft.com/en-us/library/aa366055(v=VS.85).aspx
Which defines the binary representation as: typedef struct { union { struct { u_char s_b1,s_b2,s_b3,s_b4; } S_un_b; struct { u_short s_w1,s_w2; } S_un_w; u_long S_addr; } S_un; } IPAddr;
Another thought I had was that the timers used to implement the timeout don't work right inside of a thread. For example I ran the program for exactly 10 seconds and found that it pinged a give address 17 times. At 2 seconds per ping it should have only been 5 times.