Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Sometimes the tuple of the captured http2 packet is 0 #739

Open
huaixia777 opened this issue Feb 18, 2025 · 9 comments · May be fixed by #741
Open

Sometimes the tuple of the captured http2 packet is 0 #739

huaixia777 opened this issue Feb 18, 2025 · 9 comments · May be fixed by #741
Assignees
@cfc4n
Labels
🐞 bug Something isn't working

Comments

@huaixia777
Copy link

Hello!
When I use this tool to capture http2 packets, sometimes the tuple of the packets is 0, that is, 0.0.0.0:0-0.0.0.0:0.
And I have not stopped the running of the tool during the capture.

Here are the results of my run, this question seems to arise easily.
"DestroyConn success fd=5 pid=396386 tuple=192.168.10.201:41370-192.168.10.41:4443" printed before printing tuple information, maybe because the connection was destroyed when the tuple was fetched.

# ./ecapture-ctyun tls -i ens1f0 -d
2025-02-18T14:20:45+08:00 INF AppName="eCapture(旁观者)"
2025-02-18T14:20:45+08:00 INF HomePage=https://ecapture.cc
2025-02-18T14:20:45+08:00 INF Repository=https://github.com/gojue/ecapture
2025-02-18T14:20:45+08:00 INF Author="CFC4N <[email protected]>"
2025-02-18T14:20:45+08:00 INF Description="Capturing SSL/TLS plaintext without a CA certificate using eBPF. Supported on Linux/Android kernels for amd64/arm64."
2025-02-18T14:20:45+08:00 INF Version=linux_amd64:v0.9.3-20250210-dcfc3cf:x86_64
2025-02-18T14:20:45+08:00 INF Listen=localhost:28256
2025-02-18T14:20:45+08:00 INF eCapture running logs logger=
2025-02-18T14:20:45+08:00 INF the file handler that receives the captured event eventCollector=
2025-02-18T14:20:45+08:00 INF listen=localhost:28256
2025-02-18T14:20:45+08:00 INF https server starting...You can upgrade the configuration file via the HTTP interface.
2025-02-18T14:20:45+08:00 WRN Kernel version is less than 5.2, Process filtering parameters do not take effect such as pid/uid. kernel=4.19.90
2025-02-18T14:20:45+08:00 INF Kernel Info=4.19.90 Pid=396298
2025-02-18T14:20:45+08:00 INF BTF bytecode mode: non-CORE. btfMode=0
2025-02-18T14:20:45+08:00 INF master key keylogger has been set. eBPFProgramType=Text keylogger=
2025-02-18T14:20:45+08:00 INF module initialization. isReload=false moduleName=EBPFProbeOPENSSL
2025-02-18T14:20:45+08:00 INF Module.Run()
2025-02-18T14:20:45+08:00 INF origin versionKey="openssl 1.1.1f" versionKeyLower="openssl 1.1.1f"
2025-02-18T14:20:45+08:00 INF OpenSSL/BoringSSL version found Android=false library version="openssl 1.1.1f"
2025-02-18T14:20:45+08:00 INF Hook masterKey function ElfType=2 Functions=["SSL_get_wbio","SSL_in_before","SSL_do_handshake"] binrayPath=/lib64/libssl.so.1.1
2025-02-18T14:20:45+08:00 WRN Your kernel version is less than 5.2, GlobalVar is disabled, the following parameters will be ignored:[target_pid, target_uid, target_port]
2025-02-18T14:20:45+08:00 INF setupManagers eBPFProgramType=Text
2025-02-18T14:20:45+08:00 INF BPF bytecode file is matched. bpfFileName=user/bytecode/openssl_1_1_1d_kern_noncore_less52.o
2025-02-18T14:20:45+08:00 DBG upgrade check failed: local version is ahead of latest version
2025-02-18T14:20:46+08:00 INF perfEventReader created mapSize(MB)=4
2025-02-18T14:20:46+08:00 INF perfEventReader created mapSize(MB)=4
2025-02-18T14:20:46+08:00 INF module started successfully. isReload=false moduleName=EBPFProbeOPENSSL
2025-02-18T14:20:48+08:00 DBG AddConn success fd=5 pid=396386 tuple=192.168.10.201:41370-192.168.10.41:4443
2025-02-18T14:20:48+08:00 DBG GetConn fd=5 pid=396386
2025-02-18T14:20:48+08:00 DBG SSLDataEvent bio_type=1285 fd=5 pid=396386 tuple=192.168.10.201:41370-192.168.10.41:4443
2025-02-18T14:20:48+08:00 DBG GetConn fd=5 pid=396386
2025-02-18T14:20:48+08:00 DBG SSLDataEvent bio_type=1285 fd=5 pid=396386 tuple=192.168.10.201:41370-192.168.10.41:4443
2025-02-18T14:20:48+08:00 DBG GetConn fd=5 pid=396386
2025-02-18T14:20:48+08:00 DBG SSLDataEvent bio_type=1285 fd=5 pid=396386 tuple=192.168.10.201:41370-192.168.10.41:4443
2025-02-18T14:20:48+08:00 DBG GetConn fd=5 pid=396386
2025-02-18T14:20:48+08:00 DBG SSLDataEvent bio_type=1285 fd=5 pid=396386 tuple=192.168.10.201:41370-192.168.10.41:4443
2025-02-18T14:20:48+08:00 DBG GetConn fd=5 pid=396386
2025-02-18T14:20:48+08:00 DBG SSLDataEvent bio_type=1285 fd=5 pid=396386 tuple=192.168.10.201:41370-192.168.10.41:4443
2025-02-18T14:20:48+08:00 DBG GetConn fd=5 pid=396386
2025-02-18T14:20:48+08:00 DBG SSLDataEvent bio_type=1285 fd=5 pid=396386 tuple=192.168.10.201:41370-192.168.10.41:4443
2025-02-18T14:20:48+08:00 DBG GetConn fd=5 pid=396386
2025-02-18T14:20:48+08:00 DBG SSLDataEvent bio_type=1285 fd=5 pid=396386 tuple=192.168.10.201:41370-192.168.10.41:4443
2025-02-18T14:20:48+08:00 DBG DestroyConn success fd=5 pid=396386 tuple=192.168.10.201:41370-192.168.10.41:4443
2025-02-18T14:20:48+08:00 DBG GetConn fd=5 pid=396386
2025-02-18T14:20:48+08:00 DBG SSLDataEvent bio_type=1285 fd=5 pid=396386 tuple=[TUPLE_NOT_FOUND]
2025-02-18T14:20:49+08:00 ??? UUID:396386_396386_curl_5_1_192.168.10.201:41370-192.168.10.41:4443, Name:HTTP2Request, Type:2, Length:392

Frame Type      =>      SETTINGS
Frame StreamID  =>      0

Frame Type      =>      WINDOW_UPDATE
Frame StreamID  =>      0

Frame Type      =>      HEADERS
Frame StreamID  =>      1
header field ":method" = "GET"
header field ":path" = "/"
header field ":scheme" = "https"
header field ":authority" = "192.168.10.41:4443"
header field "user-agent" = "curl/7.71.1"
header field "accept" = "*/*"

Frame Type      =>      SETTINGS
Frame StreamID  =>      0

2025-02-18T14:20:49+08:00 ??? UUID:396386_396386_curl_5_0_192.168.10.201:41370-192.168.10.41:4443, Name:HTTP2Response, Type:4, Length:137

Frame Type      =>      SETTINGS
Frame StreamID  =>      0

Frame Type      =>      WINDOW_UPDATE
Frame StreamID  =>      0

Frame Type      =>      SETTINGS
Frame StreamID  =>      0

2025-02-18T14:20:49+08:00 ??? UUID:396386_396386_curl_5_0_0.0.0.0:0-0.0.0.0:0, Name:HTTP2Response, Type:4, Length:2089

Frame Type      =>      HEADERS
Frame StreamID  =>      1
header field ":status" = "200"
header field "server" = "nginx/1.21.5"
header field "date" = "Tue, 18 Feb 2025 06:20:48 GMT"
header field "content-type" = "text/html"

Frame Type      =>      DATA
Frame StreamID  =>      1
<html>
<head><title>Index of /</title></head>
<body>
<h1>Index of /</h1><hr><pre><a href="../">../</a>
<a href="bak/">bak/</a>                                               18-Dec-2024 09:59       -
<a href="http2_test/">http2_test/</a>                                        17-Feb-2025 15:10       -
<a href="iso/">iso/</a>                                               22-Jan-2025 15:22       -
<a href="small/">small/</a>                                             19-Dec-2024 15:35       -
<a href="temp/">temp/</a>                                              18-Dec-2024 10:25       -
<a href="1.txt">1.txt</a>                                              23-Dec-2024 10:20      12
<a href="config.txt">config.txt</a>                                         23-Dec-2024 09:19     87K
</pre><hr></body>
</html>

