gamzinav/haproxy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

MINOR: quic: Wrong CRYPTO frame concatenation

Browse Source 
This commit was not correct:
	 "MINOR: quic: Only one CRYPTO frame by encryption level"
Indeed, when receiving CRYPTO data from TLS stack for a packet number space,
there are rare cases where there is already other frames than CRYPTO data frames
in the packet number space, especially for 01RTT packet number space.  This is
very often with quant as client.
This commit is contained in:
Frédéric Lécaille 2022-01-10 18:31:07 +01:00
parent 2fe8b3be20
commit 81cd3c8eed
1 changed files with 19 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
src/xprt_quic.c
View File

@ -993,8 +993,26 @@ static int quic_crypto_data_cpy(struct quic_enc_level *qel,
*/
if (!len) {
struct quic_frame *frm;
struct quic_frame *found = NULL;
struct mt_list *tmp1, tmp2;
if (MT_LIST_ISEMPTY(&qel->pktns->tx.frms)) {
/* There is at most one CRYPTO frame in this packet number
* space. Let's look for it.
*/
mt_list_for_each_entry_safe(frm, &qel->pktns->tx.frms,
mt_list, tmp1, tmp2) {
if (frm->type != QUIC_FT_CRYPTO)
continue;
/* Found */
found = frm;
break;
}
if (found) {
found->crypto.len += cf_len;
}
else {
frm = pool_alloc(pool_head_quic_frame);
if (!frm)
return 0;
@ -1005,10 +1023,6 @@ static int quic_crypto_data_cpy(struct quic_enc_level *qel,
frm->crypto.qel = qel;
MT_LIST_APPEND(&qel->pktns->tx.frms, &frm->mt_list);
}
else {
frm = MT_LIST_NEXT(&qel->pktns->tx.frms, struct quic_frame *, mt_list);
frm->crypto.len += cf_len;
}
}
return len == 0;