Tls errors under ping flood #2117
Comments
|
|
I still can reproduce the issue, you went wrong way. First of all:
no, it's must not be patched, it's PoC please use it as is. Otherwise you will got OOM, definitely. Yes, it's looks strange but I hacked this way just to show the error in Tempesta. Memory consumption about 2.5GB of 8GB, it's pretty small. In the dmesg I don't have any warnings about OOM or buddy exhausting. Complete dmesg log is attached. I've one assumption, maybe you testing it inside single VM. If so, please, try to run the script on the host OS or from other VM. |
That's a mistake definitely, because then your connection argument doesn't take effect actually, i.e. it blocks on the first connection, then how many clients is how many connections. In fact, I also test with your original script, only one client one connection, if no delay, it will make tempesta consume memory constantly, although it's slower. ./ping_flood -address 192.168.2.1:443 -threads 1 -connections 1 -debug 1
As long as no delay, the memory will increase constantly. It will not stop at some amount. And I cannot reproduce your error message without OOM.
No, I tried both one VM or two VM cases, and both have the same result. The only difference is one VM case will has slow memory increase rate because the consumption of control frame in tempesta is faster than the two VM cases. |
Of course it will, if you "fix" it. Basically it must
it's desired behavior just for PoC. |
|
step16: the last possible partial ssl record may lost Line 838 in c298298 step17: sk->sk_receive_queue is not purged Line 901 in c298298 The root cause of the tls error is that It's impossible to come up with a perfect solution in the current implementation because we don't have socket buffer-based back pressure (#498) in the client TCP connection.
diff --git a/tls/ttls.c b/tls/ttls.c
index 9ccdd874..f526b004 100644
--- a/tls/ttls.c
+++ b/tls/ttls.c
@@ -2307,7 +2307,7 @@ ttls_recv(void *tls_data, unsigned char *buf, unsigned int len, unsigned int *re
TTLS_WARN(tls, "TLS cannot decrypt msg on state %s, ret=%d%s\n",
tls_state_to_str(tls->state), r,
r == -EBADMSG ? "(bad ciphertext)" : "");
- return r;
+ return T_BLOCK_WITH_RST;
}
if (io->msgtype == TTLS_MSG_ALERT) {
debug logs: There are no bugs with KTLS and kernel TCP/IP, as we can demonstrate it using a simple python script that serves h2 traffic in a single thread using openssl and KTLS. Also, the throughput is 20x higher than tempesta, with no significant impact on memory usage. |
Scope
Faced weird behavior. I wrote little script for ping flooding, when I running it to test Tempesta, I'm getting a lot of warnings in dmesg about invalid tls processing. However when I added delays between ping frames, all warnings are gone. I tested this script on other implementations. Nginx just blocks me, because it has flood protection. Golang server processes all frames without errors.
commit: 10b38e0
Looks like we don't disconnect client on error in tls protocol.
stats:
log:
config:
Utility:
main.zip
Run:
./flood -address 192.168.122.127:443 -threads 4 -connections 900 -debug 1The text was updated successfully, but these errors were encountered: