how to get ipv6 tuple info for -m text

[chilli13]

As feat #684 and #695 already support get 4-tuple info for decrypt ssl data from UUID. But the kernel hook function such as sys_connect, __sys_accept4, tcp_v4_destroy_sock only works for ipv4 connection, is there any solutions to obtain ipv6 tuple info? Thks @Asphaltt

{"time":"2025-01-02T14:43:25+08:00","message":"UUID:18605_18605_nginx_32_0_192.168.10.201:35740-192.168.10.41:443, Name:HTTPRequest, Type:1, Length:81\nGET /2.txt HTTP/1.1\r\nHost: zhm.test.com\r\nAccept: */*\r\nUser-Agent: curl/7.71.1\r\n\r\n"}

code kretprobe_connect only deal with AF_INET, and AF_INET6 packet will be dropped.

static __inline int kretprobe_connect(struct pt_regs *ctx, int fd, struct sock *sk, const bool active) {
    ... ...
    u16 address_family = 0;
   ... ...
       bpf_probe_read_kernel(&address_family, sizeof(address_family), &sk->__sk_common.skc_family);
    if (address_family != AF_INET) {
        return 0;
    }
  ... ...

[dosubot]

To obtain IPv6 tuple information in the kretprobe_connect function, you need to modify the function to handle AF_INET6 connections. Here are the steps you can take:

1. Check for AF_INET6: Modify the check for the address family to include AF_INET6. This will allow the function to process IPv6 connections.

2. Read IPv6 Addresses: For IPv6, you need to read the source and destination addresses using the appropriate fields in the socket structure:

   • Use sk->__sk_common.skc_v6_rcv_saddr for the source IPv6 address.
   • Use sk->__sk_common.skc_v6_daddr for the destination IPv6 address.

3. Handle 128-bit Addresses: Since IPv6 addresses are 128 bits, ensure that you handle them correctly by reading them into an array of four 32-bit integers.

Here is a basic outline of how you might modify the function:

static __inline int kretprobe_connect(struct pt_regs *ctx, int fd, struct sock *sk, const bool active) {
    u64 current_pid_tgid = bpf_get_current_pid_tgid();
    u32 pid = current_pid_tgid >> 32;
    u64 current_uid_gid = bpf_get_current_uid_gid();
    u32 uid = current_uid_gid;
    u16 address_family = 0;

    bpf_probe_read_kernel(&address_family, sizeof(address_family), &sk->__sk_common.skc_family);
    if (address_family == AF_INET) {
        // Existing IPv4 handling code
    } else if (address_family == AF_INET6) {
        u32 src_ip6[4], dst_ip6[4];
        bpf_probe_read_kernel(&src_ip6, sizeof(src_ip6), &sk->__sk_common.skc_v6_rcv_saddr);
        bpf_probe_read_kernel(&dst_ip6, sizeof(dst_ip6), &sk->__sk_common.skc_v6_daddr);
        
        // Process the IPv6 addresses and ports
        // Add your logic here to handle the IPv6 tuple
    } else {
        return 0;
    }

    // Continue with the rest of the function
}

By implementing these changes, you should be able to capture IPv6 tuple information alongside IPv4. This approach aligns with the suggestions in the pull requests you mentioned, which aim to enhance IPv6 support by modifying existing hooks or implementing new ones ^[1].

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[chilli13]

But hook function __sys_accept4 only support ipv4 connect event @dosu
SEC("kretprobe/__sys_accept4")
int retprobe_accept4(struct pt_regs* ctx) {

[dosubot]

To extend the retprobe_accept4 function to support IPv6 connections, you need to modify it to handle AF_INET6 connections similarly to how you would handle them in the kretprobe_connect function. Here are the steps you can take:

1. Check for AF_INET6: Modify the function to check for the AF_INET6 address family, allowing it to process IPv6 connections.

2. Read IPv6 Addresses: For IPv6, read the source and destination addresses using the appropriate fields in the socket structure:

   • Use sk->__sk_common.skc_v6_rcv_saddr for the source IPv6 address.
   • Use sk->__sk_common.skc_v6_daddr for the destination IPv6 address.

3. Handle 128-bit Addresses: Since IPv6 addresses are 128 bits, handle them correctly by reading them into an array of four 32-bit integers.

Here's a basic outline of how you might modify the function:

SEC("kretprobe/__sys_accept4")
int retprobe_accept4(struct pt_regs* ctx) {
    struct sock *sk;
    u16 address_family = 0;

    // Retrieve the socket and address family
    bpf_probe_read_kernel(&sk, sizeof(sk), /* appropriate method to get sk */);
    bpf_probe_read_kernel(&address_family, sizeof(address_family), &sk->__sk_common.skc_family);

    if (address_family == AF_INET) {
        // Existing IPv4 handling code
    } else if (address_family == AF_INET6) {
        u32 src_ip6[4], dst_ip6[4];
        bpf_probe_read_kernel(&src_ip6, sizeof(src_ip6), &sk->__sk_common.skc_v6_rcv_saddr);
        bpf_probe_read_kernel(&dst_ip6, sizeof(dst_ip6), &sk->__sk_common.skc_v6_daddr);

        // Process the IPv6 addresses and ports
        // Add your logic here to handle the IPv6 tuple
    } else {
        return 0;
    }

    // Continue with the rest of the function
}

By implementing these changes, you should be able to capture IPv6 connection events in the __sys_accept4 function. This approach is consistent with handling IPv6 in other parts of the codebase, such as in the tcp_sendmsg and udp_sendmsg functions ^[1].

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[chilli13]

kernel function __sys_accept4 can not handle ipv6 connect, I think we should found another kernel function to hook to get ipv6 tuple

[cfc4n]

kernel function __sys_accept4 can not handle ipv6 connect, I think we should found another kernel function to hook to get ipv6 tuple

The answer of AI robot is correct. You can refer to it. After optimization and repair, can you mention a PR?

[yuweizzz]

I had a simple test, we can get the ip info in same function.

         coredns-64279   [000] ...21 620501.044761: bpf_trace_printk: @ sockaddr FM :10

         coredns-64279   [000] ...21 620501.044762: bpf_trace_printk: port=8181 port=45364

         coredns-64279   [000] ...21 620501.044764: bpf_trace_printk: saddr=0.0.0.0 daddr=0.0.0.0

         coredns-64279   [000] ...21 620501.044766: bpf_trace_printk: saddr=0000:0000:0000:0000:0000:ffff:0a00:004f daddr=0000:0000:0000:0000:0000:ffff:0a00:00f9

         coredns-2097    [000] ...21 620501.490582: bpf_trace_printk: @ sockaddr FM :10

         coredns-2097    [000] ...21 620501.490584: bpf_trace_printk: port=8080 port=41546

         coredns-2097    [000] ...21 620501.490586: bpf_trace_printk: saddr=0.0.0.0 daddr=0.0.0.0

         coredns-2097    [000] ...21 620501.490587: bpf_trace_printk: saddr=0000:0000:0000:0000:0000:ffff:7f00:0001 daddr=0000:0000:0000:0000:0000:ffff:7f00:0001

         coredns-64279   [001] ...21 620501.490594: bpf_trace_printk: @ sockaddr FM :2

         coredns-64279   [001] ...21 620501.490596: bpf_trace_printk: port=41546 port=8080

         coredns-64279   [001] ...21 620501.490597: bpf_trace_printk: saddr=0.0.0.0 daddr=0.0.0.0

         coredns-64279   [001] ...21 620501.490598: bpf_trace_printk: saddr=0000:0000:0000:0000:0000:ffff:7f00:0001 daddr=0000:0000:0000:0000:0000:ffff:7f00:0001