Frédéric Lécaille

Should have mentioned that this macro constant must be increased to 2048 in aeadtest.c: `#define BUF_MAX 2048`

OMG! So, we have used the wrong curl option :-s. So by default I guess this is TLS_CHACHA20_POLY1305_SHA256 or TLS_AES_128_CCM_SHA256 which is negotiated. I would say TLS_CHACHA20_POLY1305_SHA256 because the other...

I have managed to reproduce the same issue (with pkt_decipher.txt) patch which makes haproxy BUG_ON() as soon as it cannot decipher a packet it has ciphered. But only with libressl...

and only with TLS_CHACHA20_POLY1305_SHA256 (on linux).

Weird variables values: tls_ctx = 0x1 at line 1418 (src/quic_rx.c) after qc_select_tls_ctx() returned.

According to the two dumps, this is same bug but at different steps. First dump is during the handshake, and the second one after the handshake. Cannot tell very much...

For the second traces, we have a crash when dumping frames values (with TRACE()).

Unfortunately, I did not find any clue which could lead to the resolution. :disappointed: Perhaps a gdb dump of the connections could help: `(gdb) p *qc` where object is available...

I meant, where qc object is available...

No useful clue again. Perhaps the tls_ctx variable is not optimized into some frames. Please try into qc_do_rm_hp() to dump these variables: ``` p *tls_ctx p pkt->len p pn p...