……

Expect your reply!
@dosubot DosuBot
Copy link

dosubot bot commented Feb 18, 2025

The issue of a connection tuple being logged as 0.0.0.0:0-0.0.0.0:0 in eCapture can occur when the connection information is not available at the time of logging. This can happen if the connection is destroyed before the tuple is fetched, as you suspected. The DestroyConn function removes the connection data from the internal maps, and if a subsequent attempt is made to retrieve the connection information, it may result in a default or placeholder value like 0.0.0.0:0-0.0.0.0:0 being logged [1].

To address this, you might want to ensure that the connection data is accessed and logged before the DestroyConn function is called. Additionally, reviewing the timing and sequence of events in your capture process could help in identifying if there are any adjustments needed to prevent premature destruction of connection data.

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot dosubot bot added the 🐞 bug Something isn't working label Feb 18, 2025
@huaixia777
Copy link
Author

Hello! I continued to test and found the same test environment and methods, the http1.1 protocol did not have this problem, http2 protocol occasionally has this problem

@cfc4n
Copy link
Member

cfc4n commented Feb 19, 2025

Please provide steps to reproduce

@huaixia777
Copy link
Author

My steps are as follows：

1.Run the ecapture
./ecapture-ctyun tls -i ens1f0

2.curl another machine's nginx server and its files
curl -k https://192.168.10.41:4443/
curl -k https://192.168.10.41:4443/1.txt

3.The result of ecapture is as follows

[root@xxx]# ./ecapture-ctyun tls -i ens1f0
2025-02-20T09:05:42+08:00 INF AppName="eCapture(旁观者)"
2025-02-20T09:05:42+08:00 INF HomePage=https://ecapture.cc
2025-02-20T09:05:42+08:00 INF Repository=https://github.com/gojue/ecapture
2025-02-20T09:05:42+08:00 INF Author="CFC4N <[email protected]>"
2025-02-20T09:05:42+08:00 INF Description="Capturing SSL/TLS plaintext without a CA certificate using eBPF. Supported on Linux/Android kernels for amd64/arm64."
2025-02-20T09:05:42+08:00 INF Version=linux_amd64:v0.9.3-20250210-dcfc3cf:x86_64
2025-02-20T09:05:42+08:00 INF Listen=localhost:28256
2025-02-20T09:05:42+08:00 INF eCapture running logs logger=
2025-02-20T09:05:42+08:00 INF the file handler that receives the captured event eventCollector=
2025-02-20T09:05:42+08:00 INF listen=localhost:28256
2025-02-20T09:05:42+08:00 INF https server starting...You can upgrade the configuration file via the HTTP interface.
2025-02-20T09:05:42+08:00 WRN Kernel version is less than 5.2, Process filtering parameters do not take effect such as pid/uid. kernel=4.19.90
2025-02-20T09:05:42+08:00 INF Kernel Info=4.19.90 Pid=813217
2025-02-20T09:05:42+08:00 INF BTF bytecode mode: non-CORE. btfMode=0
2025-02-20T09:05:42+08:00 INF master key keylogger has been set. eBPFProgramType=Text keylogger=
2025-02-20T09:05:42+08:00 INF module initialization. isReload=false moduleName=EBPFProbeOPENSSL
2025-02-20T09:05:42+08:00 INF Module.Run()
2025-02-20T09:05:42+08:00 INF origin versionKey="openssl 1.1.1f" versionKeyLower="openssl 1.1.1f"
2025-02-20T09:05:42+08:00 INF OpenSSL/BoringSSL version found Android=false library version="openssl 1.1.1f"
2025-02-20T09:05:42+08:00 INF Hook masterKey function ElfType=2 Functions=["SSL_get_wbio","SSL_in_before","SSL_do_handshake"] binrayPath=/lib64/libssl.so.1.1
2025-02-20T09:05:42+08:00 WRN Your kernel version is less than 5.2, GlobalVar is disabled, the following parameters will be ignored:[target_pid, target_uid, target_port]
2025-02-20T09:05:42+08:00 INF setupManagers eBPFProgramType=Text
2025-02-20T09:05:42+08:00 INF BPF bytecode file is matched. bpfFileName=user/bytecode/openssl_1_1_1d_kern_noncore_less52.o
2025-02-20T09:05:43+08:00 INF perfEventReader created mapSize(MB)=4
2025-02-20T09:05:43+08:00 INF perfEventReader created mapSize(MB)=4
2025-02-20T09:05:43+08:00 INF module started successfully. isReload=false moduleName=EBPFProbeOPENSSL
2025-02-20T09:05:48+08:00 ??? UUID:813369_813369_curl_5_1_192.168.10.201:60676-192.168.10.41:4443, Name:HTTP2Request, Type:2, Length:392

