upstream/haproxy
1
0
Fork 0
mirror of https://github.com/haproxy/haproxy.git synced 2026-03-29 22:04:53 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 3
haproxy/src/connection.c

1042 lines
31 KiB
C
Raw Normal View History

MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
/*
* Connection management functions
*
* Copyright 2000-2012 Willy Tarreau <w@1wt.eu>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
*/
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
#include <errno.h>
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
#include <common/compat.h>
#include <common/config.h>
MAJOR: namespace: add Linux network namespace support This patch makes it possible to create binds and servers in separate namespaces. This can be used to proxy between multiple completely independent virtual networks (with possibly overlapping IP addresses) and a non-namespace-aware proxy implementation that supports the proxy protocol (v2). The setup is something like this: net1 on VLAN 1 (namespace 1) -\ net2 on VLAN 2 (namespace 2) -- haproxy ==== proxy (namespace 0) net3 on VLAN 3 (namespace 3) -/ The proxy is configured to make server connections through haproxy and sending the expected source/target addresses to haproxy using the proxy protocol. The network namespace setup on the haproxy node is something like this: = 8< = $ cat setup.sh ip netns add 1 ip link add link eth1 type vlan id 1 ip link set eth1.1 netns 1 ip netns exec 1 ip addr add 192.168.91.2/24 dev eth1.1 ip netns exec 1 ip link set eth1.$id up ... = 8< = = 8< = $ cat haproxy.cfg frontend clients bind 127.0.0.1:50022 namespace 1 transparent default_backend scb backend server mode tcp server server1 192.168.122.4:2222 namespace 2 send-proxy-v2 = 8< = A bind line creates the listener in the specified namespace, and connections originating from that listener also have their network namespace set to that of the listener. A server line either forces the connection to be made in a specified namespace or may use the namespace from the client-side connection if that was set. For more documentation please read the documentation included in the patch itself. Signed-off-by: KOVACS Tamas <ktamas@balabit.com> Signed-off-by: Sarkozi Laszlo <laszlo.sarkozi@balabit.com> Signed-off-by: KOVACS Krisztian <hidden@balabit.com>
2014-11-17 09:11:45 -05:00
#include <common/namespace.h>
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
CLEANUP: connection: split sock_ops into data_ops, app_cp and si_ops Some parts of the sock_ops structure were only used by the stream interface and have been moved into si_ops. Some of them were callbacks to the stream interface from the connection and have been moved into app_cp as they're the application seen from the connection (later, health-checks will need to use them). The rest has moved to data_ops. Normally at this point the connection could live without knowing about stream interfaces at all.
2012-08-24 12:12:41 -04:00
#include <proto/connection.h>
CLEANUP: includes: fix includes for a number of users of fd.h It appears that fd.h includes a number of unneeded files and was included from standard.h, and as such served as an intermediary to provide almost everything to everyone. By removing its useless includes, a long dependency chain broke but could easily be fixed.
2012-09-02 16:34:23 -04:00
#include <proto/fd.h>
MEDIUM: connection: add a new local send-proxy transport callback This callback sends a PROXY protocol line on the outgoing connection, with the local and remote endpoint information. This is used for local connections (eg: health checks) where the other end needs to have a valid address and no connection is relayed.
2012-10-04 17:55:57 -04:00
#include <proto/frontend.h>
MAJOR: tcp: remove the specific I/O callbacks for TCP connection probes Use a single tcp_connect_probe() instead of tcp_connect_write() and tcp_connect_read(). We call this one only when no data layer function have been processed, so this is a fallback to test for completion of a connection attempt. With this done, we don't have the need for any direct I/O callback anymore. The function still relies on ->write() to wake the stream interface up, so it's not finished.
2012-07-23 09:07:23 -04:00
#include <proto/proto_tcp.h>
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
#include <proto/stream_interface.h>
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
#ifdef USE_OPENSSL
#include <proto/ssl_sock.h>
#endif
MAJOR: session: detach the connections from the stream interfaces We will need to be able to switch server connections on a session and to keep idle connections. In order to achieve this, the preliminary requirement is that the connections can survive the session and be detached from them. Right now they're still allocated at exactly the same place, so when there is a session, there are always 2 connections. We could soon improve on this by allocating the outgoing connection only during a connect(). This current patch touches a lot of code and intentionally does not change any functionnality. Performance tests show no regression (even a very minor improvement). The doc has not yet been updated.
2012-10-26 14:10:28 -04:00
struct pool_head *pool2_connection;
/* perform minimal intializations, report 0 in case of error, 1 if OK. */
int init_connection()
{
pool2_connection = create_pool("connection", sizeof (struct connection), MEM_F_SHARED);
return pool2_connection != NULL;
}
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
/* I/O callback for fd-based connections. It calls the read/write handlers
CLEANUP: fix inconsistency between fd->iocb, proto->accept and accept() There's quite some inconsistency in the internal API. listener_accept() which is the main accept() function returns void but is declared as int in the include file. It's assigned to proto->accept() for all stream protocols where an int is expected but the result is never checked (nor is it documented by the way). This proto->accept() is in turn assigned to fd->iocb() which is supposed to return an int composed of FD_WAIT_* flags, but which is never checked either. So let's fix all this mess : - nobody checks accept()'s return - nobody checks iocb()'s return - nobody sets a return value => let's mark all these functions void and keep the current ones intact. Additionally we now include listener.h from listener.c to ensure we won't silently hide this incoherency in the future. Note that this patch could/should be backported to 1.6 and even 1.5 to simplify debugging sessions.
2016-04-14 05:13:20 -04:00
* provided by the connection's sock_ops, which must be valid.
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
*/
CLEANUP: fix inconsistency between fd->iocb, proto->accept and accept() There's quite some inconsistency in the internal API. listener_accept() which is the main accept() function returns void but is declared as int in the include file. It's assigned to proto->accept() for all stream protocols where an int is expected but the result is never checked (nor is it documented by the way). This proto->accept() is in turn assigned to fd->iocb() which is supposed to return an int composed of FD_WAIT_* flags, but which is never checked either. So let's fix all this mess : - nobody checks accept()'s return - nobody checks iocb()'s return - nobody sets a return value => let's mark all these functions void and keep the current ones intact. Additionally we now include listener.h from listener.c to ensure we won't silently hide this incoherency in the future. Note that this patch could/should be backported to 1.6 and even 1.5 to simplify debugging sessions.
2016-04-14 05:13:20 -04:00
void conn_fd_handler(int fd)
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
{
MINOR: fd: make fdtab->owner a connection and not a stream_interface anymore It is more convenient with a connection here and will abstract stream_interface more easily.
2012-07-06 08:54:49 -04:00
struct connection *conn = fdtab[fd].owner;
MEDIUM: connection: only call the data->wake callback on activity We now check the connection flags for changes in order not to call the data->wake callback when there is no activity. Activity means a change on any of the CO_FL_*_SH, CO_FL_ERROR, CO_FL_CONNECTED, CO_FL_WAIT_CONN* flags, as well as a call to data->recv or data->send.
2012-10-03 15:04:48 -04:00
unsigned int flags;
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
if (unlikely(!conn))
CLEANUP: fix inconsistency between fd->iocb, proto->accept and accept() There's quite some inconsistency in the internal API. listener_accept() which is the main accept() function returns void but is declared as int in the include file. It's assigned to proto->accept() for all stream protocols where an int is expected but the result is never checked (nor is it documented by the way). This proto->accept() is in turn assigned to fd->iocb() which is supposed to return an int composed of FD_WAIT_* flags, but which is never checked either. So let's fix all this mess : - nobody checks accept()'s return - nobody checks iocb()'s return - nobody sets a return value => let's mark all these functions void and keep the current ones intact. Additionally we now include listener.h from listener.c to ensure we won't silently hide this incoherency in the future. Note that this patch could/should be backported to 1.6 and even 1.5 to simplify debugging sessions.
2016-04-14 05:13:20 -04:00
return;
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
BUG/MEDIUM: connection: always update connection flags prior to computing polling stream_int_chk_rcv_conn() did not clear connection flags before updating them. It is unsure whether this could have caused the stalled transfers that have been reported since dev15. In order to avoid such further issues, we now use a simple inline function to do all the job.
2012-12-16 13:19:13 -05:00
conn_refresh_polling_flags(conn);
flags = conn->flags & ~CO_FL_ERROR; /* ensure to call the wake handler upon error */
BUG/MAJOR: connection: always recompute polling status upon I/O Bryan Berry and Baptiste Assmann both reported some occasional CPU spinning loops where haproxy was still processing I/O but burning CPU for apparently uncaught events. What happens is the following sequence : - proxy is in TCP mode - a connection from a client initiates a connection to a server - the connection to the server does not immediately happen and is polled for - in the mean time, the client speaks and the stream interface calls ->chk_snd() on the peer connection to send the new data - chk_snd() calls send_loop() to send the data. This last one makes the connection succeed and empties the buffer, so it disables polling on the connection and on the FD by creating an update entry. - before the update is processed, poll() succeeds and reports a write event for this fd. The poller does fd_ev_set() on the FD to switch it to speculative mode - the IO handler is called with a connection which has no write flag but an FD which is enabled in speculative mode. - the connection does nothing useful. - conn_update_polling() at the end of conn_fd_handler() cannot disable the FD because there were no changes on this FD. - the handler is left with speculative polling still enabled on the FD, and will be called over and over until a poll event is needed to transfer data. There is no perfectly elegant solution to this. At least we should update the flags indicating the current polling status to reflect what is being done at the FD level. This will allow to detect that the FD needs to be disabled upon exit. chk_snd() also needs minor changes to correctly switch to speculative polling before calling send_loop(), and to reflect this in the connection flags. This is needed so that no event remains stuck there without any polling. In fact, chk_snd() and chk_rcv() should perform the same number of preparations and cleanups as conn_fd_handler().
2012-12-10 10:33:38 -05:00
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
process_handshake:
MEDIUM: connection: make use of the new polling functions Now the connection handler, the handshake callbacks and the I/O callbacks make use of the connection-layer polling functions to enable or disable polling on a file descriptor. Some changes still need to be done to avoid using the FD_WAIT_* constants.
2012-08-17 11:33:53 -04:00
/* The handshake callbacks are called in sequence. If either of them is
* missing something, it must enable the required polling at the socket
* layer of the connection. Polling state is not guaranteed when entering
* these handlers, so any handshake handler which does not complete its
OPTIM: connection: fold the error handling with handshake handling Both of them are rare and are detected from the same flags source, so let's detect errors in the handshake loop and remove two tests in the fast path. This seems to improve overall performance by less than 0.5% on connection-bound workloads.
2013-11-25 02:41:15 -05:00
* work must explicitly disable events it's not interested in. Error
* handling is also performed here in order to reduce the number of tests
* around.
MEDIUM: connection: make use of the new polling functions Now the connection handler, the handshake callbacks and the I/O callbacks make use of the connection-layer polling functions to enable or disable polling on a file descriptor. Some changes still need to be done to avoid using the FD_WAIT_* constants.
2012-08-17 11:33:53 -04:00
*/
OPTIM: connection: fold the error handling with handshake handling Both of them are rare and are detected from the same flags source, so let's detect errors in the handshake loop and remove two tests in the fast path. This seems to improve overall performance by less than 0.5% on connection-bound workloads.
2013-11-25 02:41:15 -05:00
while (unlikely(conn->flags & (CO_FL_HANDSHAKE | CO_FL_ERROR))) {
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
if (unlikely(conn->flags & CO_FL_ERROR))
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
goto leave;
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
MINOR: listener: add the "accept-netscaler-cip" option to the "bind" keyword When NetScaler application switch is used as L3+ switch, informations regarding the original IP and TCP headers are lost as a new TCP connection is created between the NetScaler and the backend server. NetScaler provides a feature to insert in the TCP data the original data that can then be consumed by the backend server. Specifications and documentations from NetScaler: https://support.citrix.com/article/CTX205670 https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/ When CIP is enabled on the NetScaler, then a TCP packet is inserted just after the TCP handshake. This is composed as: - CIP magic number : 4 bytes Both sender and receiver have to agree on a magic number so that they both handle the incoming data as a NetScaler Client IP insertion packet. - Header length : 4 bytes Defines the length on the remaining data. - IP header : >= 20 bytes if IPv4, 40 bytes if IPv6 Contains the header of the last IP packet sent by the client during TCP handshake. - TCP header : >= 20 bytes Contains the header of the last TCP packet sent by the client during TCP handshake.
2016-06-04 10:11:10 -04:00
if (conn->flags & CO_FL_ACCEPT_CIP)
if (!conn_recv_netscaler_cip(conn, CO_FL_ACCEPT_CIP))
goto leave;
MAJOR: connection: make the PROXY decoder a handshake handler The PROXY protocol is now decoded in the connection before other handshakes. This means that it may be extracted from a TCP stream before SSL is decoded from this stream.
2012-08-31 11:43:29 -04:00
if (conn->flags & CO_FL_ACCEPT_PROXY)
if (!conn_recv_proxy(conn, CO_FL_ACCEPT_PROXY))
goto leave;
MEDIUM: connection: merge the send_proxy and local_send_proxy calls We used to have two very similar functions for sending a PROXY protocol line header. The reason is that the default one relies on the stream interface to retrieve the other end's address, while the "local" one performs a local address lookup and sends that instead (used by health checks). Now that the send_proxy_ofs is stored in the connection and not the stream interface, we can make the local_send_proxy rely on it and support partial sends. This also simplifies the code by removing the local_send_proxy function, making health checks use send_proxy_ofs, resulting in the removal of the CO_FL_LOCAL_SPROXY flag, and the associated test in the connection handler. The other flag, CO_FL_SI_SEND_PROXY was renamed without the "SI" part so that it is clear that it is not dedicated anymore to a usage with a stream interface.
2013-10-24 16:01:26 -04:00
if (conn->flags & CO_FL_SEND_PROXY)
if (!conn_si_send_proxy(conn, CO_FL_SEND_PROXY))
MEDIUM: connection: add a new local send-proxy transport callback This callback sends a PROXY protocol line on the outgoing connection, with the local and remote endpoint information. This is used for local connections (eg: health checks) where the other end needs to have a valid address and no connection is relayed.
2012-10-04 17:55:57 -04:00
goto leave;
MEDIUM: ssl: add new files ssl_sock.[ch] to provide the SSL data layer This data layer supports socket-to-buffer and buffer-to-socket operations. No sock-to-pipe nor pipe-to-sock functions are provided, since splicing does not provide any benefit with data transformation. At best it could save a memcpy() and avoid keeping a buffer allocated but that does not seem very useful. An init function and a close function are provided because the SSL context needs to be allocated/freed. A data-layer shutw() function is also provided because upon successful shutdown, we want to store the SSL context in the cache in order to reuse it for future connections and avoid a new key generation. The handshake function is directly called from the connection handler. At this point it is not certain whether this will remain this way or if a new ->handshake callback will be added to the data layer so that the connection handler doesn't care about SSL. The sock-to-buf and buf-to-sock functions are all capable of enabling the SSL handshake at any time. This also implies polling in the opposite direction to what was expected. The upper layers must take that into account (it is OK right now with the stream interface).
2012-05-18 09:47:34 -04:00
#ifdef USE_OPENSSL
if (conn->flags & CO_FL_SSL_WAIT_HS)
if (!ssl_sock_handshake(conn, CO_FL_SSL_WAIT_HS))
goto leave;
#endif
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
}
MEDIUM: connection: make use of the new polling functions Now the connection handler, the handshake callbacks and the I/O callbacks make use of the connection-layer polling functions to enable or disable polling on a file descriptor. Some changes still need to be done to avoid using the FD_WAIT_* constants.
2012-08-17 11:33:53 -04:00
/* Once we're purely in the data phase, we disable handshake polling */
if (!(conn->flags & CO_FL_POLL_SOCK))
__conn_sock_stop_both(conn);
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
MEDIUM: connection: use a generic data-layer init() callback The generic data-layer init callback is now used after the transport layer is complete and before calling the data layer recv/send callbacks. This allows the session to switch from the embryonic session data layer to the complete stream interface data layer, by making conn_session_complete() the data layer's init callback. It sill looks awkwards that the init() callback must be used opon error, but except by adding yet another one, it does not seem to be mergeable into another function (eg: it should probably not be merged with ->wake to avoid unneeded calls during the handshake, though semantically that would make sense).
2012-10-02 19:39:48 -04:00
/* The data layer might not be ready yet (eg: when using embryonic
* sessions). If we're about to move data, we must initialize it first.
* The function may fail and cause the connection to be destroyed, thus
MAJOR: session: introduce embryonic sessions When an incoming connection request is accepted, a connection structure is needed to store its state. However we don't want to fully initialize a session until the data layer is about to be ready. As long as the connection is physically stored into the session, it's not easy to split both allocations. As such, we only initialize the minimum requirements of a session, which results in what we call an embryonic session. Then once the data layer is ready, we can complete the function's initialization. Doing so avoids buffers allocation and ensures that a session only sees ready connections. The frontend's client timeout is used as the handshake timeout. It is likely that another timeout will be used in the future.
2012-08-31 10:01:23 -04:00
* we must not use it anymore and should immediately leave instead.
*/
MEDIUM: connection: use a generic data-layer init() callback The generic data-layer init callback is now used after the transport layer is complete and before calling the data layer recv/send callbacks. This allows the session to switch from the embryonic session data layer to the complete stream interface data layer, by making conn_session_complete() the data layer's init callback. It sill looks awkwards that the init() callback must be used opon error, but except by adding yet another one, it does not seem to be mergeable into another function (eg: it should probably not be merged with ->wake to avoid unneeded calls during the handshake, though semantically that would make sense).
2012-10-02 19:39:48 -04:00
if ((conn->flags & CO_FL_INIT_DATA) && conn->data->init(conn) < 0)
CLEANUP: fix inconsistency between fd->iocb, proto->accept and accept() There's quite some inconsistency in the internal API. listener_accept() which is the main accept() function returns void but is declared as int in the include file. It's assigned to proto->accept() for all stream protocols where an int is expected but the result is never checked (nor is it documented by the way). This proto->accept() is in turn assigned to fd->iocb() which is supposed to return an int composed of FD_WAIT_* flags, but which is never checked either. So let's fix all this mess : - nobody checks accept()'s return - nobody checks iocb()'s return - nobody sets a return value => let's mark all these functions void and keep the current ones intact. Additionally we now include listener.h from listener.c to ensure we won't silently hide this incoherency in the future. Note that this patch could/should be backported to 1.6 and even 1.5 to simplify debugging sessions.
2016-04-14 05:13:20 -04:00
return;
MAJOR: session: introduce embryonic sessions When an incoming connection request is accepted, a connection structure is needed to store its state. However we don't want to fully initialize a session until the data layer is about to be ready. As long as the connection is physically stored into the session, it's not easy to split both allocations. As such, we only initialize the minimum requirements of a session, which results in what we call an embryonic session. Then once the data layer is ready, we can complete the function's initialization. Doing so avoids buffers allocation and ensures that a session only sees ready connections. The frontend's client timeout is used as the handshake timeout. It is likely that another timeout will be used in the future.
2012-08-31 10:01:23 -04:00
BUG/MAJOR: connection: risk of crash on certain tricky close scenario In some circumstances, if the connection to the server is aborted while some data were planned to be sent and the poller reported an ability to send, then conn_fd_handler() would still call conn->data->send(), causing the data layer to dereference the now NULL conn->xprt and crash. So we have to check for conn->xprt validity before calling the data layer. This issue was introduced after 1.5-dev12 so it does not need any backport and does not affect any released version. Special thanks go to Cristian Ditoiu who once again provided amazing help to troubleshoot this bug !
2012-10-22 16:47:55 -04:00
/* The data transfer starts here and stops on error and handshakes. Note
* that we must absolutely test conn->xprt at each step in case it suddenly
* changes due to a quick unexpected close().
*/
MEDIUM: connection: no need to recheck FD state We already have everything in the connection flags using the CO_FL_DATA_*_ENA bits combined with the fd's ready state, so we do not need to check fdtab[fd].ev anymore. This considerably simplifies the connection handling logic since it doesn't have to mix connection flags with past polling states.
2014-01-21 05:01:08 -05:00
if (conn->xprt && fd_recv_ready(fd) &&
((conn->flags & (CO_FL_DATA_RD_ENA|CO_FL_WAIT_ROOM|CO_FL_ERROR|CO_FL_HANDSHAKE)) == CO_FL_DATA_RD_ENA)) {
BUG: connection: fix regression from commit 9e272bf9 Commit 9e272bf9 broke connection setup in TCP mode, the comment was misleading and obviously wrong, as after a connection is established, we *do* have none of the CONNECT* flags. However we can never have them all at the same time, so let's use this to trigger a detection.
2012-10-05 15:29:37 -04:00
/* force detection of a flag change : it's impossible to have both
* CONNECTED and WAIT_CONN so we're certain to trigger a change.
MEDIUM: connection: only call the data->wake callback on activity We now check the connection flags for changes in order not to call the data->wake callback when there is no activity. Activity means a change on any of the CO_FL_*_SH, CO_FL_ERROR, CO_FL_CONNECTED, CO_FL_WAIT_CONN* flags, as well as a call to data->recv or data->send.
2012-10-03 15:04:48 -04:00
*/
BUG: connection: fix regression from commit 9e272bf9 Commit 9e272bf9 broke connection setup in TCP mode, the comment was misleading and obviously wrong, as after a connection is established, we *do* have none of the CONNECT* flags. However we can never have them all at the same time, so let's use this to trigger a detection.
2012-10-05 15:29:37 -04:00
flags = CO_FL_WAIT_L4_CONN | CO_FL_CONNECTED;
REORG: connection: rename app_cb "data" Now conn->data will designate the data layer which is the client for the transport layer. In practice it's the stream interface and will soon also be the health checks.
2012-10-02 18:41:04 -04:00
conn->data->recv(conn);
MEDIUM: connection: only call the data->wake callback on activity We now check the connection flags for changes in order not to call the data->wake callback when there is no activity. Activity means a change on any of the CO_FL_*_SH, CO_FL_ERROR, CO_FL_CONNECTED, CO_FL_WAIT_CONN* flags, as well as a call to data->recv or data->send.
2012-10-03 15:04:48 -04:00
}
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
MEDIUM: connection: no need to recheck FD state We already have everything in the connection flags using the CO_FL_DATA_*_ENA bits combined with the fd's ready state, so we do not need to check fdtab[fd].ev anymore. This considerably simplifies the connection handling logic since it doesn't have to mix connection flags with past polling states.
2014-01-21 05:01:08 -05:00
if (conn->xprt && fd_send_ready(fd) &&
((conn->flags & (CO_FL_DATA_WR_ENA|CO_FL_WAIT_DATA|CO_FL_ERROR|CO_FL_HANDSHAKE)) == CO_FL_DATA_WR_ENA)) {
BUG: connection: fix regression from commit 9e272bf9 Commit 9e272bf9 broke connection setup in TCP mode, the comment was misleading and obviously wrong, as after a connection is established, we *do* have none of the CONNECT* flags. However we can never have them all at the same time, so let's use this to trigger a detection.
2012-10-05 15:29:37 -04:00
/* force detection of a flag change : it's impossible to have both
* CONNECTED and WAIT_CONN so we're certain to trigger a change.
MEDIUM: connection: only call the data->wake callback on activity We now check the connection flags for changes in order not to call the data->wake callback when there is no activity. Activity means a change on any of the CO_FL_*_SH, CO_FL_ERROR, CO_FL_CONNECTED, CO_FL_WAIT_CONN* flags, as well as a call to data->recv or data->send.
2012-10-03 15:04:48 -04:00
*/
BUG: connection: fix regression from commit 9e272bf9 Commit 9e272bf9 broke connection setup in TCP mode, the comment was misleading and obviously wrong, as after a connection is established, we *do* have none of the CONNECT* flags. However we can never have them all at the same time, so let's use this to trigger a detection.
2012-10-05 15:29:37 -04:00
flags = CO_FL_WAIT_L4_CONN | CO_FL_CONNECTED;
REORG: connection: rename app_cb "data" Now conn->data will designate the data layer which is the client for the transport layer. In practice it's the stream interface and will soon also be the health checks.
2012-10-02 18:41:04 -04:00
conn->data->send(conn);
MEDIUM: connection: only call the data->wake callback on activity We now check the connection flags for changes in order not to call the data->wake callback when there is no activity. Activity means a change on any of the CO_FL_*_SH, CO_FL_ERROR, CO_FL_CONNECTED, CO_FL_WAIT_CONN* flags, as well as a call to data->recv or data->send.
2012-10-03 15:04:48 -04:00
}
MAJOR: tcp: remove the specific I/O callbacks for TCP connection probes Use a single tcp_connect_probe() instead of tcp_connect_write() and tcp_connect_read(). We call this one only when no data layer function have been processed, so this is a fallback to test for completion of a connection attempt. With this done, we don't have the need for any direct I/O callback anymore. The function still relies on ->write() to wake the stream interface up, so it's not finished.
2012-07-23 09:07:23 -04:00
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
/* It may happen during the data phase that a handshake is
* enabled again (eg: SSL)
*/
OPTIM: connection: fold the error handling with handshake handling Both of them are rare and are detected from the same flags source, so let's detect errors in the handshake loop and remove two tests in the fast path. This seems to improve overall performance by less than 0.5% on connection-bound workloads.
2013-11-25 02:41:15 -05:00
if (unlikely(conn->flags & (CO_FL_HANDSHAKE | CO_FL_ERROR)))
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
goto process_handshake;
MEDIUM: connection: add check for readiness in I/O handlers The recv/send callbacks must check for readiness themselves instead of having their callers do it. This will strengthen the test and will also ensure we never refrain from calling a handshake handler because a direction is being polled while the other one is ready.
2014-01-20 09:13:07 -05:00
if (unlikely(conn->flags & CO_FL_WAIT_L4_CONN)) {
MEDIUM: connection: only call tcp_connect_probe when nothing was attempted yet It was observed that after a failed send() on EAGAIN, a second connect() would still be attempted in tcp_connect_probe() because there was no way to know that a send() had failed. By checking the WANT_WR status flag, we know if a previous write attempt failed on EAGAIN, so we don't try to connect again if we know this has already failed. With this simple change, the second connect() has disappeared.
2012-09-01 11:59:22 -04:00
/* still waiting for a connection to establish and nothing was
* attempted yet to probe the connection. Then let's retry the
* connect().
MAJOR: tcp: remove the specific I/O callbacks for TCP connection probes Use a single tcp_connect_probe() instead of tcp_connect_write() and tcp_connect_read(). We call this one only when no data layer function have been processed, so this is a fallback to test for completion of a connection attempt. With this done, we don't have the need for any direct I/O callback anymore. The function still relies on ->write() to wake the stream interface up, so it's not finished.
2012-07-23 09:07:23 -04:00
*/
MEDIUM: stream_interface: pass connection instead of fd in sock_ops The sock_ops I/O callbacks made use of an FD till now. This has become inappropriate and the struct connection is much more useful. It also fixes the race condition introduced by previous change.
2012-07-23 12:53:03 -04:00
if (!tcp_connect_probe(conn))
MAJOR: make use of conn_{data|sock}_{poll|stop|want}* in connection handlers This is a second attempt at getting rid of FD_WAIT_*. Now the situation is much better since native I/O handlers can directly manipulate the FD using fd_{poll|want|stop}_* and the connection handlers manipulate connection-level flags using the conn_{data|sock}_* equivalent. Proceeding this way ensures that the connection flags always reflect the reality even after data<->handshake switches.
2012-08-09 08:45:22 -04:00
goto leave;
MAJOR: tcp: remove the specific I/O callbacks for TCP connection probes Use a single tcp_connect_probe() instead of tcp_connect_write() and tcp_connect_read(). We call this one only when no data layer function have been processed, so this is a fallback to test for completion of a connection attempt. With this done, we don't have the need for any direct I/O callback anymore. The function still relies on ->write() to wake the stream interface up, so it's not finished.
2012-07-23 09:07:23 -04:00
}
MEDIUM: connection: extract the send_proxy callback from proto_tcp This handshake handler must be independant, so move it away from proto_tcp. It has a dedicated connection flag. It is tested before I/O handlers and automatically removes the CO_FL_WAIT_L4_CONN flag upon success. It also sets the BF_WRITE_NULL flag on the stream interface and stops the SI timeout. However it does not perform the task_wakeup(), and relies on the data handler to do so for now. The SI wakeup will have to be moved elsewhere anyway.
2012-07-06 11:12:34 -04:00
leave:
MEDIUM: connection: make it possible for data->wake to return an error Just like ->init(), ->wake() may now be used to return an error and abort the connection. Currently this is not used but will be with embryonic sessions.
2012-10-03 15:12:16 -04:00
/* The wake callback may be used to process a critical error and abort the
* connection. If so, we don't want to go further as the connection will
* have been released and the FD destroyed.
*/
if ((conn->flags & CO_FL_WAKE_DATA) &&
((conn->flags ^ flags) & CO_FL_CONN_STATE) &&
conn->data->wake(conn) < 0)
CLEANUP: fix inconsistency between fd->iocb, proto->accept and accept() There's quite some inconsistency in the internal API. listener_accept() which is the main accept() function returns void but is declared as int in the include file. It's assigned to proto->accept() for all stream protocols where an int is expected but the result is never checked (nor is it documented by the way). This proto->accept() is in turn assigned to fd->iocb() which is supposed to return an int composed of FD_WAIT_* flags, but which is never checked either. So let's fix all this mess : - nobody checks accept()'s return - nobody checks iocb()'s return - nobody sets a return value => let's mark all these functions void and keep the current ones intact. Additionally we now include listener.h from listener.c to ensure we won't silently hide this incoherency in the future. Note that this patch could/should be backported to 1.6 and even 1.5 to simplify debugging sessions.
2016-04-14 05:13:20 -04:00
return;
MAJOR: remove the stream interface and task management code from sock_* The socket data layer code must only focus on moving data between a socket and a buffer. We need a special stream interface handler to update the stream interface and the file descriptor status. At the moment the code works but suffers from a race condition caused by its API : the read/write callbacks still make use of the fd instead of using the connection. And when a double shutdown is performed, a call to ->write() after ->read() processed an error results in dereferencing a NULL fdtab[]->owner. This is only a temporary issue which doesn't need to be fixed now since this will automatically go away when the functions change to use the connection instead.
2012-07-23 12:24:25 -04:00
MAJOR: connection: add a new CO_FL_CONNECTED flag This new flag is used to indicate that the connection was already connected. It can be used by I/O handlers to know that a connection has just completed. It is used by stream_sock_update_conn(), allowing the sock_opt handlers not to manipulate the SI timeout nor the BF_WRITE_NULL flag anymore.
2012-07-23 13:45:44 -04:00
/* Last check, verify if the connection just established */
MAJOR: connection: call data layer handshakes from the handler Handshakes is not called anymore from the data handlers, they're only called from the connection handler when their flag is set. Also, this move has uncovered an issue with the stream interface notifier : it doesn't consider the FD_WAIT_* flags possibly set by the handshake handlers. This will result in a stuck handshake when no data is in the output buffer. In order to cover this, for now we'll perform the EV_FD_SET in the SSL handshake function, but this needs to be addressed separately from the stream interface operations.
2012-07-12 09:32:13 -04:00
if (unlikely(!(conn->flags & (CO_FL_WAIT_L4_CONN | CO_FL_WAIT_L6_CONN | CO_FL_CONNECTED))))
MAJOR: connection: add a new CO_FL_CONNECTED flag This new flag is used to indicate that the connection was already connected. It can be used by I/O handlers to know that a connection has just completed. It is used by stream_sock_update_conn(), allowing the sock_opt handlers not to manipulate the SI timeout nor the BF_WRITE_NULL flag anymore.
2012-07-23 13:45:44 -04:00
conn->flags |= CO_FL_CONNECTED;
MEDIUM: connection: remove the FD_POLL_* flags only once It's inappropriate to remove FD_POLL_IN and FD_POLL_OUT in the IO callback handlers, first because they shouldn't care about this, and second because it will make it harder to chain multiple callers. So let's flush these flags only once for all in the connection handler. Right now, the HUP and ERR flags are still flushed in each IO handler to avoid multiple calls. This will probably have to be fixed later.
2012-07-23 06:14:26 -04:00
/* remove the events before leaving */
BUG/MAJOR: polling: do not set speculative events on ERR nor HUP Errors and Hangups are sticky events, which means that once they're detected, we never clear them, allowing them to be handled later if needed. Till now when an error was reported, it used to register a speculative I/O event for both recv and send. Since the connection had not requested such events, it was not able to detect a change and did not clear them, so the events were called in loops until a timeout caused their owner task to die. So this patch does two things : - stop registering spec events when no I/O activity was requested, so that we don't end up with non-disablable polling state ; - keep the sticky polling flags (ERR and HUP) when leaving the connection handler so that an error notification doesn't magically become a normal recv() or send() report once the event is converted to a spec event. It is normally not needed to make the connection handler emit an error when it detects POLL_ERR because either a registered data handler will have done it, or the event will be disabled by the wake() callback.
2012-12-06 18:09:43 -05:00
fdtab[fd].ev &= FD_POLL_STICKY;
MEDIUM: connection: make use of the new polling functions Now the connection handler, the handshake callbacks and the I/O callbacks make use of the connection-layer polling functions to enable or disable polling on a file descriptor. Some changes still need to be done to avoid using the FD_WAIT_* constants.
2012-08-17 11:33:53 -04:00
/* commit polling changes */
conn_cond_update_polling(conn);
CLEANUP: fix inconsistency between fd->iocb, proto->accept and accept() There's quite some inconsistency in the internal API. listener_accept() which is the main accept() function returns void but is declared as int in the include file. It's assigned to proto->accept() for all stream protocols where an int is expected but the result is never checked (nor is it documented by the way). This proto->accept() is in turn assigned to fd->iocb() which is supposed to return an int composed of FD_WAIT_* flags, but which is never checked either. So let's fix all this mess : - nobody checks accept()'s return - nobody checks iocb()'s return - nobody sets a return value => let's mark all these functions void and keep the current ones intact. Additionally we now include listener.h from listener.c to ensure we won't silently hide this incoherency in the future. Note that this patch could/should be backported to 1.6 and even 1.5 to simplify debugging sessions.
2016-04-14 05:13:20 -04:00
return;
MINOR: connection: add a handler for fd-based connections This connection handler will be used as an I/O handler for events detected on a file descriptor. It is not used yet.
2012-07-06 08:13:49 -04:00
}
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
/* Update polling on connection <c>'s file descriptor depending on its current
* state as reported in the connection's CO_FL_CURR_* flags, reports of EAGAIN
* in CO_FL_WAIT_*, and the data layer expectations indicated by CO_FL_DATA_*.
* The connection flags are updated with the new flags at the end of the
MEDIUM: connection: automatically disable polling on error We absolutely want to disable FD polling after an error is detected, otherwise the data layer has to do it and it's far from being obvious at these layers. The way we did it was a bit tricky in conn_update_*_polling and conn_*_polling_changes. However it has almost no impact on performance and code size both for the fast and slow path. We'll now be able to remove some flag updates in the stream interface.
2012-10-04 16:21:15 -04:00
* operation. Polling is totally disabled if an error was reported.
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
*/
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
void conn_update_data_polling(struct connection *c)
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
{
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
unsigned int f = c->flags;
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 07:50:42 -05:00
if (!conn_ctrl_ready(c))
MAJOR: connection: add two new flags to indicate readiness of control/transport Currently the control and transport layers of a connection are supposed to be initialized when their respective pointers are not NULL. This will not work anymore when we plan to reuse connections, because there is an asymmetry between the accept() side and the connect() side : - on accept() side, the fd is set first, then the ctrl layer then the transport layer ; upon error, they must be undone in the reverse order, then the FD must be closed. The FD must not be deleted if the control layer was not yet initialized ; - on the connect() side, the fd is set last and there is no reliable way to know if it has been initialized or not. In practice it's initialized to -1 first but this is hackish and supposes that local FDs only will be used forever. Also, there are even less solutions for keeping trace of the transport layer's state. Also it is possible to support delayed close() when something (eg: logs) tracks some information requiring the transport and/or control layers, making it even more difficult to clean them. So the proposed solution is to add two flags to the connection : - CO_FL_CTRL_READY is set when the control layer is initialized (fd_insert) and cleared after it's released (fd_delete). - CO_FL_XPRT_READY is set when the control layer is initialized (xprt->init) and cleared after it's released (xprt->close). The functions have been adapted to rely on this and not on the pointers anymore. conn_xprt_close() was unused and dangerous : it did not close the control layer (eg: the socket itself) but still marks the transport layer as closed, preventing any future call to conn_full_close() from finishing the job. The problem comes from conn_full_close() in fact. It needs to close the xprt and ctrl layers independantly. After that we're still having an issue : we don't know based on ->ctrl alone whether the fd was registered or not. For this we use the two new flags CO_FL_XPRT_READY and CO_FL_CTRL_READY. We now rely on this and not on conn->xprt nor conn->ctrl anymore to decide what remains to be done on the connection. In order not to miss some flag assignments, we introduce conn_ctrl_init() to initialize the control layer, register the fd using fd_insert() and set the flag, and conn_ctrl_close() which unregisters the fd and removes the flag, but only if the transport layer was closed. Similarly, at the transport layer, conn_xprt_init() calls ->init and sets the flag, while conn_xprt_close() checks the flag, calls ->close and clears the flag, regardless xprt_ctx or xprt_st. This also ensures that the ->init and the ->close functions are called only once each and in the correct order. Note that conn_xprt_close() does nothing if the transport layer is still tracked. conn_full_close() now simply calls conn_xprt_close() then conn_full_close() in turn, which do nothing if CO_FL_XPRT_TRACKED is set. In order to handle the error path, we also provide conn_force_close() which ignores CO_FL_XPRT_TRACKED and closes the transport and the control layers in turns. All relevant instances of fd_delete() have been replaced with conn_force_close(). Now we always know what state the connection is in and we can expect to split its initialization.
2013-10-21 10:30:56 -04:00
return;
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
/* update read status if needed */
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
if (unlikely((f & (CO_FL_CURR_RD_ENA|CO_FL_DATA_RD_ENA)) == CO_FL_DATA_RD_ENA)) {
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
fd_want_recv(c->t.sock.fd);
MAJOR: connection: remove the CO_FL_CURR_*_POL flag This is the first step of a series of changes aiming at making the polling totally event-driven. This first change consists in only remembering at the connection level whether an FD was enabled or not, regardless of the fact it was being polled or cached. From now on, an EAGAIN will always be considered as a change so that the pollers are able to manage a cache and to flush it based on such events. One of the noticeable effect is that conn_fd_handler() is called once more per session (6 instead of 5 min) but other update functions are less called. Note that the performance loss caused by this change at the moment is quite significant, around 2.5%, but the change is needed to have SSL working correctly in all situations, even when data were read from the socket and stored in the invisible cache, waiting for some room in the channel's buffer.
2012-11-05 11:52:26 -05:00
f |= CO_FL_CURR_RD_ENA;
}
else if (unlikely((f & (CO_FL_CURR_RD_ENA|CO_FL_DATA_RD_ENA)) == CO_FL_CURR_RD_ENA)) {
fd_stop_recv(c->t.sock.fd);
f &= ~CO_FL_CURR_RD_ENA;
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
}
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
/* update write status if needed */
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
if (unlikely((f & (CO_FL_CURR_WR_ENA|CO_FL_DATA_WR_ENA)) == CO_FL_DATA_WR_ENA)) {
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
fd_want_send(c->t.sock.fd);
MAJOR: connection: remove the CO_FL_CURR_*_POL flag This is the first step of a series of changes aiming at making the polling totally event-driven. This first change consists in only remembering at the connection level whether an FD was enabled or not, regardless of the fact it was being polled or cached. From now on, an EAGAIN will always be considered as a change so that the pollers are able to manage a cache and to flush it based on such events. One of the noticeable effect is that conn_fd_handler() is called once more per session (6 instead of 5 min) but other update functions are less called. Note that the performance loss caused by this change at the moment is quite significant, around 2.5%, but the change is needed to have SSL working correctly in all situations, even when data were read from the socket and stored in the invisible cache, waiting for some room in the channel's buffer.
2012-11-05 11:52:26 -05:00
f |= CO_FL_CURR_WR_ENA;
}
else if (unlikely((f & (CO_FL_CURR_WR_ENA|CO_FL_DATA_WR_ENA)) == CO_FL_CURR_WR_ENA)) {
fd_stop_send(c->t.sock.fd);
f &= ~CO_FL_CURR_WR_ENA;
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
}
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
c->flags = f;
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
}
/* Update polling on connection <c>'s file descriptor depending on its current
* state as reported in the connection's CO_FL_CURR_* flags, reports of EAGAIN
* in CO_FL_WAIT_*, and the sock layer expectations indicated by CO_FL_SOCK_*.
* The connection flags are updated with the new flags at the end of the
MEDIUM: connection: automatically disable polling on error We absolutely want to disable FD polling after an error is detected, otherwise the data layer has to do it and it's far from being obvious at these layers. The way we did it was a bit tricky in conn_update_*_polling and conn_*_polling_changes. However it has almost no impact on performance and code size both for the fast and slow path. We'll now be able to remove some flag updates in the stream interface.
2012-10-04 16:21:15 -04:00
* operation. Polling is totally disabled if an error was reported.
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
*/
void conn_update_sock_polling(struct connection *c)
{
unsigned int f = c->flags;
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 07:50:42 -05:00
if (!conn_ctrl_ready(c))
MAJOR: connection: add two new flags to indicate readiness of control/transport Currently the control and transport layers of a connection are supposed to be initialized when their respective pointers are not NULL. This will not work anymore when we plan to reuse connections, because there is an asymmetry between the accept() side and the connect() side : - on accept() side, the fd is set first, then the ctrl layer then the transport layer ; upon error, they must be undone in the reverse order, then the FD must be closed. The FD must not be deleted if the control layer was not yet initialized ; - on the connect() side, the fd is set last and there is no reliable way to know if it has been initialized or not. In practice it's initialized to -1 first but this is hackish and supposes that local FDs only will be used forever. Also, there are even less solutions for keeping trace of the transport layer's state. Also it is possible to support delayed close() when something (eg: logs) tracks some information requiring the transport and/or control layers, making it even more difficult to clean them. So the proposed solution is to add two flags to the connection : - CO_FL_CTRL_READY is set when the control layer is initialized (fd_insert) and cleared after it's released (fd_delete). - CO_FL_XPRT_READY is set when the control layer is initialized (xprt->init) and cleared after it's released (xprt->close). The functions have been adapted to rely on this and not on the pointers anymore. conn_xprt_close() was unused and dangerous : it did not close the control layer (eg: the socket itself) but still marks the transport layer as closed, preventing any future call to conn_full_close() from finishing the job. The problem comes from conn_full_close() in fact. It needs to close the xprt and ctrl layers independantly. After that we're still having an issue : we don't know based on ->ctrl alone whether the fd was registered or not. For this we use the two new flags CO_FL_XPRT_READY and CO_FL_CTRL_READY. We now rely on this and not on conn->xprt nor conn->ctrl anymore to decide what remains to be done on the connection. In order not to miss some flag assignments, we introduce conn_ctrl_init() to initialize the control layer, register the fd using fd_insert() and set the flag, and conn_ctrl_close() which unregisters the fd and removes the flag, but only if the transport layer was closed. Similarly, at the transport layer, conn_xprt_init() calls ->init and sets the flag, while conn_xprt_close() checks the flag, calls ->close and clears the flag, regardless xprt_ctx or xprt_st. This also ensures that the ->init and the ->close functions are called only once each and in the correct order. Note that conn_xprt_close() does nothing if the transport layer is still tracked. conn_full_close() now simply calls conn_xprt_close() then conn_full_close() in turn, which do nothing if CO_FL_XPRT_TRACKED is set. In order to handle the error path, we also provide conn_force_close() which ignores CO_FL_XPRT_TRACKED and closes the transport and the control layers in turns. All relevant instances of fd_delete() have been replaced with conn_force_close(). Now we always know what state the connection is in and we can expect to split its initialization.
2013-10-21 10:30:56 -04:00
return;
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
/* update read status if needed */
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
if (unlikely((f & (CO_FL_CURR_RD_ENA|CO_FL_SOCK_RD_ENA)) == CO_FL_SOCK_RD_ENA)) {
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
fd_want_recv(c->t.sock.fd);
MAJOR: connection: remove the CO_FL_CURR_*_POL flag This is the first step of a series of changes aiming at making the polling totally event-driven. This first change consists in only remembering at the connection level whether an FD was enabled or not, regardless of the fact it was being polled or cached. From now on, an EAGAIN will always be considered as a change so that the pollers are able to manage a cache and to flush it based on such events. One of the noticeable effect is that conn_fd_handler() is called once more per session (6 instead of 5 min) but other update functions are less called. Note that the performance loss caused by this change at the moment is quite significant, around 2.5%, but the change is needed to have SSL working correctly in all situations, even when data were read from the socket and stored in the invisible cache, waiting for some room in the channel's buffer.
2012-11-05 11:52:26 -05:00
f |= CO_FL_CURR_RD_ENA;
}
else if (unlikely((f & (CO_FL_CURR_RD_ENA|CO_FL_SOCK_RD_ENA)) == CO_FL_CURR_RD_ENA)) {
fd_stop_recv(c->t.sock.fd);
f &= ~CO_FL_CURR_RD_ENA;
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
}
/* update write status if needed */
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
if (unlikely((f & (CO_FL_CURR_WR_ENA|CO_FL_SOCK_WR_ENA)) == CO_FL_SOCK_WR_ENA)) {
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
fd_want_send(c->t.sock.fd);
MAJOR: connection: remove the CO_FL_CURR_*_POL flag This is the first step of a series of changes aiming at making the polling totally event-driven. This first change consists in only remembering at the connection level whether an FD was enabled or not, regardless of the fact it was being polled or cached. From now on, an EAGAIN will always be considered as a change so that the pollers are able to manage a cache and to flush it based on such events. One of the noticeable effect is that conn_fd_handler() is called once more per session (6 instead of 5 min) but other update functions are less called. Note that the performance loss caused by this change at the moment is quite significant, around 2.5%, but the change is needed to have SSL working correctly in all situations, even when data were read from the socket and stored in the invisible cache, waiting for some room in the channel's buffer.
2012-11-05 11:52:26 -05:00
f |= CO_FL_CURR_WR_ENA;
}
else if (unlikely((f & (CO_FL_CURR_WR_ENA|CO_FL_SOCK_WR_ENA)) == CO_FL_CURR_WR_ENA)) {
fd_stop_send(c->t.sock.fd);
f &= ~CO_FL_CURR_WR_ENA;
MAJOR: connection: rearrange the polling flags. Polling flags were set for data and sock layer, but while this does make sense for the ENA flag, it does not for the POL flag which translates the detection of an EAGAIN condition. So now we remove the {DATA,SOCK}_POL* flags and instead introduce two new layer-independant flags (WANT_RD and WANT_WR). These flags are only set when an EAGAIN is encountered so that polling can be enabled. In order for these flags to have any meaning they are not persistent and have to be cleared by the connection handler before calling the I/O and data callbacks. For this reason, changes detection has been slightly improved. Instead of comparing the WANT_* flags with CURR_*_POL, we only check if the ENA status changes, or if the polling appears, since we don't want to detect the useless poll to ena transition. Tests show that this has eliminated one useless call to __fd_clr(). Finally the conn_set_polling() function which was becoming complex and required complex operations from the caller was split in two and replaced its two only callers (conn_update_data_polling and conn_update_sock_polling). The two functions are now much smaller due to the less complex conditions. Note that it would be possible to re-merge them and only pass a mask but this does not appear much interesting.
2012-09-01 11:26:16 -04:00
}
MAJOR: connection: remove the CO_FL_WAIT_{RD,WR} flags These flags were used to report the readiness of the file descriptor. Now this readiness is directly checked at the file descriptor itself. This removes the need for constantly synchronizing updates between the file descriptor and the connection and ensures that all layers share the same level of information. For now, the readiness is updated in conn_{sock,data}_poll_* by directly touching the file descriptor. This must move to the lower layers instead so that these functions can disappear as well. In this state, the change works but is incomplete. It's sensible enough to avoid making it more complex. Now the sock/data updates become much simpler because they just have to enable/disable access to a file descriptor and not to care anymore about its readiness.
2014-01-22 13:46:33 -05:00
c->flags = f;
MEDIUM: connection: add definitions for dual polling mechanisms The conflicts we're facing with polling is that handshake handlers have precedence over data handlers and may change the polling requirements regardless of what is expected by the data layer. This causes issues such as missed events. The real need is to have three polling levels : - the "current" one, which is effective at any moment - the data one, which reflects what the data layer asks for - the sock one, which reflects what the socket layer asks for Depending on whether a handshake is in progress or not, either one of the last two will replace the current one, and the change will be propagated to the lower layers. At the moment, the shutdown status is not considered, and only handshakes are used to decide which layer to chose. This will probably change.
2012-08-17 05:55:04 -04:00
}
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
MINOR: connection: implement conn_sock_send() This function is an equivalent to send() which operates over a connection instead of a file descriptor. It checks that the control layer is ready and that it's allowed to send. If automatically enables polling if it cannot send. It simplifies the return checks by returning zero in all cases where it cannot send so that the caller only has to care about negative values indicating errors.
2015-03-12 18:56:52 -04:00
/* Send a message over an established connection. It makes use of send() and
* returns the same return code and errno. If the socket layer is not ready yet
* then -1 is returned and ENOTSOCK is set into errno. If the fd is not marked
* as ready, or if EAGAIN or ENOTCONN is returned, then we return 0. It returns
* EMSGSIZE if called with a zero length message. The purpose is to simplify
* some rare attempts to directly write on the socket from above the connection
* (typically send_proxy). In case of EAGAIN, the fd is marked as "cant_send".
* It automatically retries on EINTR. Other errors cause the connection to be
* marked as in error state. It takes similar arguments as send() except the
* first one which is the connection instead of the file descriptor. Note,
* MSG_DONTWAIT and MSG_NOSIGNAL are forced on the flags.
*/
int conn_sock_send(struct connection *conn, const void *buf, int len, int flags)
{
int ret;
ret = -1;
errno = ENOTSOCK;
if (conn->flags & CO_FL_SOCK_WR_SH)
goto fail;
if (!conn_ctrl_ready(conn))
goto fail;
errno = EMSGSIZE;
if (!len)
goto fail;
if (!fd_send_ready(conn->t.sock.fd))
goto wait;
do {
ret = send(conn->t.sock.fd, buf, len, flags | MSG_DONTWAIT | MSG_NOSIGNAL);
} while (ret < 0 && errno == EINTR);
if (ret > 0)
return ret;
if (ret == 0 || errno == EAGAIN || errno == ENOTCONN) {
wait:
fd_cant_send(conn->t.sock.fd);
return 0;
}
fail:
conn->flags |= CO_FL_SOCK_RD_SH | CO_FL_SOCK_WR_SH | CO_FL_ERROR;
return ret;
}
REORG: connection: move conn_drain() to connection.c and rename it It's now called conn_sock_drain() to make it clear that it only reads at the sock layer and not at the data layer. The function was too big to remain inlined and it's used at a few places where size counts.
2015-03-12 19:40:28 -04:00
/* Drains possibly pending incoming data on the file descriptor attached to the
* connection and update the connection's flags accordingly. This is used to
* know whether we need to disable lingering on close. Returns non-zero if it
* is safe to close without disabling lingering, otherwise zero. The SOCK_RD_SH
* flag may also be updated if the incoming shutdown was reported by the drain()
* function.
*/
int conn_sock_drain(struct connection *conn)
{
if (!conn_ctrl_ready(conn))
return 1;
if (conn->flags & (CO_FL_ERROR | CO_FL_SOCK_RD_SH))
return 1;
if (fdtab[conn->t.sock.fd].ev & (FD_POLL_ERR|FD_POLL_HUP)) {
fdtab[conn->t.sock.fd].linger_risk = 0;
}
else {
if (!fd_recv_ready(conn->t.sock.fd))
return 0;
/* disable draining if we were called and have no drain function */
if (!conn->ctrl->drain) {
__conn_data_stop_recv(conn);
return 0;
}
if (conn->ctrl->drain(conn->t.sock.fd) <= 0)
return 0;
}
conn->flags |= CO_FL_SOCK_RD_SH;
return 1;
}
MAJOR: namespace: add Linux network namespace support This patch makes it possible to create binds and servers in separate namespaces. This can be used to proxy between multiple completely independent virtual networks (with possibly overlapping IP addresses) and a non-namespace-aware proxy implementation that supports the proxy protocol (v2). The setup is something like this: net1 on VLAN 1 (namespace 1) -\ net2 on VLAN 2 (namespace 2) -- haproxy ==== proxy (namespace 0) net3 on VLAN 3 (namespace 3) -/ The proxy is configured to make server connections through haproxy and sending the expected source/target addresses to haproxy using the proxy protocol. The network namespace setup on the haproxy node is something like this: = 8< = $ cat setup.sh ip netns add 1 ip link add link eth1 type vlan id 1 ip link set eth1.1 netns 1 ip netns exec 1 ip addr add 192.168.91.2/24 dev eth1.1 ip netns exec 1 ip link set eth1.$id up ... = 8< = = 8< = $ cat haproxy.cfg frontend clients bind 127.0.0.1:50022 namespace 1 transparent default_backend scb backend server mode tcp server server1 192.168.122.4:2222 namespace 2 send-proxy-v2 = 8< = A bind line creates the listener in the specified namespace, and connections originating from that listener also have their network namespace set to that of the listener. A server line either forces the connection to be made in a specified namespace or may use the namespace from the client-side connection if that was set. For more documentation please read the documentation included in the patch itself. Signed-off-by: KOVACS Tamas <ktamas@balabit.com> Signed-off-by: Sarkozi Laszlo <laszlo.sarkozi@balabit.com> Signed-off-by: KOVACS Krisztian <hidden@balabit.com>
2014-11-17 09:11:45 -05:00
/*
* Get data length from tlv
*/
static int get_tlv_length(const struct tlv *src)
{
return (src->length_hi << 8) | src->length_lo;
}
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
/* This handshake handler waits a PROXY protocol header at the beginning of the
* raw data stream. The header looks like this :
*
* "PROXY" <SP> PROTO <SP> SRC3 <SP> DST3 <SP> SRC4 <SP> <DST4> "\r\n"
*
* There must be exactly one space between each field. Fields are :
* - PROTO : layer 4 protocol, which must be "TCP4" or "TCP6".
* - SRC3 : layer 3 (eg: IP) source address in standard text form
* - DST3 : layer 3 (eg: IP) destination address in standard text form
* - SRC4 : layer 4 (eg: TCP port) source address in standard text form
* - DST4 : layer 4 (eg: TCP port) destination address in standard text form
*
* This line MUST be at the beginning of the buffer and MUST NOT wrap.
*
* The header line is small and in all cases smaller than the smallest normal
* TCP MSS. So it MUST always be delivered as one segment, which ensures we
* can safely use MSG_PEEK and avoid buffering.
*
* Once the data is fetched, the values are set in the connection's address
* fields, and data are removed from the socket's buffer. The function returns
* zero if it needs to wait for more data or if it fails, or 1 if it completed
* and removed itself.
*/
int conn_recv_proxy(struct connection *conn, int flag)
{
char *line, *end;
MEDIUM: connection: add support for proxy protocol v2 in accept-proxy The "accept-proxy" statement of bind lines was still limited to version 1 of the protocol, while send-proxy-v2 is now available on the server lines. This patch adds support for parsing v2 of the protocol on incoming connections. The v2 header is automatically recognized so there is no need for a new option.
2014-06-14 05:06:17 -04:00
struct proxy_hdr_v2 *hdr_v2;
const char v2sig[] = PP2_SIGNATURE;
MAJOR: namespace: add Linux network namespace support This patch makes it possible to create binds and servers in separate namespaces. This can be used to proxy between multiple completely independent virtual networks (with possibly overlapping IP addresses) and a non-namespace-aware proxy implementation that supports the proxy protocol (v2). The setup is something like this: net1 on VLAN 1 (namespace 1) -\ net2 on VLAN 2 (namespace 2) -- haproxy ==== proxy (namespace 0) net3 on VLAN 3 (namespace 3) -/ The proxy is configured to make server connections through haproxy and sending the expected source/target addresses to haproxy using the proxy protocol. The network namespace setup on the haproxy node is something like this: = 8< = $ cat setup.sh ip netns add 1 ip link add link eth1 type vlan id 1 ip link set eth1.1 netns 1 ip netns exec 1 ip addr add 192.168.91.2/24 dev eth1.1 ip netns exec 1 ip link set eth1.$id up ... = 8< = = 8< = $ cat haproxy.cfg frontend clients bind 127.0.0.1:50022 namespace 1 transparent default_backend scb backend server mode tcp server server1 192.168.122.4:2222 namespace 2 send-proxy-v2 = 8< = A bind line creates the listener in the specified namespace, and connections originating from that listener also have their network namespace set to that of the listener. A server line either forces the connection to be made in a specified namespace or may use the namespace from the client-side connection if that was set. For more documentation please read the documentation included in the patch itself. Signed-off-by: KOVACS Tamas <ktamas@balabit.com> Signed-off-by: Sarkozi Laszlo <laszlo.sarkozi@balabit.com> Signed-off-by: KOVACS Krisztian <hidden@balabit.com>
2014-11-17 09:11:45 -05:00
int tlv_length = 0;
BUG/MAJOR: connection: fix TLV offset calculation for proxy protocol v2 parsing Until now, the code assumed that it can get the offset to the first TLV header just by subtracting the length of the TLV part from the length of the complete buffer. However, if the buffer contains actual data after the header, this computation is flawed and leads to haproxy trying to parse TLV headers from the proxied data. This change fixes this by making sure that the offset to the first TLV header is calculated based from the start of the buffer -- simply by adding the size of the proxy protocol v2 header plus the address family-dependent size of the address information block.
2015-07-03 08:09:10 -04:00
int tlv_offset = 0;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
/* we might have been called just after an asynchronous shutr */
if (conn->flags & CO_FL_SOCK_RD_SH)
goto fail;
CLEANUP: connection: use conn_ctrl_ready() instead of checking the flag It's easier and safer to rely on conn_ctrl_ready() everywhere than to check the flag itself. It will also simplify adding extra checks later if needed. Some useless controls for !ctrl have been removed, as the CTRL_READY flag itself guarantees ctrl is set.
2014-01-23 07:50:42 -05:00
if (!conn_ctrl_ready(conn))
MAJOR: connection: add two new flags to indicate readiness of control/transport Currently the control and transport layers of a connection are supposed to be initialized when their respective pointers are not NULL. This will not work anymore when we plan to reuse connections, because there is an asymmetry between the accept() side and the connect() side : - on accept() side, the fd is set first, then the ctrl layer then the transport layer ; upon error, they must be undone in the reverse order, then the FD must be closed. The FD must not be deleted if the control layer was not yet initialized ; - on the connect() side, the fd is set last and there is no reliable way to know if it has been initialized or not. In practice it's initialized to -1 first but this is hackish and supposes that local FDs only will be used forever. Also, there are even less solutions for keeping trace of the transport layer's state. Also it is possible to support delayed close() when something (eg: logs) tracks some information requiring the transport and/or control layers, making it even more difficult to clean them. So the proposed solution is to add two flags to the connection : - CO_FL_CTRL_READY is set when the control layer is initialized (fd_insert) and cleared after it's released (fd_delete). - CO_FL_XPRT_READY is set when the control layer is initialized (xprt->init) and cleared after it's released (xprt->close). The functions have been adapted to rely on this and not on the pointers anymore. conn_xprt_close() was unused and dangerous : it did not close the control layer (eg: the socket itself) but still marks the transport layer as closed, preventing any future call to conn_full_close() from finishing the job. The problem comes from conn_full_close() in fact. It needs to close the xprt and ctrl layers independantly. After that we're still having an issue : we don't know based on ->ctrl alone whether the fd was registered or not. For this we use the two new flags CO_FL_XPRT_READY and CO_FL_CTRL_READY. We now rely on this and not on conn->xprt nor conn->ctrl anymore to decide what remains to be done on the connection. In order not to miss some flag assignments, we introduce conn_ctrl_init() to initialize the control layer, register the fd using fd_insert() and set the flag, and conn_ctrl_close() which unregisters the fd and removes the flag, but only if the transport layer was closed. Similarly, at the transport layer, conn_xprt_init() calls ->init and sets the flag, while conn_xprt_close() checks the flag, calls ->close and clears the flag, regardless xprt_ctx or xprt_st. This also ensures that the ->init and the ->close functions are called only once each and in the correct order. Note that conn_xprt_close() does nothing if the transport layer is still tracked. conn_full_close() now simply calls conn_xprt_close() then conn_full_close() in turn, which do nothing if CO_FL_XPRT_TRACKED is set. In order to handle the error path, we also provide conn_force_close() which ignores CO_FL_XPRT_TRACKED and closes the transport and the control layers in turns. All relevant instances of fd_delete() have been replaced with conn_force_close(). Now we always know what state the connection is in and we can expect to split its initialization.
2013-10-21 10:30:56 -04:00
goto fail;
MEDIUM: connection: add check for readiness in I/O handlers The recv/send callbacks must check for readiness themselves instead of having their callers do it. This will strengthen the test and will also ensure we never refrain from calling a handshake handler because a direction is being polled while the other one is ready.
2014-01-20 09:13:07 -05:00
if (!fd_recv_ready(conn->t.sock.fd))
return 0;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
do {
MEDIUM: make the trash be a chunk instead of a char * The trash is used everywhere to store the results of temporary strings built out of s(n)printf, or as a storage for a chunk when chunks are needed. Using global.tune.bufsize is not the most convenient thing either. So let's replace trash with a chunk and directly use it as such. We can then use trash.size as the natural way to get its size, and get rid of many intermediary chunks that were previously used. The patch is huge because it touches many areas but it makes the code a lot more clear and even outlines places where trash was used without being that obvious.
2012-10-29 11:51:55 -04:00
trash.len = recv(conn->t.sock.fd, trash.str, trash.size, MSG_PEEK);
if (trash.len < 0) {
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
if (errno == EINTR)
continue;
if (errno == EAGAIN) {
MEDIUM: connection: remove conn_{data,sock}_poll_{recv,send} We simply remove these functions and replace their calls with the appropriate ones : - if we're in the data phase, we can simply report wait on the FD - if we're in the socket phase, we may also have to signal the desire to read/write on the socket because it might not be active yet.
2014-01-22 14:02:06 -05:00
fd_cant_recv(conn->t.sock.fd);
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
return 0;
}
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto recv_abort;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
}
} while (0);
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
if (!trash.len) {
/* client shutdown */
conn->err_code = CO_ER_PRX_EMPTY;
goto fail;
}
MEDIUM: make the trash be a chunk instead of a char * The trash is used everywhere to store the results of temporary strings built out of s(n)printf, or as a storage for a chunk when chunks are needed. Using global.tune.bufsize is not the most convenient thing either. So let's replace trash with a chunk and directly use it as such. We can then use trash.size as the natural way to get its size, and get rid of many intermediary chunks that were previously used. The patch is huge because it touches many areas but it makes the code a lot more clear and even outlines places where trash was used without being that obvious.
2012-10-29 11:51:55 -04:00
if (trash.len < 6)
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
goto missing;
MEDIUM: make the trash be a chunk instead of a char * The trash is used everywhere to store the results of temporary strings built out of s(n)printf, or as a storage for a chunk when chunks are needed. Using global.tune.bufsize is not the most convenient thing either. So let's replace trash with a chunk and directly use it as such. We can then use trash.size as the natural way to get its size, and get rid of many intermediary chunks that were previously used. The patch is huge because it touches many areas but it makes the code a lot more clear and even outlines places where trash was used without being that obvious.
2012-10-29 11:51:55 -04:00
line = trash.str;
end = trash.str + trash.len;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
/* Decode a possible proxy request, fail early if it does not match */
MEDIUM: connection: add support for proxy protocol v2 in accept-proxy The "accept-proxy" statement of bind lines was still limited to version 1 of the protocol, while send-proxy-v2 is now available on the server lines. This patch adds support for parsing v2 of the protocol on incoming connections. The v2 header is automatically recognized so there is no need for a new option.
2014-06-14 05:06:17 -04:00
if (strncmp(line, "PROXY ", 6) != 0)
goto not_v1;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
line += 6;
BUG/MINOR: connection: make proxy protocol v1 support the UNKNOWN protocol If haproxy receives a connection over a unix socket and forwards it to another haproxy instance using proxy protocol v1, it sends an UNKNOWN protocol, which is rejected by the other side. Make the receiver accept the UNKNOWN protocol as per the spec, and only use the local connection's address for this.
2014-06-14 05:41:36 -04:00
if (trash.len < 9) /* shortest possible line */
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
goto missing;
CLEANUP: connection: fix double negation on memcmp() Nothing harmful in here, just clarify that it applies to the whole expression.
2016-03-24 05:22:36 -04:00
if (memcmp(line, "TCP4 ", 5) == 0) {
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
u32 src3, dst3, sport, dport;
line += 5;
src3 = inetaddr_host_lim_ret(line, end, &line);
if (line == end)
goto missing;
if (*line++ != ' ')
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
dst3 = inetaddr_host_lim_ret(line, end, &line);
if (line == end)
goto missing;
if (*line++ != ' ')
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
sport = read_uint((const char **)&line, end);
if (line == end)
goto missing;
if (*line++ != ' ')
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
dport = read_uint((const char **)&line, end);
if (line > end - 2)
goto missing;
if (*line++ != '\r')
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
if (*line++ != '\n')
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
/* update the session's addresses and mark them set */
((struct sockaddr_in *)&conn->addr.from)->sin_family = AF_INET;
((struct sockaddr_in *)&conn->addr.from)->sin_addr.s_addr = htonl(src3);
((struct sockaddr_in *)&conn->addr.from)->sin_port = htons(sport);
((struct sockaddr_in *)&conn->addr.to)->sin_family = AF_INET;
((struct sockaddr_in *)&conn->addr.to)->sin_addr.s_addr = htonl(dst3);
((struct sockaddr_in *)&conn->addr.to)->sin_port = htons(dport);
conn->flags |= CO_FL_ADDR_FROM_SET | CO_FL_ADDR_TO_SET;
}
CLEANUP: connection: fix double negation on memcmp() Nothing harmful in here, just clarify that it applies to the whole expression.
2016-03-24 05:22:36 -04:00
else if (memcmp(line, "TCP6 ", 5) == 0) {
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
u32 sport, dport;
char *src_s;
char *dst_s, *sport_s, *dport_s;
struct in6_addr src3, dst3;
line += 5;
src_s = line;
dst_s = sport_s = dport_s = NULL;
while (1) {
if (line > end - 2) {
goto missing;
}
else if (*line == '\r') {
*line = 0;
line++;
if (*line++ != '\n')
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
break;
}
if (*line == ' ') {
*line = 0;
if (!dst_s)
dst_s = line + 1;
else if (!sport_s)
sport_s = line + 1;
else if (!dport_s)
dport_s = line + 1;
}
line++;
}
if (!dst_s || !sport_s || !dport_s)
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
sport = read_uint((const char **)&sport_s,dport_s - 1);
if (*sport_s != 0)
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
dport = read_uint((const char **)&dport_s,line - 2);
if (*dport_s != 0)
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
if (inet_pton(AF_INET6, src_s, (void *)&src3) != 1)
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
if (inet_pton(AF_INET6, dst_s, (void *)&dst3) != 1)
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto bad_header;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
/* update the session's addresses and mark them set */
((struct sockaddr_in6 *)&conn->addr.from)->sin6_family = AF_INET6;
memcpy(&((struct sockaddr_in6 *)&conn->addr.from)->sin6_addr, &src3, sizeof(struct in6_addr));
((struct sockaddr_in6 *)&conn->addr.from)->sin6_port = htons(sport);
((struct sockaddr_in6 *)&conn->addr.to)->sin6_family = AF_INET6;
memcpy(&((struct sockaddr_in6 *)&conn->addr.to)->sin6_addr, &dst3, sizeof(struct in6_addr));
((struct sockaddr_in6 *)&conn->addr.to)->sin6_port = htons(dport);
conn->flags |= CO_FL_ADDR_FROM_SET | CO_FL_ADDR_TO_SET;
}
BUG/MINOR: connection: make proxy protocol v1 support the UNKNOWN protocol If haproxy receives a connection over a unix socket and forwards it to another haproxy instance using proxy protocol v1, it sends an UNKNOWN protocol, which is rejected by the other side. Make the receiver accept the UNKNOWN protocol as per the spec, and only use the local connection's address for this.
2014-06-14 05:41:36 -04:00
else if (memcmp(line, "UNKNOWN\r\n", 9) == 0) {
/* This can be a UNIX socket forwarded by an haproxy upstream */
line += 9;
}
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
else {
BUG/MINOR: connection: make proxy protocol v1 support the UNKNOWN protocol If haproxy receives a connection over a unix socket and forwards it to another haproxy instance using proxy protocol v1, it sends an UNKNOWN protocol, which is rejected by the other side. Make the receiver accept the UNKNOWN protocol as per the spec, and only use the local connection's address for this.
2014-06-14 05:41:36 -04:00
/* The protocol does not match something known (TCP4/TCP6/UNKNOWN) */
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
conn->err_code = CO_ER_PRX_BAD_PROTO;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
goto fail;
}
MEDIUM: connection: add support for proxy protocol v2 in accept-proxy The "accept-proxy" statement of bind lines was still limited to version 1 of the protocol, while send-proxy-v2 is now available on the server lines. This patch adds support for parsing v2 of the protocol on incoming connections. The v2 header is automatically recognized so there is no need for a new option.
2014-06-14 05:06:17 -04:00
trash.len = line - trash.str;
goto eat_header;
not_v1:
/* try PPv2 */
if (trash.len < PP2_HEADER_LEN)
goto missing;
hdr_v2 = (struct proxy_hdr_v2 *)trash.str;
if (memcmp(hdr_v2->sig, v2sig, PP2_SIGNATURE_LEN) != 0 ||
(hdr_v2->ver_cmd & PP2_VERSION_MASK) != PP2_VERSION) {
conn->err_code = CO_ER_PRX_NOT_HDR;
goto fail;
}
if (trash.len < PP2_HEADER_LEN + ntohs(hdr_v2->len))
goto missing;
switch (hdr_v2->ver_cmd & PP2_CMD_MASK) {
case 0x01: /* PROXY command */
switch (hdr_v2->fam) {
case 0x11: /* TCPv4 */
BUG/MEDIUM: connection: sanitize PPv2 header length before parsing address information Previously, if hdr_v2->len was less than the length of the protocol specific address information we could have read after the end of the buffer and initialize the sockaddr structure with junk. Signed-off-by: KOVACS Krisztian <hidden@balabit.com> [WT: this is only tagged medium since proxy protocol is only used from trusted sources] This must be backported to 1.5.
2014-11-19 04:53:20 -05:00
if (ntohs(hdr_v2->len) < PP2_ADDR_LEN_INET)
goto bad_header;
MEDIUM: connection: add support for proxy protocol v2 in accept-proxy The "accept-proxy" statement of bind lines was still limited to version 1 of the protocol, while send-proxy-v2 is now available on the server lines. This patch adds support for parsing v2 of the protocol on incoming connections. The v2 header is automatically recognized so there is no need for a new option.
2014-06-14 05:06:17 -04:00
((struct sockaddr_in *)&conn->addr.from)->sin_family = AF_INET;
((struct sockaddr_in *)&conn->addr.from)->sin_addr.s_addr = hdr_v2->addr.ip4.src_addr;
((struct sockaddr_in *)&conn->addr.from)->sin_port = hdr_v2->addr.ip4.src_port;
((struct sockaddr_in *)&conn->addr.to)->sin_family = AF_INET;
((struct sockaddr_in *)&conn->addr.to)->sin_addr.s_addr = hdr_v2->addr.ip4.dst_addr;
((struct sockaddr_in *)&conn->addr.to)->sin_port = hdr_v2->addr.ip4.dst_port;
conn->flags |= CO_FL_ADDR_FROM_SET | CO_FL_ADDR_TO_SET;
BUG/MAJOR: connection: fix TLV offset calculation for proxy protocol v2 parsing Until now, the code assumed that it can get the offset to the first TLV header just by subtracting the length of the TLV part from the length of the complete buffer. However, if the buffer contains actual data after the header, this computation is flawed and leads to haproxy trying to parse TLV headers from the proxied data. This change fixes this by making sure that the offset to the first TLV header is calculated based from the start of the buffer -- simply by adding the size of the proxy protocol v2 header plus the address family-dependent size of the address information block.
2015-07-03 08:09:10 -04:00
tlv_offset = PP2_HEADER_LEN + PP2_ADDR_LEN_INET;
MAJOR: namespace: add Linux network namespace support This patch makes it possible to create binds and servers in separate namespaces. This can be used to proxy between multiple completely independent virtual networks (with possibly overlapping IP addresses) and a non-namespace-aware proxy implementation that supports the proxy protocol (v2). The setup is something like this: net1 on VLAN 1 (namespace 1) -\ net2 on VLAN 2 (namespace 2) -- haproxy ==== proxy (namespace 0) net3 on VLAN 3 (namespace 3) -/ The proxy is configured to make server connections through haproxy and sending the expected source/target addresses to haproxy using the proxy protocol. The network namespace setup on the haproxy node is something like this: = 8< = $ cat setup.sh ip netns add 1 ip link add link eth1 type vlan id 1 ip link set eth1.1 netns 1 ip netns exec 1 ip addr add 192.168.91.2/24 dev eth1.1 ip netns exec 1 ip link set eth1.$id up ... = 8< = = 8< = $ cat haproxy.cfg frontend clients bind 127.0.0.1:50022 namespace 1 transparent default_backend scb backend server mode tcp server server1 192.168.122.4:2222 namespace 2 send-proxy-v2 = 8< = A bind line creates the listener in the specified namespace, and connections originating from that listener also have their network namespace set to that of the listener. A server line either forces the connection to be made in a specified namespace or may use the namespace from the client-side connection if that was set. For more documentation please read the documentation included in the patch itself. Signed-off-by: KOVACS Tamas <ktamas@balabit.com> Signed-off-by: Sarkozi Laszlo <laszlo.sarkozi@balabit.com> Signed-off-by: KOVACS Krisztian <hidden@balabit.com>
2014-11-17 09:11:45 -05:00
tlv_length = ntohs(hdr_v2->len) - PP2_ADDR_LEN_INET;
MEDIUM: connection: add support for proxy protocol v2 in accept-proxy The "accept-proxy" statement of bind lines was still limited to version 1 of the protocol, while send-proxy-v2 is now available on the server lines. This patch adds support for parsing v2 of the protocol on incoming connections. The v2 header is automatically recognized so there is no need for a new option.
2014-06-14 05:06:17 -04:00
break;
case 0x21: /* TCPv6 */
BUG/MEDIUM: connection: sanitize PPv2 header length before parsing address information Previously, if hdr_v2->len was less than the length of the protocol specific address information we could have read after the end of the buffer and initialize the sockaddr structure with junk. Signed-off-by: KOVACS Krisztian <hidden@balabit.com> [WT: this is only tagged medium since proxy protocol is only used from trusted sources] This must be backported to 1.5.
2014-11-19 04:53:20 -05:00
if (ntohs(hdr_v2->len) < PP2_ADDR_LEN_INET6)
goto bad_header;
MEDIUM: connection: add support for proxy protocol v2 in accept-proxy The "accept-proxy" statement of bind lines was still limited to version 1 of the protocol, while send-proxy-v2 is now available on the server lines. This patch adds support for parsing v2 of the protocol on incoming connections. The v2 header is automatically recognized so there is no need for a new option.
2014-06-14 05:06:17 -04:00
((struct sockaddr_in6 *)&conn->addr.from)->sin6_family = AF_INET6;
memcpy(&((struct sockaddr_in6 *)&conn->addr.from)->sin6_addr, hdr_v2->addr.ip6.src_addr, 16);
((struct sockaddr_in6 *)&conn->addr.from)->sin6_port = hdr_v2->addr.ip6.src_port;
((struct sockaddr_in6 *)&conn->addr.to)->sin6_family = AF_INET6;
memcpy(&((struct sockaddr_in6 *)&conn->addr.to)->sin6_addr, hdr_v2->addr.ip6.dst_addr, 16);
((struct sockaddr_in6 *)&conn->addr.to)->sin6_port = hdr_v2->addr.ip6.dst_port;
conn->flags |= CO_FL_ADDR_FROM_SET | CO_FL_ADDR_TO_SET;
BUG/MAJOR: connection: fix TLV offset calculation for proxy protocol v2 parsing Until now, the code assumed that it can get the offset to the first TLV header just by subtracting the length of the TLV part from the length of the complete buffer. However, if the buffer contains actual data after the header, this computation is flawed and leads to haproxy trying to parse TLV headers from the proxied data. This change fixes this by making sure that the offset to the first TLV header is calculated based from the start of the buffer -- simply by adding the size of the proxy protocol v2 header plus the address family-dependent size of the address information block.
2015-07-03 08:09:10 -04:00
tlv_offset = PP2_HEADER_LEN + PP2_ADDR_LEN_INET6;
MAJOR: namespace: add Linux network namespace support This patch makes it possible to create binds and servers in separate namespaces. This can be used to proxy between multiple completely independent virtual networks (with possibly overlapping IP addresses) and a non-namespace-aware proxy implementation that supports the proxy protocol (v2). The setup is something like this: net1 on VLAN 1 (namespace 1) -\ net2 on VLAN 2 (namespace 2) -- haproxy ==== proxy (namespace 0) net3 on VLAN 3 (namespace 3) -/ The proxy is configured to make server connections through haproxy and sending the expected source/target addresses to haproxy using the proxy protocol. The network namespace setup on the haproxy node is something like this: = 8< = $ cat setup.sh ip netns add 1 ip link add link eth1 type vlan id 1 ip link set eth1.1 netns 1 ip netns exec 1 ip addr add 192.168.91.2/24 dev eth1.1 ip netns exec 1 ip link set eth1.$id up ... = 8< = = 8< = $ cat haproxy.cfg frontend clients bind 127.0.0.1:50022 namespace 1 transparent default_backend scb backend server mode tcp server server1 192.168.122.4:2222 namespace 2 send-proxy-v2 = 8< = A bind line creates the listener in the specified namespace, and connections originating from that listener also have their network namespace set to that of the listener. A server line either forces the connection to be made in a specified namespace or may use the namespace from the client-side connection if that was set. For more documentation please read the documentation included in the patch itself. Signed-off-by: KOVACS Tamas <ktamas@balabit.com> Signed-off-by: Sarkozi Laszlo <laszlo.sarkozi@balabit.com> Signed-off-by: KOVACS Krisztian <hidden@balabit.com>
2014-11-17 09:11:45 -05:00
tlv_length = ntohs(hdr_v2->len) - PP2_ADDR_LEN_INET6;
MEDIUM: connection: add support for proxy protocol v2 in accept-proxy The "accept-proxy" statement of bind lines was still limited to version 1 of the protocol, while send-proxy-v2 is now available on the server lines. This patch adds support for parsing v2 of the protocol on incoming connections. The v2 header is automatically recognized so there is no need for a new option.
2014-06-14 05:06:17 -04:00
break;
}
MAJOR: namespace: add Linux network namespace support This patch makes it possible to create binds and servers in separate namespaces. This can be used to proxy between multiple completely independent virtual networks (with possibly overlapping IP addresses) and a non-namespace-aware proxy implementation that supports the proxy protocol (v2). The setup is something like this: net1 on VLAN 1 (namespace 1) -\ net2 on VLAN 2 (namespace 2) -- haproxy ==== proxy (namespace 0) net3 on VLAN 3 (namespace 3) -/ The proxy is configured to make server connections through haproxy and sending the expected source/target addresses to haproxy using the proxy protocol. The network namespace setup on the haproxy node is something like this: = 8< = $ cat setup.sh ip netns add 1 ip link add link eth1 type vlan id 1 ip link set eth1.1 netns 1 ip netns exec 1 ip addr add 192.168.91.2/24 dev eth1.1 ip netns exec 1 ip link set eth1.$id up ... = 8< = = 8< = $ cat haproxy.cfg frontend clients bind 127.0.0.1:50022 namespace 1 transparent default_backend scb backend server mode tcp server server1 192.168.122.4:2222 namespace 2 send-proxy-v2 = 8< = A bind line creates the listener in the specified namespace, and connections originating from that listener also have their network namespace set to that of the listener. A server line either forces the connection to be made in a specified namespace or may use the namespace from the client-side connection if that was set. For more documentation please read the documentation included in the patch itself. Signed-off-by: KOVACS Tamas <ktamas@balabit.com> Signed-off-by: Sarkozi Laszlo <laszlo.sarkozi@balabit.com> Signed-off-by: KOVACS Krisztian <hidden@balabit.com>
2014-11-17 09:11:45 -05:00
/* TLV parsing */
if (tlv_length > 0) {
while (tlv_offset + TLV_HEADER_SIZE <= trash.len) {
const struct tlv *tlv_packet = (struct tlv *) &trash.str[tlv_offset];
const int tlv_len = get_tlv_length(tlv_packet);
tlv_offset += tlv_len + TLV_HEADER_SIZE;
switch (tlv_packet->type) {
#ifdef CONFIG_HAP_NS
case PP2_TYPE_NETNS: {
const struct netns_entry *ns;
ns = netns_store_lookup((char*)tlv_packet->value, tlv_len);
if (ns)
conn->proxy_netns = ns;
break;
}
#endif
default:
break;
}
}
}
MEDIUM: connection: add support for proxy protocol v2 in accept-proxy The "accept-proxy" statement of bind lines was still limited to version 1 of the protocol, while send-proxy-v2 is now available on the server lines. This patch adds support for parsing v2 of the protocol on incoming connections. The v2 header is automatically recognized so there is no need for a new option.
2014-06-14 05:06:17 -04:00
/* unsupported protocol, keep local connection address */
break;
case 0x00: /* LOCAL command */
/* keep local connection address for LOCAL */
break;
default:
goto bad_header; /* not a supported command */
}
trash.len = PP2_HEADER_LEN + ntohs(hdr_v2->len);
goto eat_header;
eat_header:
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
/* remove the PROXY line from the request. For this we re-read the
* exact line at once. If we don't get the exact same result, we
* fail.
*/
do {
MEDIUM: make the trash be a chunk instead of a char * The trash is used everywhere to store the results of temporary strings built out of s(n)printf, or as a storage for a chunk when chunks are needed. Using global.tune.bufsize is not the most convenient thing either. So let's replace trash with a chunk and directly use it as such. We can then use trash.size as the natural way to get its size, and get rid of many intermediary chunks that were previously used. The patch is huge because it touches many areas but it makes the code a lot more clear and even outlines places where trash was used without being that obvious.
2012-10-29 11:51:55 -04:00
int len2 = recv(conn->t.sock.fd, trash.str, trash.len, 0);
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
if (len2 < 0 && errno == EINTR)
continue;
MEDIUM: make the trash be a chunk instead of a char * The trash is used everywhere to store the results of temporary strings built out of s(n)printf, or as a storage for a chunk when chunks are needed. Using global.tune.bufsize is not the most convenient thing either. So let's replace trash with a chunk and directly use it as such. We can then use trash.size as the natural way to get its size, and get rid of many intermediary chunks that were previously used. The patch is huge because it touches many areas but it makes the code a lot more clear and even outlines places where trash was used without being that obvious.
2012-10-29 11:51:55 -04:00
if (len2 != trash.len)
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto recv_abort;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
} while (0);
conn->flags &= ~flag;
return 1;
missing:
/* Missing data. Since we're using MSG_PEEK, we can only poll again if
* we have not read anything. Otherwise we need to fail because we won't
* be able to poll anymore.
*/
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
conn->err_code = CO_ER_PRX_TRUNCATED;
goto fail;
bad_header:
/* This is not a valid proxy protocol header */
conn->err_code = CO_ER_PRX_BAD_HDR;
goto fail;
recv_abort:
conn->err_code = CO_ER_PRX_ABORT;
MEDIUM: connection: set the socket shutdown flags on socket errors When we get a hard error from a syscall indicating the socket is dead, it makes sense to set the CO_FL_SOCK_WR_SH and CO_FL_SOCK_RD_SH flags to indicate that the socket may not be used anymore. It will ease the error processing in health checks where the state of socket is very important. We'll also be able to avoid some setsockopt(nolinger) after an error. For now, the rest of the code is not impacted because CO_FL_ERROR is always tested prior to these flags.
2013-12-04 17:44:10 -05:00
conn->flags |= CO_FL_SOCK_RD_SH | CO_FL_SOCK_WR_SH;
MEDIUM: connection: add error reporting for the PROXY protocol header When the PROXY protocol header is expected and fails, leading to an abort of the incoming connection, we now emit a log message. If option dontlognull is set and it was just a port probe, then nothing is logged.
2012-12-03 09:41:18 -05:00
goto fail;
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
fail:
BUG/MINOR: connection: remove a few synchronous calls to polling updates There were a few synchronous calls to polling updates in some functions called from the connection handler. These ones are not needed and should be replaced by more efficient and more debugable asynchronous calls.
2012-12-10 11:03:52 -05:00
__conn_sock_stop_both(conn);
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
conn->flags |= CO_FL_ERROR;
return 0;
}
MINOR: listener: add the "accept-netscaler-cip" option to the "bind" keyword When NetScaler application switch is used as L3+ switch, informations regarding the original IP and TCP headers are lost as a new TCP connection is created between the NetScaler and the backend server. NetScaler provides a feature to insert in the TCP data the original data that can then be consumed by the backend server. Specifications and documentations from NetScaler: https://support.citrix.com/article/CTX205670 https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/ When CIP is enabled on the NetScaler, then a TCP packet is inserted just after the TCP handshake. This is composed as: - CIP magic number : 4 bytes Both sender and receiver have to agree on a magic number so that they both handle the incoming data as a NetScaler Client IP insertion packet. - Header length : 4 bytes Defines the length on the remaining data. - IP header : >= 20 bytes if IPv4, 40 bytes if IPv6 Contains the header of the last IP packet sent by the client during TCP handshake. - TCP header : >= 20 bytes Contains the header of the last TCP packet sent by the client during TCP handshake.
2016-06-04 10:11:10 -04:00
/* This handshake handler waits a NetScaler Client IP insertion header
* at the beginning of the raw data stream. The header looks like this:
*
* 4 bytes: CIP magic number
* 4 bytes: Header length
* 20+ bytes: Header of the last IP packet sent by the client during
* TCP handshake.
* 20+ bytes: Header of the last TCP packet sent by the client during
* TCP handshake.
*
* This line MUST be at the beginning of the buffer and MUST NOT be
* fragmented.
*
* The header line is small and in all cases smaller than the smallest normal
* TCP MSS. So it MUST always be delivered as one segment, which ensures we
* can safely use MSG_PEEK and avoid buffering.
*
* Once the data is fetched, the values are set in the connection's address
* fields, and data are removed from the socket's buffer. The function returns
* zero if it needs to wait for more data or if it fails, or 1 if it completed
* and removed itself.
*/
int conn_recv_netscaler_cip(struct connection *conn, int flag)
{
char *line;
uint32_t cip_magic;
uint32_t cip_len;
uint8_t ip_v;
/* we might have been called just after an asynchronous shutr */
if (conn->flags & CO_FL_SOCK_RD_SH)
goto fail;
if (!conn_ctrl_ready(conn))
goto fail;
if (!fd_recv_ready(conn->t.sock.fd))
return 0;
do {
trash.len = recv(conn->t.sock.fd, trash.str, trash.size, MSG_PEEK);
if (trash.len < 0) {
if (errno == EINTR)
continue;
if (errno == EAGAIN) {
fd_cant_recv(conn->t.sock.fd);
return 0;
}
goto recv_abort;
}
} while (0);
if (!trash.len) {
/* client shutdown */
conn->err_code = CO_ER_CIP_EMPTY;
goto fail;
}
/* Fail if buffer length is not large enough to contain
* CIP magic, CIP length */
if (trash.len < 8)
goto missing;
line = trash.str;
cip_magic = ntohl(*(uint32_t *)line);
cip_len = ntohl(*(uint32_t *)(line+4));
/* Decode a possible NetScaler Client IP request, fail early if
* it does not match */
if (cip_magic != objt_listener(conn->target)->bind_conf->ns_cip_magic)
goto bad_magic;
/* Fail if buffer length is not large enough to contain
* CIP magic, CIP length, minimal IP header */
if (trash.len < 28)
goto missing;
line += 8;
/* Get IP version from the first four bits */
ip_v = (*line & 0xf0) >> 4;
if (ip_v == 4) {
struct ip *hdr_ip4;
CLEANUP: connection: using internal struct to hold source and dest port. Originally, tcphdr's source and dest from Linux were used to get the source and port which led to a build issue on BSD oses. To avoid side problems related to network then we just use an internal struct as we need only those two fields.
2016-07-04 17:51:33 -04:00
struct my_tcphdr *hdr_tcp;
MINOR: listener: add the "accept-netscaler-cip" option to the "bind" keyword When NetScaler application switch is used as L3+ switch, informations regarding the original IP and TCP headers are lost as a new TCP connection is created between the NetScaler and the backend server. NetScaler provides a feature to insert in the TCP data the original data that can then be consumed by the backend server. Specifications and documentations from NetScaler: https://support.citrix.com/article/CTX205670 https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/ When CIP is enabled on the NetScaler, then a TCP packet is inserted just after the TCP handshake. This is composed as: - CIP magic number : 4 bytes Both sender and receiver have to agree on a magic number so that they both handle the incoming data as a NetScaler Client IP insertion packet. - Header length : 4 bytes Defines the length on the remaining data. - IP header : >= 20 bytes if IPv4, 40 bytes if IPv6 Contains the header of the last IP packet sent by the client during TCP handshake. - TCP header : >= 20 bytes Contains the header of the last TCP packet sent by the client during TCP handshake.
2016-06-04 10:11:10 -04:00
hdr_ip4 = (struct ip *)line;
if (trash.len < (8 + ntohs(hdr_ip4->ip_len))) {
/* Fail if buffer length is not large enough to contain
* CIP magic, CIP length, IPv4 header */
goto missing;
} else if (hdr_ip4->ip_p != IPPROTO_TCP) {
/* The protocol does not include a TCP header */
conn->err_code = CO_ER_CIP_BAD_PROTO;
goto fail;
} else if (trash.len < (28 + ntohs(hdr_ip4->ip_len))) {
/* Fail if buffer length is not large enough to contain
* CIP magic, CIP length, IPv4 header, TCP header */
goto missing;
}
CLEANUP: connection: using internal struct to hold source and dest port. Originally, tcphdr's source and dest from Linux were used to get the source and port which led to a build issue on BSD oses. To avoid side problems related to network then we just use an internal struct as we need only those two fields.
2016-07-04 17:51:33 -04:00
hdr_tcp = (struct my_tcphdr *)(line + (hdr_ip4->ip_hl * 4));
MINOR: listener: add the "accept-netscaler-cip" option to the "bind" keyword When NetScaler application switch is used as L3+ switch, informations regarding the original IP and TCP headers are lost as a new TCP connection is created between the NetScaler and the backend server. NetScaler provides a feature to insert in the TCP data the original data that can then be consumed by the backend server. Specifications and documentations from NetScaler: https://support.citrix.com/article/CTX205670 https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/ When CIP is enabled on the NetScaler, then a TCP packet is inserted just after the TCP handshake. This is composed as: - CIP magic number : 4 bytes Both sender and receiver have to agree on a magic number so that they both handle the incoming data as a NetScaler Client IP insertion packet. - Header length : 4 bytes Defines the length on the remaining data. - IP header : >= 20 bytes if IPv4, 40 bytes if IPv6 Contains the header of the last IP packet sent by the client during TCP handshake. - TCP header : >= 20 bytes Contains the header of the last TCP packet sent by the client during TCP handshake.
2016-06-04 10:11:10 -04:00
/* update the session's addresses and mark them set */
((struct sockaddr_in *)&conn->addr.from)->sin_family = AF_INET;
((struct sockaddr_in *)&conn->addr.from)->sin_addr.s_addr = hdr_ip4->ip_src.s_addr;
((struct sockaddr_in *)&conn->addr.from)->sin_port = hdr_tcp->source;
((struct sockaddr_in *)&conn->addr.to)->sin_family = AF_INET;
((struct sockaddr_in *)&conn->addr.to)->sin_addr.s_addr = hdr_ip4->ip_dst.s_addr;
((struct sockaddr_in *)&conn->addr.to)->sin_port = hdr_tcp->dest;
conn->flags |= CO_FL_ADDR_FROM_SET | CO_FL_ADDR_TO_SET;
}
else if (ip_v == 6) {
struct ip6_hdr *hdr_ip6;
CLEANUP: connection: using internal struct to hold source and dest port. Originally, tcphdr's source and dest from Linux were used to get the source and port which led to a build issue on BSD oses. To avoid side problems related to network then we just use an internal struct as we need only those two fields.
2016-07-04 17:51:33 -04:00
struct my_tcphdr *hdr_tcp;
MINOR: listener: add the "accept-netscaler-cip" option to the "bind" keyword When NetScaler application switch is used as L3+ switch, informations regarding the original IP and TCP headers are lost as a new TCP connection is created between the NetScaler and the backend server. NetScaler provides a feature to insert in the TCP data the original data that can then be consumed by the backend server. Specifications and documentations from NetScaler: https://support.citrix.com/article/CTX205670 https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/ When CIP is enabled on the NetScaler, then a TCP packet is inserted just after the TCP handshake. This is composed as: - CIP magic number : 4 bytes Both sender and receiver have to agree on a magic number so that they both handle the incoming data as a NetScaler Client IP insertion packet. - Header length : 4 bytes Defines the length on the remaining data. - IP header : >= 20 bytes if IPv4, 40 bytes if IPv6 Contains the header of the last IP packet sent by the client during TCP handshake. - TCP header : >= 20 bytes Contains the header of the last TCP packet sent by the client during TCP handshake.
2016-06-04 10:11:10 -04:00
hdr_ip6 = (struct ip6_hdr *)line;
if (trash.len < 28) {
/* Fail if buffer length is not large enough to contain
* CIP magic, CIP length, IPv6 header */
goto missing;
} else if (hdr_ip6->ip6_nxt != IPPROTO_TCP) {
/* The protocol does not include a TCP header */
conn->err_code = CO_ER_CIP_BAD_PROTO;
goto fail;
} else if (trash.len < 48) {
/* Fail if buffer length is not large enough to contain
* CIP magic, CIP length, IPv6 header, TCP header */
goto missing;
}
CLEANUP: connection: using internal struct to hold source and dest port. Originally, tcphdr's source and dest from Linux were used to get the source and port which led to a build issue on BSD oses. To avoid side problems related to network then we just use an internal struct as we need only those two fields.
2016-07-04 17:51:33 -04:00
hdr_tcp = (struct my_tcphdr *)(line + sizeof(struct ip6_hdr));
MINOR: listener: add the "accept-netscaler-cip" option to the "bind" keyword When NetScaler application switch is used as L3+ switch, informations regarding the original IP and TCP headers are lost as a new TCP connection is created between the NetScaler and the backend server. NetScaler provides a feature to insert in the TCP data the original data that can then be consumed by the backend server. Specifications and documentations from NetScaler: https://support.citrix.com/article/CTX205670 https://www.citrix.com/blogs/2016/04/25/how-to-enable-client-ip-in-tcpip-option-of-netscaler/ When CIP is enabled on the NetScaler, then a TCP packet is inserted just after the TCP handshake. This is composed as: - CIP magic number : 4 bytes Both sender and receiver have to agree on a magic number so that they both handle the incoming data as a NetScaler Client IP insertion packet. - Header length : 4 bytes Defines the length on the remaining data. - IP header : >= 20 bytes if IPv4, 40 bytes if IPv6 Contains the header of the last IP packet sent by the client during TCP handshake. - TCP header : >= 20 bytes Contains the header of the last TCP packet sent by the client during TCP handshake.
2016-06-04 10:11:10 -04:00
/* update the session's addresses and mark them set */
((struct sockaddr_in6 *)&conn->addr.from)->sin6_family = AF_INET6;
((struct sockaddr_in6 *)&conn->addr.from)->sin6_addr = hdr_ip6->ip6_src;
((struct sockaddr_in6 *)&conn->addr.from)->sin6_port = hdr_tcp->source;
((struct sockaddr_in6 *)&conn->addr.to)->sin6_family = AF_INET6;
((struct sockaddr_in6 *)&conn->addr.to)->sin6_addr = hdr_ip6->ip6_dst;
((struct sockaddr_in6 *)&conn->addr.to)->sin6_port = hdr_tcp->dest;
conn->flags |= CO_FL_ADDR_FROM_SET | CO_FL_ADDR_TO_SET;
}
else {
/* The protocol does not match something known (IPv4/IPv6) */
conn->err_code = CO_ER_CIP_BAD_PROTO;
goto fail;
}
line += cip_len;
trash.len = line - trash.str;
/* remove the NetScaler Client IP header from the request. For this
* we re-read the exact line at once. If we don't get the exact same
* result, we fail.
*/
do {
int len2 = recv(conn->t.sock.fd, trash.str, trash.len, 0);
if (len2 < 0 && errno == EINTR)
continue;
if (len2 != trash.len)
goto recv_abort;
} while (0);
conn->flags &= ~flag;
return 1;
missing:
/* Missing data. Since we're using MSG_PEEK, we can only poll again if
* we have not read anything. Otherwise we need to fail because we won't
* be able to poll anymore.
*/
conn->err_code = CO_ER_CIP_TRUNCATED;
goto fail;
bad_magic:
conn->err_code = CO_ER_CIP_BAD_MAGIC;
goto fail;
recv_abort:
conn->err_code = CO_ER_CIP_ABORT;
conn->flags |= CO_FL_SOCK_RD_SH | CO_FL_SOCK_WR_SH;
goto fail;
fail:
__conn_sock_stop_both(conn);
conn->flags |= CO_FL_ERROR;
return 0;
}
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
int make_proxy_line(char *buf, int buf_len, struct server *srv, struct connection *remote)
{
int ret = 0;
if (srv && (srv->pp_opts & SRV_PP_V2)) {
ret = make_proxy_line_v2(buf, buf_len, srv, remote);
}
else {
if (remote)
ret = make_proxy_line_v1(buf, buf_len, &remote->addr.from, &remote->addr.to);
else
ret = make_proxy_line_v1(buf, buf_len, NULL, NULL);
}
return ret;
}
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
/* Makes a PROXY protocol line from the two addresses. The output is sent to
* buffer <buf> for a maximum size of <buf_len> (including the trailing zero).
* It returns the number of bytes composing this line (including the trailing
* LF), or zero in case of failure (eg: not enough space). It supports TCP4,
MINOR: connection: make it easier to emit proxy protocol for unknown addresses Currently a connection is required on the remote side to emit a proxy protocol header line. Let's support NULL addresses to emit an UNKNOWN tag as well.
2013-10-01 05:41:55 -04:00
* TCP6 and "UNKNOWN" formats. If any of <src> or <dst> is null, UNKNOWN is
* emitted as well.
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
*/
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
int make_proxy_line_v1(char *buf, int buf_len, struct sockaddr_storage *src, struct sockaddr_storage *dst)
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
{
int ret = 0;
MINOR: connection: make it easier to emit proxy protocol for unknown addresses Currently a connection is required on the remote side to emit a proxy protocol header line. Let's support NULL addresses to emit an UNKNOWN tag as well.
2013-10-01 05:41:55 -04:00
if (src && dst && src->ss_family == dst->ss_family && src->ss_family == AF_INET) {
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
ret = snprintf(buf + ret, buf_len - ret, "PROXY TCP4 ");
if (ret >= buf_len)
return 0;
/* IPv4 src */
if (!inet_ntop(src->ss_family, &((struct sockaddr_in *)src)->sin_addr, buf + ret, buf_len - ret))
return 0;
ret += strlen(buf + ret);
if (ret >= buf_len)
return 0;
buf[ret++] = ' ';
/* IPv4 dst */
if (!inet_ntop(dst->ss_family, &((struct sockaddr_in *)dst)->sin_addr, buf + ret, buf_len - ret))
return 0;
ret += strlen(buf + ret);
if (ret >= buf_len)
return 0;
/* source and destination ports */
ret += snprintf(buf + ret, buf_len - ret, " %u %u\r\n",
ntohs(((struct sockaddr_in *)src)->sin_port),
ntohs(((struct sockaddr_in *)dst)->sin_port));
if (ret >= buf_len)
return 0;
}
MINOR: connection: make it easier to emit proxy protocol for unknown addresses Currently a connection is required on the remote side to emit a proxy protocol header line. Let's support NULL addresses to emit an UNKNOWN tag as well.
2013-10-01 05:41:55 -04:00
else if (src && dst && src->ss_family == dst->ss_family && src->ss_family == AF_INET6) {
REORG: connection: move the PROXY protocol management to connection.c It was previously in frontend.c but there is no reason for this anymore considering that all the information involved is in the connection itself only. Theorically this should be in the socket layer but we don't have this yet.
2012-10-04 18:10:55 -04:00
ret = snprintf(buf + ret, buf_len - ret, "PROXY TCP6 ");
if (ret >= buf_len)
return 0;
/* IPv6 src */
if (!inet_ntop(src->ss_family, &((struct sockaddr_in6 *)src)->sin6_addr, buf + ret, buf_len - ret))
return 0;
ret += strlen(buf + ret);
if (ret >= buf_len)
return 0;
buf[ret++] = ' ';
/* IPv6 dst */
if (!inet_ntop(dst->ss_family, &((struct sockaddr_in6 *)dst)->sin6_addr, buf + ret, buf_len - ret))
return 0;
ret += strlen(buf + ret);
if (ret >= buf_len)
return 0;
/* source and destination ports */
ret += snprintf(buf + ret, buf_len - ret, " %u %u\r\n",
ntohs(((struct sockaddr_in6 *)src)->sin6_port),
ntohs(((struct sockaddr_in6 *)dst)->sin6_port));
if (ret >= buf_len)
return 0;
}
else {
/* unknown family combination */
ret = snprintf(buf, buf_len, "PROXY UNKNOWN\r\n");
if (ret >= buf_len)
return 0;
}
return ret;
}
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
MAJOR: namespace: add Linux network namespace support This patch makes it possible to create binds and servers in separate namespaces. This can be used to proxy between multiple completely independent virtual networks (with possibly overlapping IP addresses) and a non-namespace-aware proxy implementation that supports the proxy protocol (v2). The setup is something like this: net1 on VLAN 1 (namespace 1) -\ net2 on VLAN 2 (namespace 2) -- haproxy ==== proxy (namespace 0) net3 on VLAN 3 (namespace 3) -/ The proxy is configured to make server connections through haproxy and sending the expected source/target addresses to haproxy using the proxy protocol. The network namespace setup on the haproxy node is something like this: = 8< = $ cat setup.sh ip netns add 1 ip link add link eth1 type vlan id 1 ip link set eth1.1 netns 1 ip netns exec 1 ip addr add 192.168.91.2/24 dev eth1.1 ip netns exec 1 ip link set eth1.$id up ... = 8< = = 8< = $ cat haproxy.cfg frontend clients bind 127.0.0.1:50022 namespace 1 transparent default_backend scb backend server mode tcp server server1 192.168.122.4:2222 namespace 2 send-proxy-v2 = 8< = A bind line creates the listener in the specified namespace, and connections originating from that listener also have their network namespace set to that of the listener. A server line either forces the connection to be made in a specified namespace or may use the namespace from the client-side connection if that was set. For more documentation please read the documentation included in the patch itself. Signed-off-by: KOVACS Tamas <ktamas@balabit.com> Signed-off-by: Sarkozi Laszlo <laszlo.sarkozi@balabit.com> Signed-off-by: KOVACS Krisztian <hidden@balabit.com>
2014-11-17 09:11:45 -05:00
#if defined(USE_OPENSSL) || defined(CONFIG_HAP_NS)
static int make_tlv(char *dest, int dest_len, char type, uint16_t length, const char *value)
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
{
struct tlv *tlv;
if (!dest || (length + sizeof(*tlv) > dest_len))
return 0;
tlv = (struct tlv *)dest;
tlv->type = type;
tlv->length_hi = length >> 8;
tlv->length_lo = length & 0x00ff;
memcpy(tlv->value, value, length);
return length + sizeof(*tlv);
}
#endif
int make_proxy_line_v2(char *buf, int buf_len, struct server *srv, struct connection *remote)
{
CLEANUP: connection: merge proxy proto v2 header and address block This is in order to simplify the PPv2 header parsing code to look more like the one provided as an example in the spec. No code change was performed beyond just merging the proxy_addr union into the proxy_hdr_v2 struct.
2014-06-14 02:28:06 -04:00
const char pp2_signature[] = PP2_SIGNATURE;
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
int ret = 0;
CLEANUP: connection: merge proxy proto v2 header and address block This is in order to simplify the PPv2 header parsing code to look more like the one provided as an example in the spec. No code change was performed beyond just merging the proxy_addr union into the proxy_hdr_v2 struct.
2014-06-14 02:28:06 -04:00
struct proxy_hdr_v2 *hdr = (struct proxy_hdr_v2 *)buf;
BUG/MAJOR: fix listening IP address storage for frontends When compiled with GCC 6, the IP address specified for a frontend was ignored and HAProxy was listening on all addresses instead. This is caused by an incomplete copy of a "struct sockaddr_storage". With the GNU Libc, "struct sockaddr_storage" is defined as this: struct sockaddr_storage { sa_family_t ss_family; unsigned long int __ss_align; char __ss_padding[(128 - (2 * sizeof (unsigned long int)))]; }; Doing an aggregate copy (ss1 = ss2) is different than using memcpy(): only members of the aggregate have to be copied. Notably, padding can be or not be copied. In GCC 6, some optimizations use this fact and if a "struct sockaddr_storage" contains a "struct sockaddr_in", the port and the address are part of the padding (between sa_family and __ss_align) and can be not copied over. Therefore, we replace any aggregate copy by a memcpy(). There is another place using the same pattern. We also fix a function receiving a "struct sockaddr_storage" by copy instead of by reference. Since it only needs a read-only copy, the function is converted to request a reference.
2016-05-18 10:17:44 -04:00
struct sockaddr_storage null_addr = { .ss_family = 0 };
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
struct sockaddr_storage *src = &null_addr;
struct sockaddr_storage *dst = &null_addr;
MAJOR: namespace: add Linux network namespace support This patch makes it possible to create binds and servers in separate namespaces. This can be used to proxy between multiple completely independent virtual networks (with possibly overlapping IP addresses) and a non-namespace-aware proxy implementation that supports the proxy protocol (v2). The setup is something like this: net1 on VLAN 1 (namespace 1) -\ net2 on VLAN 2 (namespace 2) -- haproxy ==== proxy (namespace 0) net3 on VLAN 3 (namespace 3) -/ The proxy is configured to make server connections through haproxy and sending the expected source/target addresses to haproxy using the proxy protocol. The network namespace setup on the haproxy node is something like this: = 8< = $ cat setup.sh ip netns add 1 ip link add link eth1 type vlan id 1 ip link set eth1.1 netns 1 ip netns exec 1 ip addr add 192.168.91.2/24 dev eth1.1 ip netns exec 1 ip link set eth1.$id up ... = 8< = = 8< = $ cat haproxy.cfg frontend clients bind 127.0.0.1:50022 namespace 1 transparent default_backend scb backend server mode tcp server server1 192.168.122.4:2222 namespace 2 send-proxy-v2 = 8< = A bind line creates the listener in the specified namespace, and connections originating from that listener also have their network namespace set to that of the listener. A server line either forces the connection to be made in a specified namespace or may use the namespace from the client-side connection if that was set. For more documentation please read the documentation included in the patch itself. Signed-off-by: KOVACS Tamas <ktamas@balabit.com> Signed-off-by: Sarkozi Laszlo <laszlo.sarkozi@balabit.com> Signed-off-by: KOVACS Krisztian <hidden@balabit.com>
2014-11-17 09:11:45 -05:00
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
#ifdef USE_OPENSSL
char *value = NULL;
struct tlv_ssl *tlv;
int ssl_tlv_len = 0;
BUG/MEDIUM: connection: fix memory corruption when building a proxy v2 header Use temporary trash chunk, instead of global trash chunk in make_proxy_line_v2() to avoid memory overwrite. This fix must also be backported to 1.5.
2014-07-17 14:34:01 -04:00
struct chunk *cn_trash;
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
#endif
if (buf_len < PP2_HEADER_LEN)
return 0;
CLEANUP: connection: merge proxy proto v2 header and address block This is in order to simplify the PPv2 header parsing code to look more like the one provided as an example in the spec. No code change was performed beyond just merging the proxy_addr union into the proxy_hdr_v2 struct.
2014-06-14 02:28:06 -04:00
memcpy(hdr->sig, pp2_signature, PP2_SIGNATURE_LEN);
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
if (remote) {
src = &remote->addr.from;
dst = &remote->addr.to;
}
MAJOR: namespace: add Linux network namespace support This patch makes it possible to create binds and servers in separate namespaces. This can be used to proxy between multiple completely independent virtual networks (with possibly overlapping IP addresses) and a non-namespace-aware proxy implementation that supports the proxy protocol (v2). The setup is something like this: net1 on VLAN 1 (namespace 1) -\ net2 on VLAN 2 (namespace 2) -- haproxy ==== proxy (namespace 0) net3 on VLAN 3 (namespace 3) -/ The proxy is configured to make server connections through haproxy and sending the expected source/target addresses to haproxy using the proxy protocol. The network namespace setup on the haproxy node is something like this: = 8< = $ cat setup.sh ip netns add 1 ip link add link eth1 type vlan id 1 ip link set eth1.1 netns 1 ip netns exec 1 ip addr add 192.168.91.2/24 dev eth1.1 ip netns exec 1 ip link set eth1.$id up ... = 8< = = 8< = $ cat haproxy.cfg frontend clients bind 127.0.0.1:50022 namespace 1 transparent default_backend scb backend server mode tcp server server1 192.168.122.4:2222 namespace 2 send-proxy-v2 = 8< = A bind line creates the listener in the specified namespace, and connections originating from that listener also have their network namespace set to that of the listener. A server line either forces the connection to be made in a specified namespace or may use the namespace from the client-side connection if that was set. For more documentation please read the documentation included in the patch itself. Signed-off-by: KOVACS Tamas <ktamas@balabit.com> Signed-off-by: Sarkozi Laszlo <laszlo.sarkozi@balabit.com> Signed-off-by: KOVACS Krisztian <hidden@balabit.com>
2014-11-17 09:11:45 -05:00
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
if (src && dst && src->ss_family == dst->ss_family && src->ss_family == AF_INET) {
if (buf_len < PP2_HDR_LEN_INET)
return 0;
CLEANUP: connection: merge proxy proto v2 header and address block This is in order to simplify the PPv2 header parsing code to look more like the one provided as an example in the spec. No code change was performed beyond just merging the proxy_addr union into the proxy_hdr_v2 struct.
2014-06-14 02:28:06 -04:00
hdr->ver_cmd = PP2_VERSION | PP2_CMD_PROXY;
hdr->fam = PP2_FAM_INET | PP2_TRANS_STREAM;
hdr->addr.ip4.src_addr = ((struct sockaddr_in *)src)->sin_addr.s_addr;
hdr->addr.ip4.dst_addr = ((struct sockaddr_in *)dst)->sin_addr.s_addr;
hdr->addr.ip4.src_port = ((struct sockaddr_in *)src)->sin_port;
hdr->addr.ip4.dst_port = ((struct sockaddr_in *)dst)->sin_port;
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
ret = PP2_HDR_LEN_INET;
}
else if (src && dst && src->ss_family == dst->ss_family && src->ss_family == AF_INET6) {
if (buf_len < PP2_HDR_LEN_INET6)
return 0;
CLEANUP: connection: merge proxy proto v2 header and address block This is in order to simplify the PPv2 header parsing code to look more like the one provided as an example in the spec. No code change was performed beyond just merging the proxy_addr union into the proxy_hdr_v2 struct.
2014-06-14 02:28:06 -04:00
hdr->ver_cmd = PP2_VERSION | PP2_CMD_PROXY;
hdr->fam = PP2_FAM_INET6 | PP2_TRANS_STREAM;
memcpy(hdr->addr.ip6.src_addr, &((struct sockaddr_in6 *)src)->sin6_addr, 16);
memcpy(hdr->addr.ip6.dst_addr, &((struct sockaddr_in6 *)dst)->sin6_addr, 16);
hdr->addr.ip6.src_port = ((struct sockaddr_in6 *)src)->sin6_port;
hdr->addr.ip6.dst_port = ((struct sockaddr_in6 *)dst)->sin6_port;
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
ret = PP2_HDR_LEN_INET6;
}
else {
if (buf_len < PP2_HDR_LEN_UNSPEC)
return 0;
CLEANUP: connection: merge proxy proto v2 header and address block This is in order to simplify the PPv2 header parsing code to look more like the one provided as an example in the spec. No code change was performed beyond just merging the proxy_addr union into the proxy_hdr_v2 struct.
2014-06-14 02:28:06 -04:00
hdr->ver_cmd = PP2_VERSION | PP2_CMD_LOCAL;
hdr->fam = PP2_FAM_UNSPEC | PP2_TRANS_UNSPEC;
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
ret = PP2_HDR_LEN_UNSPEC;
}
#ifdef USE_OPENSSL
if (srv->pp_opts & SRV_PP_V2_SSL) {
if ((buf_len - ret) < sizeof(struct tlv_ssl))
return 0;
tlv = (struct tlv_ssl *)&buf[ret];
memset(tlv, 0, sizeof(struct tlv_ssl));
ssl_tlv_len += sizeof(struct tlv_ssl);
tlv->tlv.type = PP2_TYPE_SSL;
if (ssl_sock_is_ssl(remote)) {
tlv->client |= PP2_CLIENT_SSL;
value = ssl_sock_get_version(remote);
if (value) {
MAJOR: namespace: add Linux network namespace support This patch makes it possible to create binds and servers in separate namespaces. This can be used to proxy between multiple completely independent virtual networks (with possibly overlapping IP addresses) and a non-namespace-aware proxy implementation that supports the proxy protocol (v2). The setup is something like this: net1 on VLAN 1 (namespace 1) -\ net2 on VLAN 2 (namespace 2) -- haproxy ==== proxy (namespace 0) net3 on VLAN 3 (namespace 3) -/ The proxy is configured to make server connections through haproxy and sending the expected source/target addresses to haproxy using the proxy protocol. The network namespace setup on the haproxy node is something like this: = 8< = $ cat setup.sh ip netns add 1 ip link add link eth1 type vlan id 1 ip link set eth1.1 netns 1 ip netns exec 1 ip addr add 192.168.91.2/24 dev eth1.1 ip netns exec 1 ip link set eth1.$id up ... = 8< = = 8< = $ cat haproxy.cfg frontend clients bind 127.0.0.1:50022 namespace 1 transparent default_backend scb backend server mode tcp server server1 192.168.122.4:2222 namespace 2 send-proxy-v2 = 8< = A bind line creates the listener in the specified namespace, and connections originating from that listener also have their network namespace set to that of the listener. A server line either forces the connection to be made in a specified namespace or may use the namespace from the client-side connection if that was set. For more documentation please read the documentation included in the patch itself. Signed-off-by: KOVACS Tamas <ktamas@balabit.com> Signed-off-by: Sarkozi Laszlo <laszlo.sarkozi@balabit.com> Signed-off-by: KOVACS Krisztian <hidden@balabit.com>
2014-11-17 09:11:45 -05:00
ssl_tlv_len += make_tlv(&buf[ret+ssl_tlv_len], (buf_len-ret-ssl_tlv_len), PP2_TYPE_SSL_VERSION, strlen(value), value);
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
}
MEDIUM: connection: add new bit in Proxy Protocol V2 There are two sample commands to get information about the presence of a client certificate. ssl_fc_has_crt is true if there is a certificate present in the current connection ssl_c_used is true if there is a certificate present in the session. If a session has stopped and resumed, then ssl_c_used could be true, while ssl_fc_has_crt is false. In the client byte of the TLS TLV of Proxy Protocol V2, there is only one bit to indicate whether a certificate is present on the connection. The attached patch adds a second bit to indicate the presence for the session. This maintains backward compatibility. [wt: this should be backported to 1.5 to help maintain compatibility between versions]
2014-07-30 10:39:13 -04:00
if (ssl_sock_get_cert_used_sess(remote)) {
tlv->client |= PP2_CLIENT_CERT_SESS;
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
tlv->verify = htonl(ssl_sock_get_verify_result(remote));
MEDIUM: connection: add new bit in Proxy Protocol V2 There are two sample commands to get information about the presence of a client certificate. ssl_fc_has_crt is true if there is a certificate present in the current connection ssl_c_used is true if there is a certificate present in the session. If a session has stopped and resumed, then ssl_c_used could be true, while ssl_fc_has_crt is false. In the client byte of the TLS TLV of Proxy Protocol V2, there is only one bit to indicate whether a certificate is present on the connection. The attached patch adds a second bit to indicate the presence for the session. This maintains backward compatibility. [wt: this should be backported to 1.5 to help maintain compatibility between versions]
2014-07-30 10:39:13 -04:00
if (ssl_sock_get_cert_used_conn(remote))
tlv->client |= PP2_CLIENT_CERT_CONN;
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
}
if (srv->pp_opts & SRV_PP_V2_SSL_CN) {
BUG/MEDIUM: connection: fix memory corruption when building a proxy v2 header Use temporary trash chunk, instead of global trash chunk in make_proxy_line_v2() to avoid memory overwrite. This fix must also be backported to 1.5.
2014-07-17 14:34:01 -04:00
cn_trash = get_trash_chunk();
BUG/MEDIUM: connection: fix proxy v2 header again! Last commit 77d1f01 ("BUG/MEDIUM: connection: fix memory corruption when building a proxy v2 header") was wrong, using &cn_trash instead of cn_trash resulting in a warning and the client's SSL cert CN not being stored at the proper location. Thanks to Lukas Tribus for spotting this quickly. This should be backported to 1.5 after the patch above is backported.
2014-07-19 00:37:33 -04:00
if (ssl_sock_get_remote_common_name(remote, cn_trash) > 0) {
MAJOR: namespace: add Linux network namespace support This patch makes it possible to create binds and servers in separate namespaces. This can be used to proxy between multiple completely independent virtual networks (with possibly overlapping IP addresses) and a non-namespace-aware proxy implementation that supports the proxy protocol (v2). The setup is something like this: net1 on VLAN 1 (namespace 1) -\ net2 on VLAN 2 (namespace 2) -- haproxy ==== proxy (namespace 0) net3 on VLAN 3 (namespace 3) -/ The proxy is configured to make server connections through haproxy and sending the expected source/target addresses to haproxy using the proxy protocol. The network namespace setup on the haproxy node is something like this: = 8< = $ cat setup.sh ip netns add 1 ip link add link eth1 type vlan id 1 ip link set eth1.1 netns 1 ip netns exec 1 ip addr add 192.168.91.2/24 dev eth1.1 ip netns exec 1 ip link set eth1.$id up ... = 8< = = 8< = $ cat haproxy.cfg frontend clients bind 127.0.0.1:50022 namespace 1 transparent default_backend scb backend server mode tcp server server1 192.168.122.4:2222 namespace 2 send-proxy-v2 = 8< = A bind line creates the listener in the specified namespace, and connections originating from that listener also have their network namespace set to that of the listener. A server line either forces the connection to be made in a specified namespace or may use the namespace from the client-side connection if that was set. For more documentation please read the documentation included in the patch itself. Signed-off-by: KOVACS Tamas <ktamas@balabit.com> Signed-off-by: Sarkozi Laszlo <laszlo.sarkozi@balabit.com> Signed-off-by: KOVACS Krisztian <hidden@balabit.com>
2014-11-17 09:11:45 -05:00
ssl_tlv_len += make_tlv(&buf[ret+ssl_tlv_len], (buf_len - ret - ssl_tlv_len), PP2_TYPE_SSL_CN, cn_trash->len, cn_trash->str);
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
}
}
}
tlv->tlv.length_hi = (uint16_t)(ssl_tlv_len - sizeof(struct tlv)) >> 8;
tlv->tlv.length_lo = (uint16_t)(ssl_tlv_len - sizeof(struct tlv)) & 0x00ff;
ret += ssl_tlv_len;
}
#endif
MAJOR: namespace: add Linux network namespace support This patch makes it possible to create binds and servers in separate namespaces. This can be used to proxy between multiple completely independent virtual networks (with possibly overlapping IP addresses) and a non-namespace-aware proxy implementation that supports the proxy protocol (v2). The setup is something like this: net1 on VLAN 1 (namespace 1) -\ net2 on VLAN 2 (namespace 2) -- haproxy ==== proxy (namespace 0) net3 on VLAN 3 (namespace 3) -/ The proxy is configured to make server connections through haproxy and sending the expected source/target addresses to haproxy using the proxy protocol. The network namespace setup on the haproxy node is something like this: = 8< = $ cat setup.sh ip netns add 1 ip link add link eth1 type vlan id 1 ip link set eth1.1 netns 1 ip netns exec 1 ip addr add 192.168.91.2/24 dev eth1.1 ip netns exec 1 ip link set eth1.$id up ... = 8< = = 8< = $ cat haproxy.cfg frontend clients bind 127.0.0.1:50022 namespace 1 transparent default_backend scb backend server mode tcp server server1 192.168.122.4:2222 namespace 2 send-proxy-v2 = 8< = A bind line creates the listener in the specified namespace, and connections originating from that listener also have their network namespace set to that of the listener. A server line either forces the connection to be made in a specified namespace or may use the namespace from the client-side connection if that was set. For more documentation please read the documentation included in the patch itself. Signed-off-by: KOVACS Tamas <ktamas@balabit.com> Signed-off-by: Sarkozi Laszlo <laszlo.sarkozi@balabit.com> Signed-off-by: KOVACS Krisztian <hidden@balabit.com>
2014-11-17 09:11:45 -05:00
#ifdef CONFIG_HAP_NS
if (remote && (remote->proxy_netns)) {
if ((buf_len - ret) < sizeof(struct tlv))
return 0;
ret += make_tlv(&buf[ret], buf_len, PP2_TYPE_NETNS, remote->proxy_netns->name_len, remote->proxy_netns->node.key);
}
#endif
CLEANUP: connection: merge proxy proto v2 header and address block This is in order to simplify the PPv2 header parsing code to look more like the one provided as an example in the spec. No code change was performed beyond just merging the proxy_addr union into the proxy_hdr_v2 struct.
2014-06-14 02:28:06 -04:00
hdr->len = htons((uint16_t)(ret - PP2_HEADER_LEN));
MEDIUM: connection: Implement and extented PROXY Protocol V2 This commit modifies the PROXY protocol V2 specification to support headers longer than 255 bytes allowing for optional extensions. It implements the PROXY protocol V2 which is a binary representation of V1. This will make parsing more efficient for clients who will know in advance exactly how many bytes to read. Also, it defines and implements some optional PROXY protocol V2 extensions to send information about downstream SSL/TLS connections. Support for PROXY protocol V1 remains unchanged.
2014-05-08 23:42:08 -04:00
return ret;
}
Reference in a new issue Copy permalink