I have a linux-based cellular device that every 4-6 weeks begins pinging Google IP addresses 10-12x every minute. This increased pinging begins and ends seemingly randomly, lasts for a few days before returning to normal (i.e., no pinging), and the ping requests appear to receive successful responses without exception. The IP addresses used for the requests change each time a new increase in ping activity begins although the pings appear to always use Google addresses.

Is there any way to find the application/program that is initiating the pings on my device? I ran

grep -r "Google"

hoping to find a list or database of some sort which the device uses as a source for the different IP addresses, but have not had any luck. Any suggestions/feedback/guidance would be greatly appreciated.

  • Do you use chrome (a.k.a.: chromium, the google provided web navigator) in your device ?
    – ImHere
    Jan 12 '20 at 16:44
  • What OS android or other? (it may be relevant) Jan 12 '20 at 17:10
  • Do you have CONFIG_FTRACE enabled in your kernel? You might have a copy of the config in /boot, or you can run mount -t debugfs debugfs /sys/kernel/debug to check,
    – icarus
    Jan 12 '20 at 18:26

Assuming that ftrace is configured in the kernel and you have root access you can use the kernel tracing facilities.

There are newer tools available, in particular bpftrace, but embedded devices often lack the needed space to install the needed dependencies. This solution uses ftrace which has been available for many years. This is just using the raw files, there are tools which will automate some of these steps.

If the debugfs is not already mounted then mount it

[ -e /sys/kernel/debug/tracing/README ] || mount -t debugfs debugfs /sys/kernel/debug

Disable tracing, set the report to trace functions, set the functions to monitor

 cd /sys/kernel/debug/tracing
 echo 0 > tracing_on
 echo function > current_tracer
 echo ping_init_sock > set_ftrace_filter
 echo sock_sendmsg >> set_ftrace_filter # Optional, omit if ping_init_sock gives results

Enable tracing

 echo 1 > tracing_on

wait for the ping events to happen, then examine what is in the trace file.

cat trace
# tracer: function
# entries-in-buffer/entries-written: 56/56   #P:1
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
            ping-3085  [000] .... 8035797.349326: ping_init_sock <-inet_create
            ping-3085  [000] .... 8035797.349352: ping_init_sock <-inet6_create
            ping-3085  [000] .... 8035797.349739: sock_sendmsg <-___sys_sendmsg
            ping-3085  [000] .... 8035797.349764: sock_sendmsg <-___sys_sendmsg
            ping-3085  [000] .... 8035797.365248: sock_sendmsg <-__sys_sendto
            ping-3085  [000] .... 8035797.365486: sock_sendmsg <-__sys_sendto
            ping-3085  [000] .... 8035797.379917: sock_sendmsg <-__sys_sendto
            ping-3085  [000] .... 8035797.387487: sock_sendmsg <-__sys_sendto

which show that PID 3085 is doing the ping. If you are lucky the process that does the pinging will be still running so you can find it in the ps output. If not then you may hope for it to have a recognizable name.

Failing both of those, then maybe https://github.com/brendangregg/perf-tools/blob/master/deprecated/execsnoop-proc can help.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.