* fix memory leak when gquic50 decrypt packet
fix a suspicious memory leak in gquic and iquic
* drop some redundant checking.
Co-authored-by: linsc <linsc@wangus.com>
RFC9000 3.5.
A STOP_SENDING frame requests that the receiving endpoint send a RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame MUST send a RESET_STREAM frame if the stream is in the "Ready" or "Send" state. If the stream is in the "Data Sent" state, the endpoint MAY defer sending the RESET_STREAM frame until the packets containing outstanding data are acknowledged or declared lost. If any outstanding data is declared lost, the endpoint SHOULD send a RESET_STREAM frame instead of retransmitting the data.
RFC9000 19.4. RESET_Frames
An endpoint uses a RESET_STREAM frame (type=0x04) to abruptly terminate the sending part of a stream.
Co-authored-by: wangfuyu <wangfuyu@gmail.com>
[Reproduce]
http_client POST large body request to http_server, like:
http_client -H quic.test.com -s ${SERVER_ADDR}:${SERVER_PORT} -p /1KB_char.txt -M POST -P /test/quic-data/html/10KB_char.txt -o version=h3 -n 100 -r 50000000 -R 500 -w 10 -K
[Notes]
[RFC5116 AEAD] Section 5.1
An authentication tag with a length of 16 octets (128bits) is used.
[RFC9001 QUIC-TLS] Section 5.3
These cipher suites have a 16-byte authentication tag and
produce an output 16 bytes larger than their input.
Co-authored-by: wangfuyu <ivanfywang@gmail.com>
* link fix when using lsquic in a cpp project
* Update CMakeLists.txt
* Fix getopt.h error when not needed
Co-authored-by: MBellahcene <moussa.bellahcene@4d.com>
Description:
- Error may occur while processing ack frame, e.g. poison packet was
acked by hostile attack. and then conn is supposed to be aborted,
shortly but not immediately;
- if ack frame processing failed while calling lsquic_engine_packet_in,
and IFC_HAVE_SAVED_ACK had been set, then saved ack frame will be
processed while ticking connection before it is aborted, that may
lead to assert failure;
Solution:
- close connection if neccessary before processing ack while ci_tick.
1) After handshake done, handshake packets should not be sent or received.
2) IFC_ACK_QUED_HSK will be cancelled from conn->ifc_flags after handshake done, but it maybe set again if ACKs for handshake lost(Function: should_generate_ack).
Co-authored-by: ivanfywang <ivanfywang@gmail.com>
* Test case and debug for lsquic rechist list problem
Add:
- test case
- debug rechist print function (not called)
Modify:
- rechist_test_sanity to be more robust
Test case:
Added test case which produces a corrupt rechist. The rechist
grows and then is emptied, then a rechist is produced that is nominally
empty (rh_n_used == 0) but has a circular list in rh_elems. E.g. (using
debug print at the problem site):
lsquic_rechist_received: insert before done
0x7ffe65ce75a0: cutoff 9 l. acked 12087061905995 masks 1 alloced 4 used 1 max ranges 0 head 0
(0)[9-9] (0)[9-9] (0)[9-9] (0)[9-9] (0)[9-9] (0)[9-9] (0)[9-9]
test_rechist: /tmp/lsquic/src/liblsquic/lsquic_rechist.c:272: rechist_test_sanity: Assertion `rechist->rh_n_used == n_elems' failed.
Debug print:
Added 'rechist_dump' for ease of debugging, marked as unused.
Useful for calling from gdb or adding to code temporarily.
rechist_test_sanity:
Make it more robust to bad rechists by limiting
how many list items it will follow, to prevent infinite loops or walking off
the end of the list.
* rechist: Fix bug in lsquic_rechist_received causing circular list to be created
Fix bug in lsquic_rechist_received demonstrated by the test6 test-case.
When the list is empty, i.e. rh_n_used == 0, the 'first_elem' path should
be used. However, the test for this was using rh_n_alloced, which would
cause the code to continue on incorrectly. One possibility is that it goes
to insert_before and creates a circular list in the rechist with the head at
index 0 having a next of 0.
This causes history to be lost I think.
The list at this point is still 'empty', however a following call could go
to the insert_before path and then insert an elem pointing to the circular
list, and bump up rh_n_used. Now you have a circular list.
Weird things can happen now. Notably, ACK generation will exhaust the
packet buffer and generate an error, and so cause connections to be
prematurely aborted.
Fix lsquic_rechist_received to use rh_n_used. Also modify
rechist_alloc_elem to NULL the next pointer for robustness.
It would be nice for rechist_free_elem to also invalidate the elem, but it
is meant for relinking elems in the list and should preserve the next
pointer.
FIND_LIBRARY will fail if boringssl didn't get build yet, so the
following cmake build rule doesn't work:
add_subdirectory(third_party/boringssl)
set(BORINGSSL_LIB ${CMAKE_CURRENT_BINARY_DIR}/third_party/boringssl)
add_subdirectory(third_party/lsquic)
The patch fixed it by allow setting BORINGSSL_LIB_foo explicitly,
e.g.,
add_subdirectory(third_party/boringssl)
set(BORINGSSL_LIB_ssl ssl)
set(BORINGSSL_LIB_crypto crypto)
set(BORINGSSL_LIB_decrepit decrepit)
add_subdirectory(third_party/lsquic)
* fix MSVC compiler shared library issues - mostly around 'extern const'
* add vcpkg install getopt to appveyor-windows.yml
show appveyor where to get getopt from vcpkg (non-static lib to avoid LGPL violation)
* add missing else case in lsquic_shared_support.h for windows static lib path
* have cmake spit out it's version
have cmake copy dependent dlls to build dir for tests on windows (getopt.dll)
* copy getopt.dll dep for tests
added commented version that requires >= 3.21 but handles any dll deps
* try caching boringssl dir to reduce CI build time since it's always same commit specified in config file
define VCPKG_ROOT in env since I can't seem to find it by VCPKG_ROOT or VCPKG_INSTALLED_DIR in appveyor's cmake v3.16 + vcpkg
* make windows cache dependent on yml and cmd
* sync up with changes to ls-qpack
