IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Released version 2.6.11 with the following main changes :
- BUG/MEDIUM: proxy: properly stop backends on soft-stop
- BUG/MEDIUM: resolvers: Properly stop server resolutions on soft-stop
- DEBUG: cli/show_fd: Display connection error code
- DEBUG: ssl-sock/show_fd: Display SSL error code
- BUG/MINOR: tcp_sample: fix a bug in fc_dst_port and fc_dst_is_local sample fetches
- BUG/MINOR: quic: Missing STREAM frame length updates
- BUG/MEDIUM: connection: Preserve flags when a conn is removed from an idle list
- BUG/MINOR: mux-h2: make sure the h2c task exists before refreshing it
- MINOR: buffer: add br_single() to check if a buffer ring has more than one buf
- BUG/MEDIUM: mux-h2: only restart sending when mux buffer is decongested
- BUG/MINOR: mux-h2: set CO_SFL_STREAMER when sending lots of data
- BUG/MINOR: quic: Missing STREAM frame data pointer updates
- BUG/MEDIUM: listener: duplicate inherited FDs if needed
- MINOR: h2: add h2_phdr_to_ist() to make ISTs from pseudo headers
- MEDIUM: mux-h2/trace: add tracing support for headers
- BUG/MINOR: mux-h2: Fix possible null pointer deref on h2c in _h2_trace_header()
- BUG/MEDIUM: spoe: Don't set the default traget for the SPOE agent frontend
- BUG/MINOR: proto_ux: report correct error when bind_listener fails
- BUG/MINOR: protocol: fix minor memory leak in protocol_bind_all()
- BUG/MINOR: sock_unix: match finalname with tempname in sock_unix_addrcmp()
- MINOR: trace: add a TRACE_ENABLED() macro to determine if a trace is active
- MINOR: trace: add a trace_no_cb() dummy callback for when to use no callback
- MINOR: trace: add the long awaited TRACE_PRINTF()
- BUG/MAJOR: qpack: fix possible read out of bounds in static table
CertiK Skyfall Team reported that passing an index greater than
QPACK_SHT_SIZE in a qpack instruction referencing a literal field
name with name reference or and indexed field line will cause a
read out of bounds that may crash the process, and confirmed that
this fix addresses the issue.
This needs to be backported as far as 2.5.
(cherry picked from commit f41dfc22b2)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit aac7a54fe0779cee666ec5cae0fe00e7c17faa36)
Signed-off-by: Willy Tarreau <w@1wt.eu>
TRACE_PRINTF() can be used to produce arbitrary trace contents at any
trace level. It uses the exact same arguments as other TRACE_* macros,
but here they are mandatory since they are followed by the format-string,
though they may be filled with zeroes. The reason for the arguments is to
match tracking or filtering and not pollute other non-inspected objects.
It will probably be used inside loops, in which case there are two points
to be careful about:
- output atomicity is only per-message, so competing threads may see
their messages interleaved. As such, it is recommended that the
caller places a recognizable unique context at the beginning of the
message such as a connection pointer.
- iterating over arrays or lists for all requests could be very
expensive. In order to avoid this it is best to condition the call
via TRACE_ENABLED() with the same arguments, which will return the
same decision.
- messages longer than TRACE_MAX_MSG-1 (1023 by default) will be
truncated.
For example, in order to dump the list of HTTP headers between hpack
and h2:
if (outlen > 0 &&
TRACE_ENABLED(TRACE_LEVEL_DEVELOPER,
H2_EV_RX_FRAME|H2_EV_RX_HDR, h2c->conn, 0, 0, 0)) {
int i;
for (i = 0; list[i].n.len; i++)
TRACE_PRINTF(TRACE_LEVEL_DEVELOPER, H2_EV_RX_FRAME|H2_EV_RX_HDR,
h2c->conn, 0, 0, 0, "h2c=%p hdr[%d]=%s:%s", h2c, i,
list[i].n.ptr, list[i].v.ptr);
}
In addition, a lower-level TRACE_PRINTF_LOC() macro is provided, that takes
two extra arguments, the caller's location and the caller's function name.
This will allow to emit composite traces from central functions on the
behalf of another one.
(cherry picked from commit b8b243ac6a)
[wt: this will be needed by further QUIC patches]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 37a13cb0a72836194f48a2b013a1dc0d349ccff2)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
By default, passing a NULL cb to the trace functions will result in the
source's default one to be used. For some cases we won't want to use any
callback at all, not event the default one. Let's define a trace_no_cb()
function for this, that does absolutely nothing.
(cherry picked from commit 4b36d5e8de)
[wt: will be needed for further QUIC patches]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit a1425395f544d79dbf7124b13ed3825eec3f6269)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Sometimes it would be necessary to prepare some messages, pre-process some
blocks or maybe duplicate some contents before they vanish for the purpose
of tracing them. However we don't want to do that for everything that is
submitted to the traces, it's important to do it only for what will really
be traced.
The __trace() function has all the knowledge for this, to the point of even
checking the lockon pointers. This commit splits the function in two, one
with the trace decision logic, and the other one for the trace production.
The first one is now usable through wrappers such as _trace_enabled() and
TRACE_ENABLED() which will indicate whether traces are going to be produced
for the current source, level, event mask, parameters and tracking.
(cherry picked from commit 8f9a9704bb)
[wt: will be needed for further QUIC patches]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit e2ba91e9ea0ae4b0f890210cb55a03e483ef15ba)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
In sock_unix_addrcmp(), named UNIX sockets paths are manually compared in
order to properly handle tempname paths (ending with ".XXXX.tmp") that result
from the 2-step bind implemented in sock_unix_bind_receiver().
However, this logic does not take into account "final" path names (without the
".XXXX.tmp" suffix).
Example:
/tmp/test did not match with /tmp/test.1288.tmp prior to this patch
Indeed, depending on how the socket addr is retrieved, the same socket
could be designated either by its tempname or finalname.
socket addr is normally stored with its finalname within a receiver, but a
call to getsockname() on the same socket will return the tempname that was
used for the bind() call (sock_get_old_sockets() depends on getsockname()).
This causes sock_find_compatible_fd() to malfunction with named UNIX
sockets (ie: haproxy -x CLI option).
To fix this, we slightly modify the check around the temp suffix in
sock_unix_addrcmp(): we perform the suffix check even if one of the
paths is lacking the temp suffix (with proper precautions).
Now the function is able to match:
- finalname x finalname
- tempname x tempname
- finalname x tempname
That is: /tmp/test == /tmp/test.1288.tmp == /tmp/test.X.tmp
It should be backported up to 2.4
(cherry picked from commit 2a7903bbb2)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit af3fa8c632abd425278bd8a8ae4ca89e41e92064)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
In protocol_bind_all() (involved in startup sequence):
We only free errmsg (set by fam->bind() attempt) when we make use of it.
But this could lead to some memory leaks because there are some cases
where we ignore the error message (e.g: verbose=0 with ERR_WARN messages).
As long as errmsg is set, we should always free it.
As mentioned earlier, this really is a minor leak because it can only occur on
specific conditions (error paths) during the startup phase.
This may be backported up to 2.4.
--
Backport notes:
-> 2.4 only:
Replace this:
| ha_warning("Binding [%s:%d] for %s %s: %s\n",
| listener->bind_conf->file, listener->bind_conf->line,
| proxy_type_str(px), px->id, errmsg);
By this:
| else if (lerr & ERR_WARN)
| ha_warning("Starting %s %s: %s\n",
| proxy_type_str(px), px->id, errmsg);
(cherry picked from commit 8429627e3c)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit da9a15ff0326d59ba38f5a1b258820d91c7df649)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
In uxst_bind_listener() and uxdg_bind_listener(), when the function
fails because the listener is not bound, both function are setting
the error message but don't set the err status before returning.
Because of this, such error is not properly handled by the upper functions.
Making sure this error is properly catched by returning a composition of
ERR_FATAL and ERR_ALERT.
This could be backported up to 2.4.
(cherry picked from commit d861dc9b48)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit ab2d4405205575b46cb13fe34216a6d5896eca0a)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The commit d5983cef8 ("MINOR: listener: remove the useless ->default_target
field") revealed a bug in the SPOE. No default-target must be defined for
the SPOE agent frontend. SPOE applets are used on the frontend side and a
TCP connection is established on the backend side.
Because of this bug, since the commit above, the stream target is set to the
SPOE applet instead of the backend connection, leading to a spinning loop on
the applet when it is released because are unable to close the backend side.
This patch should fix the issue #2040. It only affects the 2.8-DEV but to
avoid any future bug, it should be backported to all stable versions.
(cherry picked from commit 25e36bfc22)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 5c8f140e5aff5f496d1694a3216ea354223cb9ef)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
As reported by Coverity, this function may be called with no h2c. Thus, the
pointer must always be checked before any access. One test was missing in
TRACE_PRINTF_LOC().
This patch should fix the issue #2015. No backport needed, except if the
commit 11e8a8c2a ("MEDIUM: mux-h2/trace: add tracing support for headers")
is backported.
(cherry picked from commit c254516c53)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit b899aabd7aa8cf1daff519169fab3993a952812f)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Now we can make use of TRACE_PRINTF() to iterate over headers as they
are received or dumped. It's worth noting that the dumps may occasionally
be interrupted due to a buffer full or a realign, but in this case it
will be visible because the trace will restart from the first one. All
these headers (and trailers) may be interleaved with other connections'
so they're all preceeded by the pointer to the connection and optionally
the stream (or alternately the stream ID) to help discriminating them.
Since it's not easy to read the header directions, sent headers are
prefixed with "sndh" and received headers are prefixed with "rcvh", both
of which are rare enough in the traces to conveniently support a quick
grep.
In order to avoid code duplication, h2_encode_headers() was implemented
as a wrapper on top of hpack_encode_header(), which optionally emits the
header to the trace if the trace is active. In addition, for headers that
are encoded using a different method, h2_trace_header() was added as well.
Header names are truncated to 256 bytes and values to 1024 bytes. If
the lengths are larger, they will be truncated and suffixed with
"(... +xxx)" where "xxx" is the number of extra bytes.
Example of what an end-to-end H2 request gives:
[00|h2|5|mux_h2.c:4818] h2c_decode_headers(): h2c=0x1c13120(F,FRP) dsi=1 rcvh :method: GET
[00|h2|5|mux_h2.c:4818] h2c_decode_headers(): h2c=0x1c13120(F,FRP) dsi=1 rcvh :path: /
[00|h2|5|mux_h2.c:4818] h2c_decode_headers(): h2c=0x1c13120(F,FRP) dsi=1 rcvh :scheme: http
[00|h2|5|mux_h2.c:4818] h2c_decode_headers(): h2c=0x1c13120(F,FRP) dsi=1 rcvh :authority: localhost:14446
[00|h2|5|mux_h2.c:4818] h2c_decode_headers(): h2c=0x1c13120(F,FRP) dsi=1 rcvh user-agent: curl/7.54.1
[00|h2|5|mux_h2.c:4818] h2c_decode_headers(): h2c=0x1c13120(F,FRP) dsi=1 rcvh accept: */*
[00|h2|5|mux_h2.c:4818] h2c_decode_headers(): h2c=0x1c13120(F,FRP) dsi=1 rcvh cookie: blah
[00|h2|5|mux_h2.c:5491] h2s_bck_make_req_headers(): h2c=0x1c1cd90(B,FRH) h2s=0x1c1e3d0(1,IDL) sndh :method: GET
[00|h2|5|mux_h2.c:5572] h2s_bck_make_req_headers(): h2c=0x1c1cd90(B,FRH) h2s=0x1c1e3d0(1,IDL) sndh :authority: localhost:14446
[00|h2|5|mux_h2.c:5596] h2s_bck_make_req_headers(): h2c=0x1c1cd90(B,FRH) h2s=0x1c1e3d0(1,IDL) sndh :path: /
[00|h2|5|mux_h2.c:5647] h2s_bck_make_req_headers(): h2c=0x1c1cd90(B,FRH) h2s=0x1c1e3d0(1,IDL) sndh user-agent: curl/7.54.1
[00|h2|5|mux_h2.c:5647] h2s_bck_make_req_headers(): h2c=0x1c1cd90(B,FRH) h2s=0x1c1e3d0(1,IDL) sndh accept: */*
[00|h2|5|mux_h2.c:5647] h2s_bck_make_req_headers(): h2c=0x1c1cd90(B,FRH) h2s=0x1c1e3d0(1,IDL) sndh cookie: blah
[00|h2|5|mux_h2.c:4818] h2c_decode_headers(): h2c=0x1c1cd90(B,FRP) dsi=1 rcvh :status: 200
[00|h2|5|mux_h2.c:4818] h2c_decode_headers(): h2c=0x1c1cd90(B,FRP) dsi=1 rcvh content-length: 0
[00|h2|5|mux_h2.c:4818] h2c_decode_headers(): h2c=0x1c1cd90(B,FRP) dsi=1 rcvh x-req: size=102, time=0 ms
[00|h2|5|mux_h2.c:4818] h2c_decode_headers(): h2c=0x1c1cd90(B,FRP) dsi=1 rcvh x-rsp: id=dummy, code=200, cache=1, size=0, time=0 ms (0 real)
[00|h2|5|mux_h2.c:5210] h2s_frt_make_resp_headers(): h2c=0x1c13120(F,FRH) h2s=0x1c1c780(1,HCR) sndh :status: 200
[00|h2|5|mux_h2.c:5231] h2s_frt_make_resp_headers(): h2c=0x1c13120(F,FRH) h2s=0x1c1c780(1,HCR) sndh content-length: 0
[00|h2|5|mux_h2.c:5231] h2s_frt_make_resp_headers(): h2c=0x1c13120(F,FRH) h2s=0x1c1c780(1,HCR) sndh x-req: size=102, time=0 ms
[00|h2|5|mux_h2.c:5231] h2s_frt_make_resp_headers(): h2c=0x1c13120(F,FRH) h2s=0x1c1c780(1,HCR) sndh x-rsp: id=dummy, code=200, cache=1, size=0, time=0 ms (0 real)
At some point the frontend/backend names would be useful but that's a more
general comment than just the H2 traces.
(cherry picked from commit 11e8a8c2ac)
[wt: backported since it significantly helps for debugging; requires
the following fix]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 53413179f06ea01965d8e8862560acc88549c638)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Till now pseudo headers were passed as const strings, but having them as
ISTs will be more convenient for traces. This doesn't change anything for
strings which are derived from them (and being constants they're still
zero-terminated).
(cherry picked from commit 271c440392)
[wt: will be used for h2 header traces]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 666d816bbb9ea25dc006a2a8de4335db242f8022)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Since commit 36d9097cf ("MINOR: fd: Add BUG_ON checks on fd_insert()"),
there is currently a test in fd_insert() to detect that we're not trying
to reinsert an FD that had already been inserted. This test catches the
following anomalies:
frontend fail1
bind fd@0
bind fd@0
and:
frontend fail2
bind fd@0 shards 2
What happens is that clone_listener() is called on a listener already
having an FD, and when sock_{inet,unix}_bind_receiver() are called, the
same FD will be registered multiple times and rightfully crash in the
sanity check.
It wouldn't be correct to block shards though (e.g. they could be used
in a default-bind line). What looks like a safer and more future-proof
approach simply is to dup() the FD so that each listener has one copy.
This is also the only solution that might allow later to support more
than 64 threads on an inherited FD.
This needs to be backported as far as 2.4. Better wait for at least
one extra -dev version before backporting though, as the bug should
not be triggered often anyway.
(cherry picked from commit 145b17fd2f)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 2aa96f003af84fc68b89efdfb4d6f1866f13788a)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
This patch follows this one which was not sufficient:
"BUG/MINOR: quic: Missing STREAM frame length updates"
Indeed, it is not sufficient to update the ->len and ->offset member
of a STREAM frame to move it forward. The data pointer must also be updated.
This is not done by the STREAM frame builder.
Must be backported to 2.6 and 2.7.
(cherry picked from commit ca07979b97)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit dcc827589a3a351af315d1f4cf0126dd2dc8a746)
[cf: ctx adjustment]
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Emeric noticed that h2 bit-rate performance was always slightly lower
than h1 when the CPU is saturated. Strace showed that we were always
data in 2kB chunks, corresponding to the max_record size. What's
happening is that when this mechanism of dynamic record size was
introduced, the STREAMER flag at the stream level was relied upon.
Since all this was moved to the muxes, the flag has to be passed as
an argument to the snd_buf() function, but the mux h2 did not use it
despite a comment mentioning it, probably because before the multi-buf
it was not easy to figure the status of the buffer.
The solution here consists in checking if the mbuf is congested or not,
by checking if it has more than one buffer allocated. If so we set the
CO_SFL_STREAMER flag, otherwise we don't. This way moderate size
exchanges continue to be made over small chunks, but downloads will
be able to use the large ones.
While it could be backported to all supported versions, it would be
better to limit it to the last LTS, so let's do it for 2.7 and 2.6 only.
This patch requires previous commit "MINOR: buffer: add br_single() to
check if a buffer ring has more than one buf".
(cherry picked from commit 14ea98af73)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 558ac459de1294ced755ace5efffdb7036baac58)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
During performance tests, Emeric faced a case where the wakeups of
sc_conn_io_cb() caused by h2_resume_each_sending_h2s() was multiplied
by 5-50 and a lot of CPU was being spent doing this for apparently no
reason.
The culprit is h2_send() not behaving well with congested buffers and
small SSL records. What happens when the output is congested is that
all buffers are full, and data are emitted in 2kB chunks, which are
sufficient to wake all streams up again to ask them to send data again,
something that will obviously only work for one of them at best, and
waste a lot of CPU in wakeups and memcpy() due to the small buffers.
When this happens, the performance can be divided by 2-2.5 on large
objects.
Here the chosen solution against this is to keep in mind that as long
as there are still at least two buffers in the ring after calling
xprt->snd_buf(), it means that the output is congested and there's
no point trying again, because these data will just be placed into
such buffers and will wait there. Instead we only mark the buffer
decongested once we're back to a single allocated buffer in the ring.
By doing so we preserve the ability to deal with large concurrent
bursts while not causing a thundering herd by waking all streams for
almost nothing.
This needs to be backported to 2.7 and 2.6. Other versions could
benefit from it as well but it's not strictly necessary, and we can
reconsider this option if some excess calls to sc_conn_io_cb() are
faced.
Note that this fix depends on this recent commit:
MINOR: buffer: add br_single() to check if a buffer ring has more than one buf
(cherry picked from commit 93c5511af8)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit a3e25ada050926881f0c2a8f82d2dfded49b086c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
It's cheaper and cleaner than using br_count()==1 given that it just compares
two indexes, and that a ring having a single buffer is in a special case where
it is between empty and used up-to-1. In other words it's not congested.
(cherry picked from commit 9824f8c890)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 6fd2e323a41d972fd0f6630ee02085366fd591bb)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
When detaching a stream, if it's the last one and the mbuf is blocked,
we leave without freeing the stream yet. We also refresh the h2c task's
timeout, except that it's possible that there's no such task in case
there is no client timeout, causing a crash. The fix just consists in
doing this when the task exists.
This bug has always been there and is extremely hard to meet even
without a client timeout. This fix has to be backported to all
branches, but it's unlikely anyone has ever met it anyay.
(cherry picked from commit 3fb2c6d5b4)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 5573b86da519086cfa78a0df821f675e25a34b7c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
The commit 5e1b0e7bf ("BUG/MEDIUM: connection: Clear flags when a conn is
removed from an idle list") introduced a regression. CO_FL_SAFE_LIST and
CO_FL_IDLE_LIST flags are used when the connection is released to properly
decrement used/idle connection counters. if a connection is idle, these
flags must be preserved till the connection is really released. It may be
removed from the list but not immediately released. If these flags are lost
when it is finally released, the current number of used connections is
erroneously decremented. If means this counter may become negative and the
counters tracking the number of idle connecitons is not decremented,
suggesting a leak.
So, the above commit is reverted and instead we improve a bit the way to
detect an idle connection. The function conn_get_idle_flag() must now be
used to know if a connection is in an idle list. It returns the connection
flag corresponding to the idle list if the connection is idle
(CO_FL_SAFE_LIST or CO_FL_IDLE_LIST) or 0 otherwise. But if the connection
is scheduled to be removed, 0 is also returned, regardless the connection
flags.
This new function is used when the connection is temporarily removed from
the list to be used, mainly in muxes.
This patch should fix#2078 and #2057. It must be backported as far as 2.2.
(cherry picked from commit 3a7b539b12)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit a81a1e2aea0793aa624565a14cb7579b907f116a)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Some STREAM frame lengths were not updated before being duplicated, built
of requeued contrary to their ack offsets. This leads haproxy to crash when
receiving acknowledgements for such frames with this thread #1 backtrace:
Thread 1 (Thread 0x7211b6ffd640 (LWP 986141)):
#0 ha_crash_now () at include/haproxy/bug.h:52
No locals.
#1 b_del (b=<optimized out>, del=<optimized out>) at include/haproxy/buf.h:436
No locals.
#2 qc_stream_desc_ack (stream=stream@entry=0x7211b6fd9bc8, offset=offset@entry=53176, len=len@entry=1122) at src/quic_stream.c:111
Thank you to @Tristan971 for having provided such traces which reveal this issue:
[04|quic|5|c_conn.c:1865] qc_requeue_nacked_pkt_tx_frms(): entering : qc@0x72119c22cfe0
[04|quic|5|_frame.c:1179] qc_frm_unref(): entering : qc@0x72119c22cfe0
[04|quic|5|_frame.c:1186] qc_frm_unref(): remove frame reference : qc@0x72119c22cfe0 frm@0x72118863d260 STREAM_F uni=0 fin=1 id=460 off=52957 len=1122 3244
[04|quic|5|_frame.c:1194] qc_frm_unref(): leaving : qc@0x72119c22cfe0
[04|quic|5|c_conn.c:1902] qc_requeue_nacked_pkt_tx_frms(): updated partially acked frame : qc@0x72119c22cfe0 frm@0x72119c472290 STREAM_F uni=0 fin=1 id=460 off=53176 len=1122
Note that haproxy has much more chance to crash if this frame is the last one
(fin bit set). But another condition must be fullfilled to update the ack offset.
A previous STREAM frame from the same stream with the same offset but with less
data must be acknowledged by the peer. This is the condition to update the ack offset.
For others frames without fin bit in the same conditions, I guess the stream may be
truncated because too much data are removed from the stream when they are
acknowledged.
Must be backported to 2.6 and 2.7.
(cherry picked from commit fc546ab6a7)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 3bcadac543ee69fa03cf7bf0be572522b59e8bb3)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
There is a bug in the smp_fetch_dport() function which affects the 'f' case,
also known as 'fc_dst_port' sample fetch.
conn_get_src() is used to retrieve the address prior to calling conn_dst().
But this is wrong: conn_get_dst() should be used instead.
Because of that, conn_dst() may return unexpected results since the dst
address is not guaranteed to be set depending on the conn state at the time
the sample fetch is used.
This was reported by Corin Langosch on the ML:
during his tests he noticed that using fc_dst_port in a log-format string
resulted in the correct value being printed in the logs but when he used it
in an ACL, the ACL did not evaluate properly.
This can be easily reproduced with the following test conf:
|frontend test-http
| bind 127.0.0.1:8080
| mode http
|
| acl test fc_dst_port eq 8080
| http-request return status 200 if test
| http-request return status 500 if !test
A request on 127.0.0.1:8080 should normally return 200 OK, but here it
will return a 500.
The same bug was also found in smp_fetch_dst_is_local() (fc_dst_is_local
sample fetch) by reading the code: the fix was applied twice.
This needs to be backported up to 2.5
[both sample fetches were introduced in 2.5 with 888cd70 ("MINOR:
tcp-sample: Add samples to get original info about client connection")]
(cherry picked from commit 819817fc5e)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit e01bee20926bd88d3c3a2ef3462eb44a01a10b7f)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Like for connection error code, when FD are dumps, the ssl error code is now
displayed. This may help to diagnose why a connection error occurred.
This patch may be backported to help debugging.
(cherry picked from commit f19c639787)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 92c1452111312e6af0db56e65051cea621a4d407)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
When FD are dumps, the connection error code is now displayed. This may help
to diagnose why a connection error occurred.
This patch may be backported to help debugging.
(cherry picked from commit d52f2ad6ee)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 3829656c7e95297755d30cf5dee24f4c270a9696)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
When HAproxy is stopping, the DNS resolutions must be stopped, except those
triggered from a "do-resolve" action. To do so, the resolutions themselves
cannot be destroyed, the current design is too complex. However, it is
possible to mute the resolvers tasks. The same is already performed with the
health-checks. On soft-stop, the tasks are still running periodically but
nothing if performed.
For the resolvers, when the process is stopping, before running a
resolution, we check all the requesters attached to this resolution. If t
least a request is a stream or if there is a requester attached to a running
proxy, a new resolution is triggered. Otherwise, we ignored the
resolution. It will be evaluated again on the next wakeup. This way,
"do-resolv" action are still working during soft-stop but other resoluation
are stopped.
Of course, it may be see as a feature and not a bug because it was never
performed. But it is in fact not expected at all to still performing
resolutions when HAProxy is stopping. In addution, a proxy option will be
added to change this behavior.
This patch partially fixes the issue #1874. It could be backported to 2.7
and maybe to 2.6. But no further.
(cherry picked from commit 52ec6f14c4)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 058782b3f28d4ea6543f24d4996f97410f4e9f49)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
On soft-stop, we must properlu stop backends and not only proxies with at
least a listener. This is mandatory in order to stop the health checks. A
previous fix was provided to do so (ba29687bc1 "BUG/MEDIUM: proxy: properly
stop backends"). However, only stop_proxy() function was fixed. When HAproxy
is stopped, this function is no longer used. So the same kind of fix must be
done on do_soft_stop_now().
This patch partially fixes the issue #1874. It must be backported as far as
2.4.
(cherry picked from commit 48678e483f)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 6faf82b613a706f9751356ee933829ac8f4e8d18)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
Released version 2.6.10 with the following main changes :
- BUG/MINOR: mworker: stop doing strtok directly from the env
- BUG/MEDIUM: mworker: prevent inconsistent reload when upgrading from old versions
- BUG/MEDIUM: mworker: don't register mworker_accept_wrapper() when master FD is wrong
- MINOR: startup: HAPROXY_STARTUP_VERSION contains the version used to start
- BUG/MINOR: lua/httpclient: missing free in hlua_httpclient_send()
- BUG/MEDIUM: httpclient/lua: fix a race between lua GC and hlua_ctx_destroy
- MINOR: fd/cli: report the polling mask in "show fd"
- BUG/MEDIUM: stconn: Don't rearm the read expiration date if EOI was reached
- BUG/MINOR: sched: properly report long_rq when tasks remain in the queue
- BUG/MEDIUM: sched: allow a bit more TASK_HEAVY to be processed when needed
- BUG/MINOR: mworker: prevent incorrect values in uptime
- MINOR: mux-h2/traces: do not log h2s pointer for dummy streams
- MINOR: mux-h2/traces: add a missing TRACE_LEAVE() in h2s_frt_handle_headers()
- REGTESTS: Fix ssl_errors.vtc script to wait for connections close
- BUG/MINOR: cache: Cache response even if request has "no-cache" directive
- BUG/MINOR: cache: Check cache entry is complete in case of Vary
- BUG/MINOR: ring: do not realign ring contents on resize
- BUILD: thead: Fix several 32 bits compilation issues with uint64_t variables
- BUG/MEDIUM: h1-htx: Never copy more than the max data allowed during parsing
- DOC: config: Fix description of options about HTTP connection modes
- DOC: config: Add the missing tune.fail-alloc option from global listing
- DOC: config: Clarify the meaning of 'hold' in the 'resolvers' section
- BUG/MEDIUM: connection: Clear flags when a conn is removed from an idle list
- BUG/MINOR: http-check: Don't set HTX_SL_F_BODYLESS flag with a log-format body
- BUG/MINOR: http-check: Skip C-L header for empty body when it's not mandatory
- BUG/MINOR: http-ana: Don't increment conn_retries counter before the L7 retry
- BUG/MINOR: http-ana: Do a L7 retry on read error if there is no response
- BUG/MINOR: ssl: Use 'date' instead of 'now' in ocsp stapling callback
- MINOR: ssl: rename confusing ssl_bind_kws
- BUG/MINOR: config: crt-list keywords mistaken for bind ssl keywords
- BUG/MINOR: init: properly detect NUMA bindings on large systems
- BUG/MEDIUM: master: force the thread count earlier
- BUG/MINOR: init: make sure to always limit the total number of threads
- BUG/MINOR: thread: report thread and group counts in the correct order
- BUG/MINOR: ring: release the backing store name on exit
- MEDIUM: epoll: don't synchronously delete migrated FDs
- MEDIUM: poller: program the update in fd_update_events() for a migrated FD
- MAJOR: fd: remove pending updates upon real close
- MINOR: fd: delete unused updates on close()
- MEDIUM: fd: add the tgid to the fd and pass it to fd_insert()
- MINOR: cli/fd: show fd's tgid and refcount in "show fd"
- MINOR: fd: add functions to manipulate the FD's tgid
- MINOR: fd: add fd_get_running() to atomically return the running mask
- MAJOR: fd: grab the tgid before manipulating running
- MINOR: fd: make fd_clr_running() return the previous value instead
- MEDIUM: fd: make fd_insert/fd_delete atomically update fd.tgid
- BUG/MINOR: fd: Properly init the fd state in fd_insert()
- MEDIUM: fd: quit fd_update_events() when FD is closed
- MAJOR: poller: only touch/inspect the update_mask under tgid protection
- MEDIUM: fd: support broadcasting updates for foreign groups in updt_fd_polling
- BUG/MAJOR: fd/thread: fix race between updates and closing FD
- BUG/MAJOR: fd/threads: close a race on closing connections after takeover
- MINOR: h3/hq-interop: handle no data in decode_qcs() with FIN set
- BUG/MINOR: mux-quic: transfer FIN on empty STREAM frame
- BUG/MINOR: quic: Possible unexpected counter incrementation on send*() errors
- BUG/MINOR: quic: Really cancel the connection timer from qc_set_timer()
- BUG/MINOR: quic: Missing call to task_queue() in qc_idle_timer_do_rearm()
- BUG/MINOR: quic: Do not probe with too little Initial packets
- BUG/MINOR: quic: Wrong initialization for io_cb_wakeup boolean
- BUG/MINOR: quic: Do not drop too small datagrams with Initial packets
- BUG/MINOR: quic: Missing padding for short packets
- MINOR: quic: adjust request reject when MUX is already freed
- BUG/MINOR: quic: also send RESET_STREAM if MUX released
- BUG/MINOR: quic: acknowledge STREAM frame even if MUX is released
- BUG/MINOR: h3: prevent hypothetical demux failure on int overflow
- BUG/MEDIUM: quic: properly handle duplicated STREAM frames
- BUG/MINOR: quic: Do not send too small datagrams (with Initial packets)
- BUG/MINOR: quic: Ensure to be able to build datagrams to be retransmitted
- BUG/MINOR: quic: Remove force_ack for Initial,Handshake packets
- BUG/MINOR: quic: Ensure not to retransmit packets with no ack-eliciting frames
- BUG/MINOR: quic: Do not resend already acked frames
- MINOR: quic: Move code to wakeup the timer task to avoid anti-amplication deadlock
- BUG/MINOR: quic: Missing detections of amplification limit reached
- BUG/MEDIUM: quic: do not crash when handling STREAM on released MUX
- BUG/MINOR: mux-quic: properly init STREAM frame as not duplicated
- BUG/MINOR: mworker: use MASTER_MAXCONN as default maxconn value
- BUG/MINOR: quic: Missing listener accept queue tasklet wakeups
- DOC/CLEANUP: fix typos
This bug was revealed by h2load tests run as follows:
h2load -t 4 --npn-list h3 -c 64 -m 16 -n 16384 -v https://127.0.0.1:4443/
This open (-c) 64 QUIC connections (-n) 16384 h3 requets from (-t) 4 threads, i.e.
256 requests by connection. Such tests could not always pass and often ended with
such results displays by h2load:
finished in 53.74s, 38.11 req/s, 493.78KB/s
requests: 16384 total, 2944 started, 2048 done, 2048 succeeded, 14336
failed, 14336 errored, 0 timeout
status codes: 2048 2xx, 0 3xx, 0 4xx, 0 5xx
traffic: 25.92MB (27174537) total, 102.00KB (104448) headers (space
savings 1.92%), 25.80MB (27053569) data
UDP datagram: 3883 sent, 24330 received
min max mean sd sd
time for request: 48.75ms 502.86ms 134.12ms 75.80ms 92.68%
time for connect: 20.94ms 331.24ms 189.59ms 84.81ms 59.38%
time to 1st byte: 394.36ms 417.01ms 406.72ms 9.14ms 75.00%
req/s : 0.00 115.45 14.30 38.13 87.50%
The number of successful requests was always a multiple of 256.
Activating the traces also shew that some connections were blocked after having
successfully completed their handshakes due to the fact that the mux. The mux
is started upon the acceptation of the connection.
Under heavy load, some connections were never accepted. From the moment where
more than 4 (MAXACCEPT) connections were enqueued before a listener could be
woken up to accept at most 4 connections, the remaining connections were not
accepted ore lately at the second listener tasklet wakeup.
Add a call to tasklet_wakeup() to the accept list tasklet of the listeners to
wake up it if there are remaining connections to accept after having called
listener_accept(). In this case the listener must not be removed of this
accept list, if not at the next call it will not accept anything more.
Must be backported to 2.7 and 2.6.
(cherry picked from commit 4377dbd756)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 9cc091cb29114d71a30e703aa895a6fa9658336b)
Signed-off-by: Willy Tarreau <w@1wt.eu>
In environments where SYSTEM_MAXCONN is defined when compiling, the
master will use this value instead of the original minimal value which
was set to 100. When this happens, the master process could allocate
RAM excessively since it does not need to have an high maxconn. (For
example if SYSTEM_MAXCONN was set to 100000 or more)
This patch fixes the issue by using the new define MASTER_MAXCONN which
define a default maxconn of 100 for the master process.
Must be backported as far as 2.5.
(cherry picked from commit 2078d4b1f7)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 585a6cb8ae836094df5ab4944607349866028ca1)
Signed-off-by: Willy Tarreau <w@1wt.eu>
STREAM frame retransmission has been recently fixed. A new boolean field
<dup> was created for quic_stream frame type. It is set for duplicated
STREAM frame to ensure extra checks on the underlying buffer are
conducted before sending the frame. All of this has been implemented by
this commit :
315a4f6ae5
BUG/MEDIUM: quic: do not crash when handling STREAM on released MUX
However, the above commit is incomplete. In the MUX code, when a new
STREAM frame is created, <dup> is left uninitialized. In most cases this
is harmless as it will only add extra unneeded checks before sending the
frame. So this is mainly a performance issue.
There is however one case where this bug will lead to a crash : when the
response consists only of an empty STREAM frame. In this case, the empty
frame will be silently removed as it is incorrectly assimilated to an
already acked frame range in qc_build_frms(). This can trigger a
BUG_ON() on the MUX code as a qcs instance is still in the send list
after qc_send_frames() invocation.
Note that this is extremely rare to have only an empty STREAM frame. It
was reproduced with HTTP/0.9 where no HTTP status line exists on an
empty body. I do not know if this is possible on HTTP/3 as a status line
should be present each time in a HEADERS frame.
Properly initialize <dup> field to 0 on each STREAM frames generated by
the QUIC MUX to fix this issue.
This crash may be linked to github issue #2049.
This should be backported up to 2.6.
(cherry picked from commit ebfafc212a)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 301724cc4c4ad4593c18458c793cb6598b33b6d2)
[ad: adjusted context]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
The MUX instance is released before its quic-conn counterpart. On
termination, a H3 GOAWAY is emitted to prevent the client to open new
streams for this connection.
The quic-conn instance will stay alive until all opened streams data are
acknowledged. If the client tries to open a new stream during this
interval despite the GOAWAY, quic-conn is responsible to request its
immediate closure with a STOP_SENDING + RESET_STREAM.
This behavior was already implemented but the received packet with the
new STREAM was never acknowledged. This was fixed with the following
commit :
commit 156a89aef8
BUG/MINOR: quic: acknowledge STREAM frame even if MUX is released
However, this patch introduces a regression as it did not skip the call
to qc_handle_strm_frm() despite the MUX instance being released. This
can cause a segfault when using qcc_get_qcs() on a released MUX
instance. To fix this, add a missing break statement which will skip
qc_handle_strm_frm() when the MUX instance is not initialized.
This commit was reproduced using a short timeout client and sending
several requests with delay between them by using a modified aioquic. It
produces a crash with the following backtrace :
#0 0x000055555594d261 in __eb64_lookup (x=4, root=0x7ffff4091f60) at include/import/eb64tree.h:132
#1 eb64_lookup (root=0x7ffff4091f60, x=4) at src/eb64tree.c:37
#2 0x000055555563fc66 in qcc_get_qcs (qcc=0x7ffff4091dc0, id=4, receive_only=1, send_only=0, out=0x7ffff780ca70) at src/mux_quic.c:668
#3 0x0000555555641e1a in qcc_recv (qcc=0x7ffff4091dc0, id=4, len=40, offset=0, fin=1 '\001', data=0x7ffff40c4fef "\001&") at src/mux_quic.c:974
#4 0x0000555555619d28 in qc_handle_strm_frm (pkt=0x7ffff4088e60, strm_frm=0x7ffff780cf50, qc=0x7ffff7cef000, fin=1 '\001') at src/quic_conn.c:2515
#5 0x000055555561d677 in qc_parse_pkt_frms (qc=0x7ffff7cef000, pkt=0x7ffff4088e60, qel=0x7ffff7cef6c0) at src/quic_conn.c:3050
#6 0x00005555556230aa in qc_treat_rx_pkts (qc=0x7ffff7cef000, cur_el=0x7ffff7cef6c0, next_el=0x0) at src/quic_conn.c:4214
#7 0x0000555555625fee in quic_conn_app_io_cb (t=0x7ffff40c1fa0, context=0x7ffff7cef000, state=32848) at src/quic_conn.c:4640
#8 0x00005555558a676d in run_tasks_from_lists (budgets=0x7ffff780d470) at src/task.c:596
#9 0x00005555558a725b in process_runnable_tasks () at src/task.c:876
#10 0x00005555558522ba in run_poll_loop () at src/haproxy.c:2945
#11 0x00005555558529ac in run_thread_poll_loop (data=0x555555d14440 <ha_thread_info+64>) at src/haproxy.c:3141
#12 0x00007ffff789ebb5 in ?? () from /usr/lib/libc.so.6
#13 0x00007ffff7920d90 in ?? () from /usr/lib/libc.so.6
This should fix github issue #2067.
This must be backported up to 2.6.
(cherry picked from commit 315a4f6ae5)
Signed-off-by: William Lallemand <wlallemand@haproxy.org>
(cherry picked from commit 1103d1d979783a4f00d2fa7cac7b9d2abfaceed5)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
Mark the connection as limited by the anti-amplification limit when trying to
probe the peer.
Wakeup the connection PTO/dectection loss timer as soon as a datagram is
received. This was done only when the datagram was dropped.
This fixes deadlock issues revealed by some interop runner tests.
Must be backported to 2.7 and 2.6.
(cherry picked from commit a65b71f89f)
Signed-off-by: William Lallemand <wlallemand@haproxy.org>
(cherry picked from commit aa6b4c9325e04cdc7ca68f5b4b190c2d8ce59d72)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
This code was there because the timer task was not running on the same thread
as the one which parse the QUIC packets. Now that this is no more the case,
we can wake up this task directly.
Must be backported to 2.7.
(cherry picked from commit 75c8ad5490)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 367c06096b2338c46bb9bec273c3bcb80d983ee7)
[ad: taken on 2.6 to facilitate next cherry-pick]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
Some frames are marked as already acknowledged from duplicated packets
whose the original packet has been acknowledged. There is no need
to resend such packets or frames.
Implement qc_pkt_with_only_acked_frms() to detect packet with only
already acknowledged frames inside and use it from qc_prep_fast_retrans()
which selects the packet to be retransmitted.
Must be backported to 2.6 and 2.7.
(cherry picked from commit e6359b649b)
Signed-off-by: William Lallemand <wlallemand@haproxy.org>
(cherry picked from commit b21ed518d576e1ed64909739a3735b167c9d320b)
[ad: adjust context due to missing traces]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
Even if there is a check in callers of qc_prep_hdshk_fast_retrans() and
qc_prep_fast_retrans() to prevent retransmissions of packets with no ack-eliciting
frames, these two functions should pay attention not do to that especially if
someone decides to modify their implementations in the future.
Must be backported to 2.6 and 2.7.
(cherry picked from commit 21564be4a2)
Signed-off-by: William Lallemand <wlallemand@haproxy.org>
(cherry picked from commit 162fb779adec6e080d059923172b57a7b80ba494)
[ad: adjust context due to missing traces]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
This is an old bug which arrived in this commit due to a misinterpretation
of the RFC I guess where the desired effect was to acknowledge all the
handshake packets:
77ac6f566 BUG/MINOR: quic: Missing acknowledgments for trailing packets
This had as bad effect to acknowledge all the handshake packets even the
ones which are not ack-eliciting.
Must be backported to 2.7 and 2.6.
(cherry picked from commit b3562a3815)
Signed-off-by: William Lallemand <wlallemand@haproxy.org>
(cherry picked from commit 4b9a3733ccc1f776b24127134c57e971e3af556d)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
When retransmitting datagrams with two coalesced packets inside, the second
packet was not taken into consideration when checking there is enough space
into the network for the datagram, especially when limited by the anti-amplification.
Must be backported to 2.6 and 2.7.
(cherry picked from commit d30a04a4bb)
Signed-off-by: William Lallemand <wlallemand@haproxy.org>
(cherry picked from commit ba731669e56d1c72de0bfe1d40de478f7605f6cd)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
Before building a packet into a datagram, ensure there is sufficient space for at
least 1200 bytes. Also pad datagrams with only one ack-eliciting Initial packet
inside.
Must be backported to 2.7 and 2.6.
(cherry picked from commit 69e7118fe9)
Signed-off-by: William Lallemand <wlallemand@haproxy.org>
(cherry picked from commit da21a8015f959ee1bf10c52c06f5ffe83bd8ff44)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
When a STREAM frame is re-emitted, it will point to the same stream
buffer as the original one. If an ACK is received for either one of
these frame, the underlying buffer may be freed. Thus, if the second
frame is declared as lost and schedule for retransmission, we must
ensure that the underlying buffer is still allocated or interrupt the
retransmission.
Stream buffer is stored as an eb_tree indexed by the stream ID. To avoid
to lookup over a tree each time a STREAM frame is re-emitted, a lost
STREAM frame is flagged as QUIC_FL_TX_FRAME_LOST.
In most cases, this code is functional. However, there is several
potential issues which may cause a segfault :
- when explicitely probing with a STREAM frame, the frame won't be
flagged as lost
- when splitting a STREAM frame during retransmission, the flag is not
copied
To fix both these cases, QUIC_FL_TX_FRAME_LOST flag has been converted
to a <dup> field in quic_stream structure. This field is now properly
copied when splitting a STREAM frame. Also, as this is now an inner
quic_frame field, it will be copied automatically on qc_frm_dup()
invocation thus ensuring that it will be set on probing.
This issue was encounted randomly with the following backtrace :
#0 __memmove_avx512_unaligned_erms ()
#1 0x000055f4d5a48c01 in memcpy (__len=18446698486215405173, __src=<optimized out>,
#2 quic_build_stream_frame (buf=0x7f6ac3fcb400, end=<optimized out>, frm=0x7f6a00556620,
#3 0x000055f4d5a4a147 in qc_build_frm (buf=buf@entry=0x7f6ac3fcb5d8,
#4 0x000055f4d5a23300 in qc_do_build_pkt (pos=<optimized out>, end=<optimized out>,
#5 0x000055f4d5a25976 in qc_build_pkt (pos=0x7f6ac3fcba10,
#6 0x000055f4d5a30c7e in qc_prep_app_pkts (frms=0x7f6a0032bc50, buf=0x7f6a0032bf30,
#7 qc_send_app_pkts (qc=0x7f6a0032b310, frms=0x7f6a0032bc50) at src/quic_conn.c:4184
#8 0x000055f4d5a35f42 in quic_conn_app_io_cb (t=0x7f6a0009c660, context=0x7f6a0032b310,
This should fix github issue #2051.
This should be backported up to 2.6.
(cherry picked from commit c8a0efbda8)
Signed-off-by: William Lallemand <wlallemand@haproxy.org>
(cherry picked from commit 85ab1edd1549c4eb4680543d7f86c3065fbaf30e)
[ad: remove block which rejects frame on too many retransmission]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
h3s stores the current demux frame type and length as a state info. It
should be big enough to store a QUIC variable-length integer which is
the maximum H3 frame type and size.
Without this patch, there is a risk of integer overflow if H3 frame size
is bigger than INT_MAX. This can typically causes demux state mismatch
and demux frame error. However, no occurence has been found yet of this
bug with the current implementation.
This should be backported up to 2.6.
(cherry picked from commit 35d9053b68)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 1ef3723c229f9a18e7ba95e2000f477d12de7fc1)
[ad: remove h3 trace facility not supported on 2.6]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
When the MUX is freed, the quic-conn layer may stay active until all
streams acknowledgment are processed. In this interval, if a new stream
is opened by the client, the quic-conn is thus now responsible to handle
it. This is done by the emission of a STOP_SENDING + RESET_STREAM.
Prior to this patch, the received packet was not acknowledged. This is
undesirable if the quic-conn is able to properly reject the request as
this can lead to unneeded retransmission from the client.
This must be backported up to 2.6.
(cherry picked from commit 156a89aef8)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 49c35005d7f488524b009aa8ade7e8946660bd0b)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
When the MUX is freed, the quic-conn layer may stay active until all
streams acknowledgment are processed. In this interval, if a new stream
is opened by the client, the quic-conn is thus now responsible to handle
it. This is done by the emission of a STOP_SENDING.
This process has been completed to also emit a RESET_STREAM with the
same error code H3_REQUEST_REJECTED. This is done to conform with the H3
specification to invite the client to retry its request on a new
connection.
This should be backported up to 2.6.
(cherry picked from commit 7546301712)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit eb284ce40ca3425694ac5e4e1aae7b9df652f883)
[ad: replace non-existant wrapper for quic_frame alloc/dealloc by
plain pool_alloc/pool_free]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
When the MUX is freed, the quic-conn layer may stay active until all
streams acknowledgment are processed. In this interval, if a new stream
is opened by the client, the quic-conn is thus now responsible to handle
it. This is done by the emission of a STOP_SENDING.
This process is closely related to HTTP/3 protocol despite being handled
by the quic-conn layer. This highlights a flaw in our QUIC architecture
which should be adjusted. To reflect this situation, the function
qc_stop_sending_frm_enqueue() is renamed qc_h3_request_reject(). Also,
internal H3 treatment such as uni-directional bypass has been moved
inside the function.
This commit is only a refactor. However, bug fix on next patches will
rely on it so it should be backported up to 2.6.
(cherry picked from commit 38836b6b3d)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 7dff75afd0dbc72c5283cff7dcb7bed4e61c7943)
[ad: adjusted context : replace non existent qc_frm_alloc by a simple
pool_alloc()]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
This was revealed by Amaury when setting tune.quic.frontend.max-streams-bidi to 8
and asking a client to open 12 streams. haproxy has to send short packets
with little MAX_STREAMS frames encoded with 2 bytes. In addition to a packet number
encoded with only one byte. In the case <len_frms> is the length of the encoded
frames to be added to the packet plus the length of the packet number.
Ensure the length of the packet is at least QUIC_PACKET_PN_MAXLEN adding a PADDING
frame wich (QUIC_PACKET_PN_MAXLEN - <len_frms>) as size. For instance with
a two bytes MAX_STREAMS frames and a one byte packet number length, this adds
one byte of padding.
See https://datatracker.ietf.org/doc/html/rfc9001#name-header-protection-sample.
Must be backported to 2.7 and 2.6.
(cherry picked from commit 5faf577997)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit feb6c4e1e322bc2d51a010cd30dcdbb076f8fd9b)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
When receiving an Initial packet a peer must drop it if the datagram is smaller
than 1200. Before this patch, this is the entire datagram which was dropped.
In such a case, drop the packet after having parsed its length.
Must be backported to 2.6 and 2.7
(cherry picked from commit 35218c6357)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 97c8d5767f9f2e4b07f52bf2cbd3a3ba32d4e839)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
This bug arrives with this commit:
982896961 MINOR: quic: split and rename qc_lstnr_pkt_rcv()
The first block of code consists in possibly setting this variable to true.
But it was already initialized to true before entering this code section.
Should be initialized to false.
Also take the opportunity to remove an unused "err" label.
Must be backported to 2.6 and 2.7.
(cherry picked from commit 8f7d22406c)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit d79a8f0f8136a5f384d0cf9a274eac21cf2c1343)
[ad: adjusted context]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
Before probing the Initial packet number space, verify that we can at least
sent 1200 bytes by datagram. This may not be the case due to the amplification limit.
Must be backported to 2.6 and 2.7.
(cherry picked from commit 7c6d8f88df)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit e8b25661924dbe9746403189a0ab4aa81d4bcc40)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
The aim of this function is to rearm the idle timer. The ->expire
field of the timer task was updated without being requeued.
Some connection could be unexpectedly terminated.
Must be backported to 2.6 and 2.7.
(cherry picked from commit 1e8ef1bed6)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 6176a60afb8cbb95622bf24b27f34a7b121c512b)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