Frame Type      =>      SETTINGS
Frame StreamID  =>      0

Frame Type      =>      WINDOW_UPDATE
Frame StreamID  =>      0

Frame Type      =>      HEADERS
Frame StreamID  =>      1
header field ":method" = "GET"
header field ":path" = "/"
header field ":scheme" = "https"
header field ":authority" = "192.168.10.41:4443"
header field "user-agent" = "curl/7.71.1"
header field "accept" = "*/*"

Frame Type      =>      SETTINGS
Frame StreamID  =>      0

2025-02-20T09:05:48+08:00 ??? UUID:813369_813369_curl_5_0_192.168.10.201:60676-192.168.10.41:4443, Name:HTTP2Response, Type:4, Length:2226

Frame Type      =>      HEADERS
Frame StreamID  =>      1
header field ":status" = "200"
header field "server" = "nginx/1.21.5"
header field "date" = "Thu, 20 Feb 2025 01:05:47 GMT"
header field "content-type" = "text/html"

Frame Type      =>      SETTINGS
Frame StreamID  =>      0

Frame Type      =>      WINDOW_UPDATE
Frame StreamID  =>      0

Frame Type      =>      SETTINGS
Frame StreamID  =>      0

Frame Type      =>      DATA
Frame StreamID  =>      1
<html>
<head><title>Index of /</title></head>
<body>
<h1>Index of /</h1><hr><pre><a href="../">../</a>
<a href="bak/">bak/</a>                                               18-Dec-2024 09:59       -
<a href="http2_test/">http2_test/</a>                                        17-Feb-2025 15:10       -
<a href="iso/">iso/</a>                                               22-Jan-2025 15:22       -
<a href="small/">small/</a>                                             19-Dec-2024 15:35       -
<a href="temp/">temp/</a>                                              18-Dec-2024 10:25       -
<a href="1.txt">1.txt</a>                                              23-Dec-2024 10:20      12
<a href="config.txt">config.txt</a>                                         23-Dec-2024 09:19     87K
<a href="test.txt">test.txt</a>                                           24-Jan-2025 14:31      3M
</pre><hr></body>
</html>

2025-02-20T09:05:59+08:00 ??? UUID:813540_813540_curl_5_1_0.0.0.0:0-0.0.0.0:0, Name:HTTP2Response, Type:4, Length:44

Frame Type      =>      SETTINGS
Frame StreamID  =>      0

2025-02-20T09:05:59+08:00 ??? UUID:813540_813540_curl_5_0_0.0.0.0:0-0.0.0.0:0, Name:HTTP2Response, Type:4, Length:577

Frame Type      =>      SETTINGS
Frame StreamID  =>      0

Frame Type      =>      WINDOW_UPDATE
Frame StreamID  =>      0

Frame Type      =>      SETTINGS
Frame StreamID  =>      0

Frame Type      =>      HEADERS
Frame StreamID  =>      1
header field ":status" = "200"
header field "server" = "nginx/1.21.5"
header field "date" = "Thu, 20 Feb 2025 01:05:58 GMT"
header field "content-type" = "text/plain"
header field "content-length" = "12"
header field "last-modified" = "Mon, 23 Dec 2024 02:20:35 GMT"
header field "etag" = "\"6768c8f3-c\""
header field "accept-ranges" = "bytes"

Frame Type      =>      DATA
Frame StreamID  =>      1
hello world

……

I may not be doing anything special, in my tests, this problem comes up occasionally, but it also comes up fairly easily.
Perhaps if you test more, you will find this problem,what's your opinion?
Thanks!

