Network events generated by a Windows app under wine are not traced

[dkogan]

Hi. I'm running a Windows application under wine. It does some TCP stuff. I can see the communication with strace, but with sysdig those events just aren't there. Basic sysdig filters such as 'evt.type = connect' and 'fd.ip = 192.168.x.y' return nothing relevant. I know that the application actually does those things because the device at that ip sees the traffic and, like I said, because strace sees this.

I'm making an assumption that the wine layer is somehow responsible. Is this expected? I can point you to the specific executable if that's helpful, but asking first seems like a good idea.

Thanks

[ldegio]

No, it's not expected, and I suspect the cause is the interaction with
wine as well.
My bet would be that wine implements networking in the kernel without
going through system calls, but that's not the case if strace can see it.

Loris

On 11/23/2014 8:54 PM, Dima Kogan wrote:

Hi. I'm running a Windows application under wine. It does some TCP
stuff. I can see the communication with strace, but with sysdig those
events just aren't there. Basic sysdig filters such as 'evt.type =
connect' and 'fd.ip = 192.168.x.y' return nothing relevant. I know
that the application actually does those things because the device at
that ip sees the traffic and, like I said, because strace sees this.

I'm making an assumption that the wine layer is somehow responsible.
Is this expected? I can point you to the specific executable if that's
helpful, but asking first seems like a good idea.

Thanks

—
Reply to this email directly or view it on GitHub
#278.

[dkogan]

Loris Degioanni notifications@github.com writes:

No, it's not expected, and I suspect the cause is the interaction with
wine as well.
My bet would be that wine implements networking in the kernel without
going through system calls, but that's not the case if strace can see it.

I just checked, and tcpdump appears to work ok too.

[dkogan]

It does appear to be wine-induced. I just tried this by using a windows build of libcurl (from http://www.paehl.com/open_source/?CURL_7.39.0 I got the "without SSL" binary). By doing a simple

curl example.com

sysdig can see everything. But

wine curl.exe example.com

does not see the communication. I don't have the cycles to look at this more deeply right now, so I'm afraid this is a patch-less report.

[dkogan]

Hi. I still don't have a fix, but at least I now know what the problem is. The core of the problem is that I'm running a 64-bit Linux install (Debian amd64), but wine is a 32-bit process. The same behavior (sysdig not seeing any events) can be reproduced by building a 32-bit application, and trying to sysdig it. For instance, say I have tst.c:

#include <stdio.h>
#include <stdlib.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main(int argc, char* argv[])
{

    while(1)
    {
        int fd = open("/dev/null", O_RDONLY);
        close(fd);
        sleep(1);
    }

    return 0;
}

Then I build it with

gcc -m32 -o tst tst.c

Sysdig sees no events from this application; strace does see events. This is a general issues with Linux tracepoints. I see the same no-events-seen behavior when using tracepoints more directly by poking around in

/sys/kernel/debug/tracing

This possibly isn't fixable without heavy kernel mods. I may look at some point, but in the meantime it's probably OK to close this issue, which I'm doing now. Thanks

[kalgnana]

Hi. I still don't have a fix, but at least I now know what the problem is. The core of the problem is that I'm running a 64-bit Linux install (Debian amd64), but wine is a 32-bit process. The same behavior (sysdig not seeing any events) can be reproduced by building a 32-bit application, and trying to sysdig it. For instance, say I have tst.c:

#include <stdio.h>
#include <stdlib.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int main(int argc, char* argv[])
{

    while(1)
    {
        int fd = open("/dev/null", O_RDONLY);
        close(fd);
        sleep(1);
    }

    return 0;
}

Then I build it with

gcc -m32 -o tst tst.c

Sysdig sees no events from this application; strace does see events. This is a general issues with Linux tracepoints. I see the same no-events-seen behavior when using tracepoints more directly by poking around in

/sys/kernel/debug/tracing

This possibly isn't fixable without heavy kernel mods. I may look at some point, but in the meantime it's probably OK to close this issue, which I'm doing now. Thanks

I am facing the same issue with 5.4.0-52-generic kernel version. Which is the right forum to raise this issue or track the updates.