Have a question about incoming call from bpftrace

[the-prachi]

Hi Team - I am running tcpconnect script on my machine, and was monitoring the incoming calls, and saw a weird call from /tmp/.mount_tpdeck-nIHkjg/mountroot/nix/store/sj7a9izfdplkds8ha6cygg5xwd3zw7-bpftrace/bin/bpftrace
I have bpftrace appimage located in usr/bin folder. Could you explain the reason for these calls from the above executable?

[viktormalik]

Hi, are you using the static binary provided with the release?

[danobi]

Yeah, looks like it.

The way appimages work is it mounts a squashfs image with the binary + all its deps inside. What you're seeing in /tmp/.mount.. is the squashfs mount.

[ajor]

bpftrace shouldn't be doing any networking though, right? (unless I'm misunderstanding the OP)

[viktormalik]

tcpconnect.bt is a bpftrace tool for tracing TCP connections on a machine.

[ajor]

I took the OP to mean that when they ran tcpconnect.bt, they saw TCP connections coming from /tmp/.mount.../bpftrace.

I'm not 100% sure what "incoming call from bpftrace" means though.

[the-prachi]

Thats correct. I am seeing tcpconnections from /tmp/.mount.../bpftrace consistently. And i want to understand what these connections are for?

[ajor]

bpftrace shouldn't be making any TCP connections as far as I'm aware. That sounds very odd to me.

Can you share the full output of tcpconnect.bt that shows these connections from bpftrace?

[the-prachi]

Here is an example inbound connection using inet_csk_accept, udp_rcvmsg:
Machine ub20x
Process id 1383
Protocol TCP
Local address 10.3.1.42
Local port 41210
Remote address 168.43.119.160
Command /tmp/.mount_ay-BJplpi/mountroot/nix/store/sj7a9iz8cwd5achy8ha6cygg5xwd3zw7-bpftrace/bin/bpftrace

[ajor]

That doesn't look like the output of the standard tcpconnect.bt tool. Are you using something else to get this data?

Could you please share the full bpftrace script and console output?

[the-prachi]

Here is the console output :

[0,TCP,172.26.43.167,36138,20.151.76.58,CLOSE,swapper/7,]
[0,TCP,172.26.43.167,41906,20.53.15.179,CLOSE,swapper/9,]
[0,TCP,172.26.43.167,50174,20.53.15.179,CLOSE,swapper/8,]
[3564539,TCP,172.26.43.167,45056,185.115.121.88,"",/tmp/.mount_ay-BJplpi/mountroot/nix/store/sj7a9iz8cwd5achy8ha6cygg5xwd3zw7-bpftrace/bin/bpftrace,]
[1024,TCP,127.0.0.1,40342,127.0.0.1,,himds,]

and here is the script:

kretprobe:inet_csk_accept       
{
    $sk = (struct sock *)retval;
    $inet_family = $sk->__sk_common.skc_family;

    if ($inet_family == AF_INET || $inet_family == AF_INET6) {
        $daddr = ntop(0);
        $saddr = ntop(0);
        if ($inet_family == AF_INET) {
            $daddr = ntop($sk->__sk_common.skc_daddr);
            $saddr = ntop($sk->__sk_common.skc_rcv_saddr);
        } else {
            $daddr = ntop(
                $sk->__sk_common.skc_v6_daddr.in6_u.u6_addr8);
            $saddr = ntop(
                $sk->__sk_common.skc_v6_rcv_saddr.in6_u.u6_addr8);
        }
        $lport = $sk->__sk_common.skc_num;
        printf("[%d,TCP,%s,%d,%s,%s,%s,]\n", pid, $saddr, $lport, $daddr, "", comm);
    }
}

[ajor]

That looks like tcpaccept not tcpconnect, but either way bpftrace shouldn't be doing any networking. I've run the script myself for a while and not seen anything from bpftrace.

My best guess is that it's somehow related to BCC's symbolication attempting to use debuginfod. If the DEBUGINFOD_URLS environmental variable is set then you could try unsetting it before running bpftrace and seeing if that helps.

Otherwise, if this is reproducible for you then I'd suggest the next step is to try to collect stack traces from bpftrace to understand where this is coming from.