Watchdog monitoring a UNIX domain socket, triggering events on specific content

I'm on the embedded platform (mipsel architecture, Linux kernel 2.6), where I need to control the IPC between two closed-source processes (router firmware) in order to respond to a specific event (dynamic IP change due to reconnecting DSL), That What I have discovered so far through strace is that whenever the IP changes, the DSL daemon writes a special message to the UNIX domain socket attached to a specific file name. The message is consumed by another daemon.

Now here is my requirement: I want to monitor the flow of data through this particular UNIX domain socket and fire an event (call the shell script) if a specific message is detected. I tried to control the file name using inotify, but it does not work in socket files. I know that I can constantly work with strace, filter its output and respond to changes in the filtered log file, but this would be too difficult a decision, because strace really slows down the system. I also know that I can just poll the change of IP address via cron, but I want a watchdog, not a poll. And I am interested to know if there is a tool that can specifically monitor UNIX domain sockets and respond to specific messages flowing in a predetermined direction. I am assuming something similar to inotifywait, i.e. The tool must wait for a specific event and then exit, so I can respond to the event and return to the tool again, waiting for the next event of the same type.

Is there any existing Linux tool capable of doing this? Or is there a simple C code for a standalone binary that I could compile on my platform (uClibc, not glibc)? I am not a C expert, but I can run the make file. Using binary code from the shell is not a problem, I know enough about shell programming.

+4
source share
2 answers

Some time has passed since I dealt with this topic, and actually could not verify what my friend, Denis Vlasenko , accompanying Busybox, proposed as a solution for me several months ago. Since I just checked my StackOverflow account and saw this question again, let me share my thoughts with you. Maybe this is useful for someone:

One relatively easy hack I can offer is this:

I assume that you have a working server application that opened a listening socket for a Unix domain (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 to it for new client connections
  • for each such connection, open another connection with /tmp/some.socket1 with the original server process.
  • pump data (client ↔ server) for the resulting pairs of sockets (the code for this is very similar to the telnetd server) until the EOF is on both sides.

While you are pumping data, it’s easy to view it, save it, and even change it if you need to.

The disadvantage is that this sniffer program must be restarted each time the original server program is restarted.

This is similar to what Celada answered. Thanks to him! However, Denys answer was a bit more specific.

I asked:

It sounds hacked, yes, due to the need to reboot, but possible. I am not a C programmer, I continue to wonder if you know a command line tool that can do pass-through and logging event-based work for me. I have one guy from our project in mind who could crack a little C for this, but I'm not sure if he likes to do this. If there is anything in advance, I would prefer. Can it even be done with (a combination of) BusyBox applets, perhaps?

Denys answered again:

You need to build busybox with CONFIG_FEATURE_UNIX_LOCAL=y .

Start the capture server:

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

Where script.sh is a simple end-to-end connection to the "source server":

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

As an example, I added hexadecimal logging to the file ( -o FILE ).

Test it by running the emulated "source server":

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

and connecting to the "interception server":

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

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

If you need more complex processing, replace the nc call in script.sh with the user program.

+5
source

I don’t think there is anything that will allow you to sniff out UNIX socket traffic. Here are a few options:

  • Make sure the sender process connects to a different socket where you are listening. Also connect to the source socket as a client. When receiving data, pay attention to the data that you want to notice, and also transfer everything along with the original socket.
  • Monitoring the system to change the IP address yourself using the netlink socket ( RTM_NEWADDR , RTM_NEWLINK , etc.).
  • Run ip monitor as an external process and take action when it writes messages about added and deleted IP addresses on its standard output.
0
source

Source: https://habr.com/ru/post/1384820/


All Articles