@chilli13
Copy link
Contributor

same error occur on ubuntu 22.04(Linux cd-ubuntu 5.15.0-131-generic), with -d for more log, sometimes DestroyConn occurs before SSLDataEvent ? @dosu For https access, especially with http2, Is it possible for the kernel call SEC("kprobe/tcp_v4_destroy_sock") occurs before userspace call SEC("uretprobe/SSL_read") or SEC("uretprobe/SSL_write")?

sometimes found tuple failed for http2

root@cd-ubuntu:~/zhm/ecapture-gojue# ./bin/ecapture tls -d
2025-02-20T01:50:07Z INF AppName="eCapture(旁观者)"
2025-02-20T01:50:07Z INF HomePage=https://ecapture.cc
2025-02-20T01:50:07Z INF Repository=https://github.com/gojue/ecapture
2025-02-20T01:50:07Z INF Author="CFC4N <[email protected]>"
2025-02-20T01:50:07Z INF Description="Capturing SSL/TLS plaintext without a CA certificate using eBPF. Supported on Linux/Android kernels for amd64/arm64."
2025-02-20T01:50:07Z INF Version=linux_amd64:v0.9.3-20250214-d0245d5:5.15.0-131-generic
2025-02-20T01:50:07Z INF Listen=localhost:28256
2025-02-20T01:50:07Z INF eCapture running logs logger=
2025-02-20T01:50:07Z INF the file handler that receives the captured event eventCollector=
2025-02-20T01:50:07Z INF listen=localhost:28256
2025-02-20T01:50:07Z INF https server starting...You can upgrade the configuration file via the HTTP interface.
2025-02-20T01:50:07Z INF Kernel Info=5.15.168 Pid=30564
2025-02-20T01:50:07Z INF BTF bytecode mode: CORE. btfMode=0
2025-02-20T01:50:07Z INF master key keylogger has been set. eBPFProgramType=Text keylogger=
2025-02-20T01:50:07Z INF module initialization. isReload=false moduleName=EBPFProbeOPENSSL
2025-02-20T01:50:07Z INF Module.Run()
2025-02-20T01:50:07Z WRN OpenSSL/BoringSSL version not found. error="OpenSSL/BoringSSL version not found" soPath=/usr/lib/x86_64-linux-gnu/libssl.so.3
2025-02-20T01:50:07Z WRN Try to detect libcrypto.so.3. If you have doubts, See https://github.com/gojue/ecapture/discussions/675 for more information.
2025-02-20T01:50:07Z INF Try to detect imported libcrypto.so  imported=libcrypto.so.3 soPath=/usr/lib/x86_64-linux-gnu/libcrypto.so.3
2025-02-20T01:50:07Z INF origin versionKey="openssl 3.0.2" versionKeyLower="openssl 3.0.2"
2025-02-20T01:50:07Z INF OpenSSL/BoringSSL version found Android=false library version="openssl 3.0.2"
2025-02-20T01:50:07Z INF Hook masterKey function ElfType=2 Functions=["SSL_get_wbio","SSL_in_before","SSL_do_handshake"] binrayPath=/usr/lib/x86_64-linux-gnu/libssl.so.3
2025-02-20T01:50:07Z INF target all process.
2025-02-20T01:50:07Z INF target all users.
2025-02-20T01:50:07Z INF setupManagers eBPFProgramType=Text
2025-02-20T01:50:07Z INF BPF bytecode file is matched. bpfFileName=user/bytecode/openssl_3_0_0_kern_core.o
2025-02-20T01:50:07Z DBG upgrade check failed: local version is ahead of latest version
2025-02-20T01:50:08Z INF perfEventReader created mapSize(MB)=4
2025-02-20T01:50:08Z INF perfEventReader created mapSize(MB)=4
2025-02-20T01:50:08Z INF module started successfully. isReload=false moduleName=EBPFProbeOPENSSL
2025-02-20T01:50:09Z DBG AddConn success fd=5 pid=30573 tuple=192.168.10.122:43692-192.168.10.122:4443
2025-02-20T01:50:09Z DBG GetConn fd=5 pid=30573
2025-02-20T01:50:09Z DBG SSLDataEvent bio_type=1285 fd=5 pid=30573 tuple=192.168.10.122:43692-192.168.10.122:4443
2025-02-20T01:50:09Z DBG GetConn fd=5 pid=30573
2025-02-20T01:50:09Z DBG SSLDataEvent bio_type=1285 fd=5 pid=30573 tuple=192.168.10.122:43692-192.168.10.122:4443
2025-02-20T01:50:09Z DBG GetConn fd=5 pid=30573
2025-02-20T01:50:09Z DBG DestroyConn success fd=5 pid=30573 tuple=192.168.10.122:43692-192.168.10.122:4443
2025-02-20T01:50:09Z DBG SSLDataEvent bio_type=1285 fd=5 pid=30573 tuple=[TUPLE_NOT_FOUND]
2025-02-20T01:50:09Z DBG GetConn fd=5 pid=30573
2025-02-20T01:50:09Z DBG SSLDataEvent bio_type=1285 fd=5 pid=30573 tuple=[TUPLE_NOT_FOUND]
2025-02-20T01:50:09Z DBG GetConn fd=5 pid=30573
2025-02-20T01:50:09Z DBG SSLDataEvent bio_type=1285 fd=5 pid=30573 tuple=[TUPLE_NOT_FOUND]
2025-02-20T01:50:09Z DBG GetConn fd=5 pid=30573
2025-02-20T01:50:09Z DBG SSLDataEvent bio_type=1285 fd=5 pid=30573 tuple=[TUPLE_NOT_FOUND]
2025-02-20T01:50:09Z DBG GetConn fd=5 pid=30573
2025-02-20T01:50:09Z DBG SSLDataEvent bio_type=1285 fd=5 pid=30573 tuple=[TUPLE_NOT_FOUND]
2025-02-20T01:50:09Z DBG GetConn fd=5 pid=30573
2025-02-20T01:50:09Z DBG SSLDataEvent bio_type=1285 fd=5 pid=30573 tuple=[TUPLE_NOT_FOUND]
2025-02-20T01:50:11Z ??? UUID:30573_30573_curl_5_1_192.168.10.122:43692-192.168.10.122:4443, Name:HTTP2Request, Type:2, Length:44

