socketsunixdnsunix-socketwatchdog

Watchdog monitoring UNIX domain socket, triggering events upon specific content

I am on an embedded platform (mipsel architecture, Linux 2.6 kernel) where I need to monitor IPC between two closed-source processes (router firmware) in order to react to a certain event (dynamic IP change because of DSL reconnect). What I found out so far via strace is that whenever the IP changes, the DSL daemon writes a special message into a UNIX domain socket bound to a specific file name. The message is consumed by another daemon.

Now here is my requirement: I want to monitor the data flow through that specific UNIX domain socket and trigger an event (call a shell script) if a certain message is detected. I tried to monitor the file name with inotify, but it does not work on socket files. I know I could run strace all the time, filtering its output and react to changes in the filtered log file, but that would be too heavy a solution because strace really slows down the system. I also know I could just poll for the IP address change via cron, but I want a watchdog, not a polling solution. And I am interested in finding out whether there is a tool which can specifically monitor UNIX domain sockets and react to specific messages flowing through in a predefined direction. I imagine something similar to inotifywait, i.e. the tool should wait for a certain event, then exit, so I can react to the event and loop back into starting the tool again, waiting for the next event of the same type.

Is there any existing Linux tool capable of doing that? Or is there some simple C code for a stand-alone binary which I could compile on my platform (uClibc, not glibc)? I am not a C expert, but capable of running a Makefile. Using a binary from the shell is no problem, I know enough about shell programming.

Solution

  • It has been a while since I was dealing with this topic and did not actually get around to testing what an acquaintance of mine, Denys Vlasenko, maintainer of Busybox, proposed as a solution to me several months ago. Because I just checked my account here on StackOverflow and saw the question again, let me share his insights with you. Maybe it is helpful for somebody:

    One relatively easy hack I can propose is to do the following:

    I assume that you have a running server app which opened a Unix domain listening socket (say, /tmp/some.socket), and client programs connect to it and talk to the server.

    • rename /tmp/some.socket -> /tmp/some.socket1
    • create a new socket /tmp/some.socket
    • listen on it for new client connections
    • for every such connection, open another connection to /tmp/some.socket1 to original server process
    • pump data (client<->server) over resulting pairs of sockets (code to do so is very similar to what telnetd server does) until EOF from either side.

    While you are pumping data, it's easy to look at it, to save it, and even to modify it if you need to.

    The downside is that this sniffer program needs to be restarted every time the original server program is restarted.

    This is similar to what Celada also answered. Thanks to him as well! Denys's answer was a bit more concrete, though.

    I asked back:

    This sounds hacky, yes, because of the restart necessity, but feasible. Me not being a C programmer, I keep wondering though if you know a command line tool which could do the pass-through and protocolling or event-based triggering work for me. I have one guy from our project in mind who could hack a little C binary for that, but I am unsure if he likes to do it. If there is something pre-fab, I would prefer it. Can it even be done with a (combination of) BusyBox applet(s), maybe?

    Denys answered again:

    You need to build busybox with CONFIG_FEATURE_UNIX_LOCAL=y.

    Run the following as intercepting server:

     busybox tcpsvd -vvvE local:/tmp/socket 0 ./script.sh

    Where script.sh is a simple passthrough connection to the "original server":

     #!/bin/sh
 busybox nc -o /tmp/hexdump.$$ local:/tmp/socket1 0

    As an example, I added hex logging to file (-o FILE option).

    Test it by running an emulated "original server":

     busybox tcpsvd -vvvE local:/tmp/socket1 0 sh -c 'echo PID:$$'

    and by connecting to "intercepting server":

     echo Hello world | busybox nc local:/tmp/socket 0

    You should see "PID:19094" message and have a new /tmp/hexdump.19093 file with the dumped data. Both tcpsvd processes should print some log too (they are run with -vvv verbosity).

    If you need more complex processing, replace nc invocation in script.sh with a custom program.