Unexpected log from `cgroup_skb`

[hzxuzhonghu]

What happened:

time="2025-04-28T03:03:23Z" level=info msg="[PROBE] ERR: on data: bpf_sk_storage_get failed\n" subsys=ebpf
time="2025-04-28T03:03:23Z" level=info msg="[PROBE] ERR: on data: bpf_sk_storage_get failed\n" subsys=ebpf

This is the complete logs from kmesh while a httpbin pod restarted

time="2025-04-28T03:09:46Z" level=info msg="default/httpbin-55ffdcd94-4hsfr: enable Kmesh manage" subsys=manage_controller
time="2025-04-28T03:09:46Z" level=info msg="[PROBE] ERR: on data: bpf_sk_storage_get failed\n" subsys=ebpf
time="2025-04-28T03:09:46Z" level=info msg="add annotation for pod default/httpbin-55ffdcd94-4hsfr" subsys=manage_controller
time="2025-04-28T03:09:46Z" level=info msg="[PROBE] ERR: on data: bpf_sk_storage_get failed\n" subsys=ebpf
time="2025-04-28T03:09:46Z" level=info msg="[AUTH] ERR: xdp: auth offloaded" subsys=ebpf
time="2025-04-28T03:09:47Z" level=info msg="[AUTH] ERR: xdp: auth offloaded" subsys=ebpf
time="2025-04-28T03:09:47Z" level=info msg="default/httpbin-55ffdcd94-ls8gg: enable Kmesh manage" subsys=manage_controller
time="2025-04-28T03:09:47Z" level=info msg="[PROBE] ERR: on data: bpf_sk_storage_get failed\n" subsys=ebpf
time="2025-04-28T03:09:47Z" level=info msg="add annotation for pod default/httpbin-55ffdcd94-ls8gg" subsys=manage_controller
time="2025-04-28T03:09:47Z" level=info msg="default/httpbin-55ffdcd94-4hsfr: Pod managed by Kmesh is deleted" subsys=manage_controller
time="2025-04-28T03:09:48Z" level=info msg="[AUTH] ERR: xdp: auth offloaded" subsys=ebpf
time="2025-04-28T03:09:49Z" level=info msg="[AUTH] ERR: xdp: auth offloaded" subsys=ebpf

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• Kmesh version:
• Kmesh mode(kmesh has Kernel-Native Mode and Duel-Engine Mode):
• Istio version:
• Kernel version:
• Others:

[hzxuzhonghu]

cc @yp969803

[yp969803]

time="2025-04-28T03:03:23Z" level=info msg="[PROBE] ERR: on data: bpf_sk_storage_get failed\n" subsys=ebpf

this can occur if the connection was already established before starting the monitoring, hence sk_storage is not present in the map @hzxuzhonghu

[yp969803]

sk_storage is put on the map at the start of the connection

[yp969803]

We can remove this log if u want, this is not a bug

[hzxuzhonghu]

This is unexcpected, i figgurred out it is the packet to 929, simulated by kmesh. We should skip processing it.

[yp969803]

static inline bool is_managed_by_kmesh_skb(struct __sk_buff *skb)
{
    struct manager_key key = {0};
    if (skb->family == AF_INET)
        key.addr.ip4 = skb->local_ip4;
    if (skb->family == AF_INET6) {
        if (is_ipv4_mapped_addr(skb->local_ip6))
            key.addr.ip4 = skb->local_ip6[3];
        else
            IP6_COPY(key.addr.ip6, skb->local_ip6);
    }

    int *value = bpf_map_lookup_elem(&map_of_manager, &key);
    if (!value)
        return false;
    return (*value == 0);
}

I am using this code to filter the packets @hzxuzhonghu \

[hzxuzhonghu]

Not right, we should check the dst ip + dst port not equal to 929 and 930

[yp969803]

This is same for sock_ops programs should I change that also

[hzxuzhonghu]

A litte different, let me tell you later

[hzxuzhonghu]

/assign