Frame Type	=>	SETTINGS
Frame StreamID	=>	0

2025-02-20T01:50:11Z ??? UUID:30573_30573_curl_5_1_0.0.0.0:0-0.0.0.0:0, Name:HTTP2Response, Type:4, Length:353

Frame Type	=>	WINDOW_UPDATE
Frame StreamID	=>	0

Frame Type	=>	HEADERS
Frame StreamID	=>	1
header field ":method" = "GET"
header field ":path" = "/1.txt"
header field ":scheme" = "https"
header field ":authority" = "192.168.10.41:4443"
header field "user-agent" = "curl/7.81.0"
header field "accept" = "*/*"

Frame Type	=>	SETTINGS
Frame StreamID	=>	0

2025-02-20T01:50:11Z ??? UUID:30573_30573_curl_5_0_0.0.0.0:0-0.0.0.0:0, Name:HTTP2Response, Type:4, Length:577

Frame Type	=>	SETTINGS
Frame StreamID	=>	0

Frame Type	=>	WINDOW_UPDATE
Frame StreamID	=>	0

Frame Type	=>	SETTINGS
Frame StreamID	=>	0

Frame Type	=>	HEADERS
Frame StreamID	=>	1
header field ":status" = "200"
header field "server" = "nginx/1.21.5"
header field "date" = "Thu, 20 Feb 2025 01:50:09 GMT"
header field "content-type" = "text/plain"
header field "content-length" = "12"
header field "last-modified" = "Mon, 23 Dec 2024 02:20:35 GMT"
header field "etag" = "\"6768c8f3-c\""
header field "accept-ranges" = "bytes"

Frame Type	=>	DATA
Frame StreamID	=>	1
hello world

ok for http on same test environment


