Snoop interprocess communications

Question

Has anyone tried to create a log file of interprocess communications? Could someone give me a little advice on the best way to achieve this?

Baby

What kind of communication? TCP sockets? Unix sockets? DBUS? Shared memory? – Liederkranz

Thanks guys. Actually I don't know! I want to change one interface card for another. I was hoping to log the API calls to the original driver and analyze the output to understand the ins and outs of it and then to translate this to the API of another card – Baby

Network card control isn't IPC, it is inside the kernel. – Liederkranz

Hi thejh, thanks. This is actually a GPIB card it's used with scientific instruments but you are absolutely right, it's probably in the kernel. Could you help me rephrase my question? Should I just say "how do I log communication to a kernel driver"? Thanks again! – Baby

I'm not a kernel expert, but I would rephrase the question to what you proposed. – Liederkranz

whoops, that's "thanks" and I was just wondering if anyone can recommend the best way to do this? Can I kill my own thread before reposting – Baby

@Patrick, you should find a close below your tags...to close a question – Vestpocket

IPC is also in the kernel, it's just that network communication is not generally considered IPC. – Product

Answer 1

The question is not quite clear, and comments make it less clear, but anyway...

The two things to try first are ipcs and strace -e trace=ipc.

Crymotherapy

nice tools. Is not clear to me though how you would use ipcs. – Maltz

Answer 2

If you want to log all IPC(seems very intensive), you should consider instrumentation.

Their are a lot of good tools for this, check out PIN in perticular, this section of the manual;

In this example, we show how to do more selective instrumentation by examining the instructions. This tool generates a trace of all memory addresses referenced by a program. This is also useful for debugging and for simulating a data cache in a processor.

If your doing some heavy weight tuning and analysis, check out TAU (Tuning and analysis utilitiy).

Haematocryal

Answer 3

Communication to a kernel driver can take many forms. There is usually a special device file for communication, or there can be a special socket type, like NETLINK. If you are lucky, there's a character device to which read() and write() are the sole means of interaction - if that's the case then those calls are easy to intercept with a variety of methods. If you are unlucky, many things are done with ioctls or something even more difficult.

However, running 'strace' on the program using the kernel driver to communicate can reveal just about all it does - though 'ltrace' might be more readable if there happens to be libraries the program uses for communication. By tuning the arguments to 'strace', you can probably get a dump which contains just the information you need:

• First, just eyeball the calls and try to figure out the means of kernel communication
• Then, add filters to strace call to log only the kernel communication calls
• Finally, make sure strace logs the full strings of all calls, so you don't have to deal with truncated data

The answers which point to IPC debugging probably are not relevant, as communicating with the kernel almost never has anything to do with IPC (atleast not the different UNIX IPC facilities).

Brag