2025-02-20T01:50:16Z DBG AddConn success fd=5 pid=30575 tuple=192.168.10.122:53688-192.168.10.122:443
2025-02-20T01:50:16Z DBG GetConn fd=5 pid=30575
2025-02-20T01:50:16Z DBG SSLDataEvent bio_type=1285 fd=5 pid=30575 tuple=192.168.10.122:53688-192.168.10.122:443
2025-02-20T01:50:16Z DBG GetConn fd=5 pid=30575
2025-02-20T01:50:16Z DBG SSLDataEvent bio_type=1285 fd=5 pid=30575 tuple=192.168.10.122:53688-192.168.10.122:443
2025-02-20T01:50:16Z DBG DestroyConn success fd=5 pid=30575 tuple=192.168.10.122:53688-192.168.10.122:443
2025-02-20T01:50:17Z ??? UUID:30575_30575_curl_5_1_192.168.10.122:53688-192.168.10.122:443, Name:HTTPRequest, Type:1, Length:82
GET /1.txt HTTP/1.1
Host: 192.168.10.41
Accept: */*
User-Agent: curl/7.81.0


2025-02-20T01:50:17Z ??? UUID:30575_30575_curl_5_0_192.168.10.122:53688-192.168.10.122:443, Name:HTTPResponse, Type:3, Length:248
HTTP/1.1 200 OK
Content-Length: 12
Accept-Ranges: bytes
Connection: keep-alive
Content-Type: text/plain
Date: Thu, 20 Feb 2025 01:50:16 GMT
Etag: "6768c8f3-c"
Last-Modified: Mon, 23 Dec 2024 02:20:35 GMT
Server: nginx/1.21.5

hello world

^C2025-02-20T01:50:24Z INF module close.
2025-02-20T01:50:24Z INF Module closed,message recived from Context
2025-02-20T01:50:24Z INF iModule module close
2025-02-20T01:50:24Z INF bye bye.

@dosubot DosuBot
Copy link

dosubot bot commented Feb 20, 2025

The issue you're encountering, where HTTP/2 connections sometimes log a tuple as 0.0.0.0:0-0.0.0.0:0, while HTTP/1.1 does not, could be related to the timing of connection destruction and data capture. In eCapture, the DestroyConn function removes connection data from internal maps, and if a connection is destroyed before the data is fully captured, it may result in a default tuple being logged.

For HTTP/2, the interaction between kernel-level probes (SEC("kprobe/tcp_v4_destroy_sock")) and user-space probes (SEC("uretprobe/SSL_read") or SEC("uretprobe/SSL_write")) might lead to this issue. The kernel probe can trigger when a TCP socket is destroyed, potentially before the user-space probes have completed capturing the SSL/TLS data, especially in the case of HTTP/2 where the connection handling might differ from HTTP/1.1 [1].

To mitigate this, you could explore adjusting the sequence of events in your capture process to ensure that connection data is accessed and logged before the DestroyConn function is called. Additionally, reviewing the timing and sequence of events in your capture process could help in identifying if there are any adjustments needed to prevent premature destruction of connection data.

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@chilli13
Copy link
Contributor

@dosu HTTP/2 where the connection handling might differ from HTTP/1.1 -->Can you give a specific explanation of the differences and relevant literature references?

@cfc4n cfc4n self-assigned this Feb 20, 2025
cfc4n added a commit to cfc4n/ecapture that referenced this issue Feb 22, 2025
@cfc4n
fix: gojue#739 , the connection information was deleted in advance, c…
3218e65 
…ausing the tuple to be unreachable.
@cfc4n cfc4n linked a pull request Feb 22, 2025 that will close this issue
Open
@cfc4n
Copy link
Member

cfc4n commented Feb 22, 2025

@huaixia777 @chilli13 please try #741

@dosubot DosuBot
Copy link

dosubot bot commented Feb 22, 2025

I wasn't able to find specific details within the eCapture repository about how HTTP/2 connection handling differs from HTTP/1.1. However, generally speaking, HTTP/2 introduces multiplexing, which allows multiple streams to be sent over a single TCP connection. This can lead to differences in how connections are managed and destroyed compared to HTTP/1.1, which uses a simpler request-response model.

In terms of eCapture, the handling of HTTP/2 might involve more complex interactions between kernel and user-space probes due to the multiplexed nature of HTTP/2 connections. This complexity can affect the timing of events such as connection destruction and data capture, potentially leading to issues like the tuple being logged as 0.0.0.0:0-0.0.0.0:0.

For more detailed information, you might want to look into general resources on HTTP/2 protocol differences and eBPF-based network monitoring, as these could provide insights into the underlying mechanisms that might affect eCapture's behavior with HTTP/2.

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@cfc4n cfc4n

Labels
🐞 bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix: #739 the tuple to be unreachable. cfc4n/ecapture
3 participants
@cfc4n @chilli13 @huaixia777