parsing reload cmd output from master cli

[Joao Morais]

Hello William, here[1] is some context. I implemented a parsing of the reload 
command sent to the master cli, leave it running for a while and got an index 
out of bounds (in my code) this week.

I'm using this lay out to parse the reload output:

//   1   3   4   6  
 8   8
//   
0...|...6...|...2...|...8...|...4...|...0...|...8
//
//   #
 
//   1   master  0   2   
0d00h01m28s 2.2.3-0e58a34
//   # workers
//   3   worker  1   0   
0d00h00m00s 2.2.3-0e58a34
//   # old workers
//   2   worker  [was: 1]1   
0d00h00m28s 2.2.3-0e58a34
//   # programs
//

Apparently I found a line that: starting char isn't '#', have 32 chars or more, 
have less than 48 chars. Is that even possible?

How would you expand the lay out above, so I can improve my parser and my 
tests? Thanks!

~jm

[1] https://www.mail-archive.com/haproxy@formilux.org/msg38415.html

[PATCH v3 5/5] MEDIUM: check: align agentaddr and agentport behaviour

[William Dauchy]

in the same manner of agentaddr, we now:
- permit to set agentport through `port` keyword, like it is the case
  for agentaddr through `addr`
- set the priority on `agent-port` keyword when used
- add a flag to be able to test when the value is set like for agentaddr

it makes the behaviour between `addr` and `port` more consistent.

Signed-off-by: William Dauchy 
---
 doc/configuration.txt  | 10 +-
 include/haproxy/check.h|  1 +
 include/haproxy/server-t.h |  1 +
 src/check.c| 12 +++-
 4 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 2abd684fa..eb685785d 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -14061,11 +14061,11 @@ pool-purge-delay 
 
 port 
   Using the "port" parameter, it becomes possible to use a different port to
-  send health-checks. On some servers, it may be desirable to dedicate a port
-  to a specific component able to perform complex tests which are more suitable
-  to health-checks than the application. It is common to run a simple script in
-  inetd for instance. This parameter is ignored if the "check" parameter is not
-  set. See also the "addr" parameter.
+  send health-checks or to probe the agent-check. On some servers, it may be
+  desirable to dedicate a port to a specific component able to perform complex
+  tests which are more suitable to health-checks than the application. It is
+  common to run a simple script in inetd for instance. This parameter is
+  ignored if the "check" parameter is not set. See also the "addr" parameter.
 
 proto 
   Forces the multiplexer's protocol to use for the outgoing connections to this
diff --git a/include/haproxy/check.h b/include/haproxy/check.h
index ed8124470..ffeef4e22 100644
--- a/include/haproxy/check.h
+++ b/include/haproxy/check.h
@@ -53,6 +53,7 @@ int spoe_handle_healthcheck_response(char *frame, size_t 
size, char *err, int er
 
 int set_srv_agent_send(struct server *srv, const char *send);
 void set_srv_agent_addr(struct server *srv, struct sockaddr_storage *sk);
+void set_srv_agent_port(struct server *srv, int port);
 
 /* Use this one only. This inline version only ensures that we don't
  * call the function when the observe mode is disabled.
diff --git a/include/haproxy/server-t.h b/include/haproxy/server-t.h
index 45f41959c..32697a9c4 100644
--- a/include/haproxy/server-t.h
+++ b/include/haproxy/server-t.h
@@ -138,6 +138,7 @@ enum srv_initaddr {
 #define SRV_F_NON_STICK0x0004/* never add connections allocated to 
this server to a stick table */
 #define SRV_F_USE_NS_FROM_PP 0x0008  /* use namespace associated with 
connection if present */
 #define SRV_F_FORCED_ID0x0010/* server's ID was forced in the 
configuration */
+#define SRV_F_AGENTPORT0x0040/* this server has a agent port 
configured */
 #define SRV_F_AGENTADDR0x0080/* this server has a agent addr 
configured */
 #define SRV_F_COOKIESET0x0100/* this server has a cookie 
configured, so don't generate dynamic cookies */
 #define SRV_F_FASTOPEN 0x0200/* Use TCP Fast Open to connect to 
server */
diff --git a/src/check.c b/src/check.c
index 31f108bff..194f3b4a6 100644
--- a/src/check.c
+++ b/src/check.c
@@ -1697,7 +1697,7 @@ static int srv_parse_agent_port(char **args, int 
*cur_arg, struct proxy *curpx,
}
 
global.maxsock++;
-   srv->agent.port = atol(args[*cur_arg+1]);
+   set_srv_agent_port(srv, atol(args[*cur_arg + 1]));
 
   out:
return err_code;
@@ -1741,6 +1741,13 @@ inline void set_srv_agent_addr(struct server *srv, 
struct sockaddr_storage *sk)
srv->flags |= SRV_F_AGENTADDR;
 }
 
+/* set agent port and apprropriate flag */
+inline void set_srv_agent_port(struct server *srv, int port)
+{
+   srv->agent.port = port;
+   srv->flags |= SRV_F_AGENTPORT;
+}
+
 /* Parse the "agent-send" server keyword */
 static int srv_parse_agent_send(char **args, int *cur_arg, struct proxy 
*curpx, struct server *srv,
char **errmsg)
@@ -2060,6 +2067,9 @@ static int srv_parse_check_port(char **args, int 
*cur_arg, struct proxy *curpx,
 
global.maxsock++;
srv->check.port = atol(args[*cur_arg+1]);
+   /* if agentport was never set, we can use port */
+   if (!(srv->flags & SRV_F_AGENTPORT))
+   set_srv_agent_port(srv, srv->check.port);
 
   out:
return err_code;
-- 
2.30.0

[PATCH v3 3/5] MEDIUM: check: remove checkport checkaddr flag

[William Dauchy]

While trying to fix some consistency problem with the config file/cli
(e.g. check-port cli command does not set the flag), we realised
checkport flag was not necessarily needed. Indeed tcpcheck uses service
port as the last choice if check.port is zero. So we can assume if
check.port is zero, it means it was never set by the user, regardless if
it is by the cli or config file.  In the longterm this will avoid to
introduce a new consistency issue if we forget to set the flag.

in the same manner of checkport flag, we don't really need checkaddr
flag. We can assume if checkaddr is not set, it means it was never set
by the user or config.

Signed-off-by: William Dauchy 
---
 include/haproxy/server-t.h | 2 --
 src/check.c| 2 --
 src/dns.c  | 3 +--
 src/server.c   | 7 ++-
 4 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/include/haproxy/server-t.h b/include/haproxy/server-t.h
index e42b1c7ed..45f41959c 100644
--- a/include/haproxy/server-t.h
+++ b/include/haproxy/server-t.h
@@ -138,8 +138,6 @@ enum srv_initaddr {
 #define SRV_F_NON_STICK0x0004/* never add connections allocated to 
this server to a stick table */
 #define SRV_F_USE_NS_FROM_PP 0x0008  /* use namespace associated with 
connection if present */
 #define SRV_F_FORCED_ID0x0010/* server's ID was forced in the 
configuration */
-#define SRV_F_CHECKADDR0x0020/* this server has a check addr 
configured */
-#define SRV_F_CHECKPORT0x0040/* this server has a check port 
configured */
 #define SRV_F_AGENTADDR0x0080/* this server has a agent addr 
configured */
 #define SRV_F_COOKIESET0x0100/* this server has a cookie 
configured, so don't generate dynamic cookies */
 #define SRV_F_FASTOPEN 0x0200/* Use TCP Fast Open to connect to 
server */
diff --git a/src/check.c b/src/check.c
index 879fe84ce..e24050ff2 100644
--- a/src/check.c
+++ b/src/check.c
@@ -1527,7 +1527,6 @@ static int srv_parse_addr(char **args, int *cur_arg, 
struct proxy *curpx, struct
}
 
srv->check.addr = srv->agent.addr = *sk;
-   srv->flags |= SRV_F_CHECKADDR;
srv->flags |= SRV_F_AGENTADDR;
 
   out:
@@ -2050,7 +2049,6 @@ static int srv_parse_check_port(char **args, int 
*cur_arg, struct proxy *curpx,
 
global.maxsock++;
srv->check.port = atol(args[*cur_arg+1]);
-   srv->flags |= SRV_F_CHECKPORT;
 
   out:
return err_code;
diff --git a/src/dns.c b/src/dns.c
index 8c97df46b..8fc9089e7 100644
--- a/src/dns.c
+++ b/src/dns.c
@@ -712,8 +712,7 @@ static void dns_check_dns_response(struct dns_resolution 
*res)
 
srv->svc_port = item->port;
srv->flags   &= ~SRV_F_MAPPORTS;
-   if ((srv->check.state & CHK_ST_CONFIGURED) &&
-   !(srv->flags & SRV_F_CHECKPORT))
+   if (!srv->check.port)
srv->check.port = item->port;
 
if (!srv->dns_opts.ignore_weight) {
diff --git a/src/server.c b/src/server.c
index d8216058f..1fd71e403 100644
--- a/src/server.c
+++ b/src/server.c
@@ -1660,8 +1660,6 @@ static void srv_settings_cpy(struct server *srv, struct 
server *src, int srv_tmp
srv->flags   |= src->flags;
srv->do_check = src->do_check;
srv->do_agent = src->do_agent;
-   if (srv->check.port)
-   srv->flags |= SRV_F_CHECKPORT;
srv->check.inter  = src->check.inter;
srv->check.fastinter  = src->check.fastinter;
srv->check.downinter  = src->check.downinter;
@@ -2985,8 +2983,7 @@ static void srv_update_state(struct server *srv, int 
version, char **params)
}
 
/* configure check.port accordingly */
-   if ((srv->check.state & CHK_ST_CONFIGURED) &&
-   !(srv->flags & SRV_F_CHECKPORT))
+   if (!srv->check.port)
srv->check.port = port_check;
 
/* Unset SRV_F_MAPPORTS for SRV records.
@@ -3673,7 +3670,7 @@ const char *update_server_addr_port(struct server *s, 
const char *addr, const ch
 * we're switching from a fixed port to a 
SRV_F_MAPPORTS (mapped) port
 * prevent PORT change if check doesn't have 
it's dedicated port while switching
 * to port mapping */
-   if ((s->check.state & CHK_ST_CONFIGURED) && 
!(s->flags & SRV_F_CHECKPORT)) {
+   if (!s->check.port) {
chunk_appendf(msg, "can't change  
to port map because it is incompatible with current 

[PATCH v3 0/5] fix check port/addr consistency

[William Dauchy]

Hello Christopher,

Here is my last update on port/addr consistency. I addressed all the
point you mentioned. I hope I did not forgot anything.  I will come back
with `check-addr` and `agent-port` on the cli once those patches are
accepted.

William Dauchy (5):
  BUG/MINOR: cli: fix set server addr/port coherency with health checks
  MEDIUM: server: adding support for check_port in server state
  MEDIUM: check: remove checkport checkaddr flag
  BUG/MINOR: check: consitent way to set agentaddr
  MEDIUM: check: align agentaddr and agentport behaviour

 doc/configuration.txt | 10 +--
 doc/management.txt|  1 +
 include/haproxy/check.h   |  2 +
 include/haproxy/server-t.h| 10 +--
 .../checks/1be_40srv_odd_health_checks.vtc|  2 +-
 .../checks/40be_2srv_odd_health_checks.vtc|  2 +-
 reg-tests/checks/4be_1srv_health_checks.vtc   |  6 +-
 src/check.c   | 33 --
 src/dns.c |  3 +-
 src/proxy.c   |  4 +-
 src/server.c  | 64 +--
 11 files changed, 78 insertions(+), 59 deletions(-)

-- 
2.30.0

[PATCH v3 1/5] BUG/MINOR: cli: fix set server addr/port coherency with health checks

[William Dauchy]

while reading `update_server_addr_port` I found out some things which
can be seen as incoherency. I hope I did not overlooked anything:

- one comment is stating check's address should be updated if it uses
  the server one; however the condition checks if `SRV_F_CHECKADDR` is
  set; this flag is set when a check address is set; result is that we
  override the check address where I was not expecting it. In fact we
  don't need to update anything here as server addr is used when check
  addr is not set.
- same goes for check agent addr
- for port, it is a bit different, we update the check port if it is
  unset. This is harmless because we also use server port if check port
  is unset. However it creates some incoherency before/after using this
  command, as check port should stay unset througout the life of the
  process unless it is is set by `set server check-port` command.

quite hard to locate the origin of this this issue but the function was
introduced in commit d458adcc52b74608e2fe6a2a95f09ce5e94932b7 ("MINOR:
new update_server_addr_port() function to change both server's ADDR and
service PORT"). I was however not able to determine whether this is due
to a change of behavior along the years. So this patch can potentially
be backported up to v1.8 but we must be careful while doing so, as the
code has changed a lot. That being said, the bug being not very
impacting I would be fine keeping it for 2.4 only.

Signed-off-by: William Dauchy 
---
 src/server.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/src/server.c b/src/server.c
index 10f528640..99b7e9181 100644
--- a/src/server.c
+++ b/src/server.c
@@ -3625,16 +3625,6 @@ const char *update_server_addr_port(struct server *s, 
const char *addr, const ch
ipcpy(, >addr);
changed = 1;
 
-   /* we also need to update check's ADDR only if it uses the 
server's one */
-   if ((s->check.state & CHK_ST_CONFIGURED) && (s->flags & 
SRV_F_CHECKADDR)) {
-   ipcpy(, >check.addr);
-   }
-
-   /* we also need to update agent ADDR only if it use the 
server's one */
-   if ((s->agent.state & CHK_ST_CONFIGURED) && (s->flags & 
SRV_F_AGENTADDR)) {
-   ipcpy(, >agent.addr);
-   }
-
/* update report for caller */
chunk_printf(msg, "IP changed from '%s' to '%s'", current_addr, 
addr);
}
@@ -3714,11 +3704,6 @@ const char *update_server_addr_port(struct server *s, 
const char *addr, const ch
}
 
chunk_appendf(msg, "%d'", new_port);
-
-   /* we also need to update health checks port only if it 
uses server's realport */
-   if ((s->check.state & CHK_ST_CONFIGURED) && !(s->flags 
& SRV_F_CHECKPORT)) {
-   s->check.port = new_port;
-   }
}
else {
chunk_appendf(msg, "no need to change the port");
-- 
2.30.0

[PATCH v3 4/5] BUG/MINOR: check: consitent way to set agentaddr

[William Dauchy]

small consistency problem with `addr` and `agent-addr` options:
for the both options, the last one parsed is always used to set the
agent-check addr.  Thus these two lines don't have the same behavior:

  server ... addr  agent-addr 
  server ... agent-addr  addr 

After this patch `agent-addr` will always be the priority option over
`addr`. It means we test the flag before setting agentaddr.
We also fix all the places where we did not set the flag to be coherent
everywhere.

I was not really able to determine where this issue is coming from. So
it is probable we may backport it to all stable version where the agent
is supported.

Signed-off-by: William Dauchy 
---
 include/haproxy/check.h |  1 +
 src/check.c | 19 +++
 src/server.c|  7 ++-
 3 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/include/haproxy/check.h b/include/haproxy/check.h
index 8d70040a3..ed8124470 100644
--- a/include/haproxy/check.h
+++ b/include/haproxy/check.h
@@ -52,6 +52,7 @@ int spoe_prepare_healthcheck_request(char **req, int *len);
 int spoe_handle_healthcheck_response(char *frame, size_t size, char *err, int 
errlen);
 
 int set_srv_agent_send(struct server *srv, const char *send);
+void set_srv_agent_addr(struct server *srv, struct sockaddr_storage *sk);
 
 /* Use this one only. This inline version only ensures that we don't
  * call the function when the observe mode is disabled.
diff --git a/src/check.c b/src/check.c
index e24050ff2..31f108bff 100644
--- a/src/check.c
+++ b/src/check.c
@@ -1526,8 +1526,10 @@ static int srv_parse_addr(char **args, int *cur_arg, 
struct proxy *curpx, struct
goto error;
}
 
-   srv->check.addr = srv->agent.addr = *sk;
-   srv->flags |= SRV_F_AGENTADDR;
+   srv->check.addr = *sk;
+   /* if agentaddr was never set, we can use addr */
+   if (!(srv->flags & SRV_F_AGENTADDR))
+   set_srv_agent_addr(srv, sk);
 
   out:
return err_code;
@@ -1537,21 +1539,23 @@ static int srv_parse_addr(char **args, int *cur_arg, 
struct proxy *curpx, struct
goto out;
 }
 
-
 /* Parse the "agent-addr" server keyword */
 static int srv_parse_agent_addr(char **args, int *cur_arg, struct proxy 
*curpx, struct server *srv,
char **errmsg)
 {
+   struct sockaddr_storage sk;
int err_code = 0;
 
if (!*(args[*cur_arg+1])) {
memprintf(errmsg, "'%s' expects an address as argument.", 
args[*cur_arg]);
goto error;
}
-   if(str2ip(args[*cur_arg+1], >agent.addr) == NULL) {
+   memset(, 0, sizeof(sk));
+   if (str2ip(args[*cur_arg + 1], ) == NULL) {
memprintf(errmsg, "parsing agent-addr failed. Check if '%s' is 
correct address.", args[*cur_arg+1]);
goto error;
}
+   set_srv_agent_addr(srv, );
 
   out:
return err_code;
@@ -1730,6 +1734,13 @@ int set_srv_agent_send(struct server *srv, const char 
*send)
return 0;
 }
 
+/* set agent addr and apprropriate flag */
+inline void set_srv_agent_addr(struct server *srv, struct sockaddr_storage *sk)
+{
+   srv->agent.addr = *sk;
+   srv->flags |= SRV_F_AGENTADDR;
+}
+
 /* Parse the "agent-send" server keyword */
 static int srv_parse_agent_send(char **args, int *cur_arg, struct proxy 
*curpx, struct server *srv,
char **errmsg)
diff --git a/src/server.c b/src/server.c
index 1fd71e403..b6b3b0893 100644
--- a/src/server.c
+++ b/src/server.c
@@ -4384,9 +4384,14 @@ static int cli_parse_set_server(char **args, char 
*payload, struct appctx *appct
cli_err(appctx, "'set server  agent' expects 'up' 
or 'down'.\n");
}
else if (strcmp(args[3], "agent-addr") == 0) {
+   struct sockaddr_storage sk;
+
+   memset(, 0, sizeof(sk));
if (!(sv->agent.state & CHK_ST_ENABLED))
cli_err(appctx, "agent checks are not enabled on this 
server.\n");
-   else if (str2ip(args[4], >agent.addr) == NULL)
+   else if (str2ip(args[4], ))
+   set_srv_agent_addr(sv, );
+   else
cli_err(appctx, "incorrect addr address given for 
agent.\n");
}
else if (strcmp(args[3], "agent-send") == 0) {
-- 
2.30.0

[PATCH v3 2/5] MEDIUM: server: adding support for check_port in server state

[William Dauchy]

We can currently change the check-port using the cli command `set server
check-port` but there is a consistency issue when using server state.
This patch aims to fix this problem but will be also a good preparation
work to get rid of checkport flag, so we are able to know when checkport
was set by config.

I am fully aware this is not making github #953 moving forward, I
however think this might be acceptable while waiting for a proper
solution and resolve consistency problem faced with port settings.

Signed-off-by: William Dauchy 
---
 doc/management.txt|  1 +
 include/haproxy/server-t.h|  7 ++--
 .../checks/1be_40srv_odd_health_checks.vtc|  2 +-
 .../checks/40be_2srv_odd_health_checks.vtc|  2 +-
 reg-tests/checks/4be_1srv_health_checks.vtc   |  6 ++--
 src/proxy.c   |  4 +--
 src/server.c  | 35 ---
 7 files changed, 35 insertions(+), 22 deletions(-)

diff --git a/doc/management.txt b/doc/management.txt
index de3fbf607..b74aba769 100644
--- a/doc/management.txt
+++ b/doc/management.txt
@@ -2447,6 +2447,7 @@ show servers state []
  srv_port:Server port.
  srvrecord:   DNS SRV record associated to this SRV.
  srv_use_ssl: use ssl for server connections.
+ srv_check_port:  Server check port.
 
 show sess
   Dump all known sessions. Avoid doing this on slow connections as this can
diff --git a/include/haproxy/server-t.h b/include/haproxy/server-t.h
index b29c75c0b..e42b1c7ed 100644
--- a/include/haproxy/server-t.h
+++ b/include/haproxy/server-t.h
@@ -125,10 +125,11 @@ enum srv_initaddr {
 "srv_fqdn "   \
 "srv_port "   \
 "srvrecord "  \
-"srv_use_ssl"
+"srv_use_ssl "\
+"srv_check_port"
 
-#define SRV_STATE_FILE_MAX_FIELDS 21
-#define SRV_STATE_FILE_NB_FIELDS_VERSION_1 20
+#define SRV_STATE_FILE_MAX_FIELDS 22
+#define SRV_STATE_FILE_NB_FIELDS_VERSION_1 21
 #define SRV_STATE_LINE_MAXLEN 512
 
 /* server flags -- 32 bits */
diff --git a/reg-tests/checks/1be_40srv_odd_health_checks.vtc 
b/reg-tests/checks/1be_40srv_odd_health_checks.vtc
index bd07d8840..f01205295 100644
--- a/reg-tests/checks/1be_40srv_odd_health_checks.vtc
+++ b/reg-tests/checks/1be_40srv_odd_health_checks.vtc
@@ -112,6 +112,6 @@ syslog S -wait
 
 haproxy h1 -cli {
 send "show servers state"
-expect ~ "# be_id be_name srv_id srv_name srv_addr srv_op_state 
srv_admin_state srv_uweight srv_iweight srv_time_since_last_change 
srv_check_status srv_check_result srv_check_health srv_check_state 
srv_agent_state bk_f_forced_id srv_f_forced_id srv_fqdn srv_port srvrecord 
srv_use_ssl\n2 be1 1 srv0 ${s0_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - 
${s0_port} - 0\n2 be1 2 srv1 ${s1_addr} 2 0 1 1 [[:digit:]]+ 6 ([[:digit:]]+ 
){3}0 0 0 - ${s1_port} - 0\n2 be1 3 srv2 ${s2_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 
0 0 0 0 - ${s2_port} - 0\n2 be1 4 srv3 ${s3_addr} 2 0 1 1 [[:digit:]]+ 6 
([[:digit:]]+ ){3}0 0 0 - ${s3_port} - 0\n2 be1 5 srv4 ${s4_addr} 2 0 1 1 
[[:digit:]]+ 1 0 1 0 0 0 0 - ${s4_port} - 0\n2 be1 6 srv5 ${s5_addr} 2 0 1 1 
[[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - ${s5_port} - 0\n2 be1 7 srv6 
${s6_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - ${s6_port} - 0\n2 be1 8 srv7 
${s7_addr} 2 0 1 1 [[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - ${s7_port} - 0\n2 
be1 9 srv8 ${s8_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - ${s8_port} - 0\n2 
be1 10 srv9 ${s9_addr} 2 0 1 1 [[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - 
${s9_port} - 0\n2 be1 11 srv10 ${s10_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - 
${s10_port} - 0\n2 be1 12 srv11 ${s11_addr} 2 0 1 1 [[:digit:]]+ 6 
([[:digit:]]+ ){3}0 0 0 - ${s11_port} - 0\n2 be1 13 srv12 ${s12_addr} 2 0 1 1 
[[:digit:]]+ 1 0 1 0 0 0 0 - ${s12_port} - 0\n2 be1 14 srv13 ${s13_addr} 2 0 1 
1 [[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - ${s13_port} - 0\n2 be1 15 srv14 
${s14_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - ${s14_port} - 0\n2 be1 16 
srv15 ${s15_addr} 2 0 1 1 [[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - ${s15_port} 
- 0\n2 be1 17 srv16 ${s16_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - 
${s16_port} - 0\n2 be1 18 srv17 ${s17_addr} 2 0 1 1 [[:digit:]]+ 6 
([[:digit:]]+ ){3}0 0 0 - ${s17_port} - 0\n2 be1 19 srv18 ${s18_addr} 2 0 1 1 
[[:digit:]]+ 1 0 1 0 0 0 0 - ${s18_port} - 0\n2 be1 20 srv19 ${s19_addr} 2 0 1 
1 [[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - ${s19_port} - 0\n2 be1 21 srv20 
${s20_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - ${s20_port} - 0\n2 be1 22 
srv21 ${s21_addr} 2 0 1 1 [[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - ${s21_port} 
- 0\n2 be1 23 srv22 ${s22_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - 
${s22_port} - 0\n2 be1 24 srv23 ${s23_addr} 2 0 1 1 [[:digit:]]+ 6 
([[:digit:]]+ ){3}0 0 0 - ${s23_port} - 0\n2 be1 25 srv24 ${s24_addr} 2 0 1 1 
[[:digit:]]+ 1 0 1 0 0 0 0 - ${s24_port} - 0\n2 be1 26 srv25 ${s25_addr} 2 0 1 
1 

Re: (possibly off topic) how to handle Chrome on SSL mass hosting ?

[Lukas Tribus]

On Wed, 3 Feb 2021 at 18:47, Илья Шипицин  wrote:
>> while I do not mind to have such optimization, but when 'a.example.com"
>> responds with http2 GOAWAY, that affects also "b.example.com" and "
>> c.example.com". Chrome is not clever enough to open new connections instead
>> of abandoned one.
>
> above approach works for Chrome (and does not work for Safari)
> unfortunately we found Safari is using connection reuse just like Chrome, and 
> Safari does not handle 421 properly

In which exact case is GOAWAY sent to the browser and how does that
impact the browser behavior exactly?

You are probably doing routing based on the host header, not the SNI
value, so you wouldn't have a routing problem. I'm unsure what the
actual problem is that you are trying to solve.



Lukas

Re: SSL session resumption

[Lukas Tribus]

Hello,

On Wed, 3 Feb 2021 at 17:44, Илья Шипицин  wrote:
>
> TLS1.2 uses tls tickets, when TLS1.0 uses ssl sessions.

I believe this is incorrect, TLSv1.2 works just fine with Session ID's
(RFC5246) and TLS 1.0 works fine with TLS tickets (RFC5077). I'm not
aware of any restrictions between TLSv1.0/1.2 and session ID's vs TLS
tickets.


Lukas

Re: (possibly off topic) how to handle Chrome on SSL mass hosting ?

[Илья Шипицин]

вт, 1 дек. 2020 г. в 00:37, Tim Düsterhus :

> Ilya,
>
> Am 30.11.20 um 20:21 schrieb Илья Шипицин:
> > I guess here are people running similar high density SSL hosting, do you
> > have some approaches to please Chrome ? I would be happy if I can tell
> him
> > to open separate connections for the domains that I wish.
> >
>
> Use HTTP 421 Misdirected Request:
>
> >   http-request   set-var(txn.host)hdr(host)
> >   http-request   deny deny_status 400 unless { req.hdr_cnt(host) eq
> 1 }
> >   http-request   deny deny_status 421 unless {
> ssl_fc_sni,strcmp(txn.host) eq 0 }
>


above approach works for Chrome (and does not work for Safari)
unfortunately we found Safari is using connection reuse just like Chrome,
and Safari does not handle 421 properly

look like "something on Safari side"



>
> Or just use a dedicated certificate or IPv6 address per customer.
>
> Best regards
> Tim Düsterhus
>

Re: SSL session resumption

[Илья Шипицин]

TLS1.2 uses tls tickets, when TLS1.0 uses ssl sessions.
you have disabled tls tickets in config.

is there a chance that you upgraded from tls1.0 to tls1.2 ? (it should be
clearly seen in wireshark)

people usually disable tls tickets (and ssl sessions) for security
considerations, in such case full tls handshake is somewhat expected.


ср, 3 февр. 2021 г. в 18:44, Johan Andersson :

> Hello Lukas
>
> Output from 2.1.3
>
> -
> HA-Proxy version 2.1.3 2020/02/12 - https://haproxy.org/
> Status: stable branch - will stop receiving fixes around Q1 2021.
> Known bugs: http://www.haproxy.org/bugs/bugs-2.1.3.html
> Build options :
>   TARGET  = linux-glibc
>   CPU = generic
>   CC  = gcc
>   CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
> -fwrapv -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter
> -Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered
> -Wno-missing-field-initializers -Wno-implicit-fallthrough
> -Wno-stringop-overflow -Wno-cast-function-type -Wtype-limits
> -Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond
> -Wnull-dereference
>   OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_GETADDRINFO=1 USE_OPENSSL=1
> USE_LUA=1 USE_ZLIB=1
>
> Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER -PCRE
> -PCRE_JIT +PCRE2 +PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED
> -REGPARM -STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE
> +LIBCRYPT +CRYPT_H -VSYSCALL +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4
> -MY_ACCEPT4 +ZLIB -SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS
> -51DEGREES -WURFL -SYSTEMD -OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS
>
> Default settings :
>   bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>
> Built with multi-threading support (MAX_THREADS=64, default=4).
> Built with OpenSSL version : OpenSSL 1.1.1d  10 Sep 2019
> Running on OpenSSL version : OpenSSL 1.1.1d  10 Sep 2019
> OpenSSL library supports TLS extensions : yes
> OpenSSL library supports SNI : yes
> OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
> Built with Lua version : Lua 5.3.3
> Built with network namespace support.
> Built with transparent proxy support using: IP_TRANSPARENT
> IPV6_TRANSPARENT IP_FREEBIND
> Built with PCRE2 version : 10.32 2018-09-10
> PCRE2 library supports JIT : yes
> Encrypted password support via crypt(3): yes
> Built with zlib version : 1.2.11
> Running on zlib version : 1.2.11
> Compression algorithms supported : identity("identity"),
> deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
> Built with the Prometheus exporter as a service
>
> Available polling systems :
>   epoll : pref=300,  test result OK
>poll : pref=200,  test result OK
>  select : pref=150,  test result OK
> Total: 3 (3 usable), will use epoll.
>
> Available multiplexer protocols :
> (protocols marked as  cannot be specified using 'proto' keyword)
>   h2 : mode=HTTP   side=FE|BE mux=H2
> fcgi : mode=HTTP   side=BEmux=FCGI
> : mode=HTTP   side=FE|BE mux=H1
> : mode=TCPside=FE|BE mux=PASS
>
> Available services :
> prometheus-exporter
>
> Available filters :
> [SPOE] spoe
> [CACHE] cache
> [FCGI] fcgi-app
> [TRACE] trace
> [COMP] compression
>
> -
>
> Output from 2.2.4
>
>
> -
> HA-Proxy version 2.2.4-de45672 2020/09/30 - https://haproxy.org/
> Status: long-term supported branch - will stop receiving fixes around Q2
> 2025.
> Known bugs: http://www.haproxy.org/bugs/bugs-2.2.4.html
> Running on: Linux 4.19.121-linuxkit #1 SMP Tue Dec 1 17:50:32 UTC 2020
> x86_64
> Build options :
>   TARGET  = linux-glibc
>   CPU = generic
>   CC  = gcc
>   CFLAGS  = -O2 -g -Wall -Wextra -Wdeclaration-after-statement -fwrapv
> -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered
> -Wno-missing-field-initializers -Wno-stringop-overflow
> -Wno-cast-function-type -Wtype-limits -Wshift-negative-value
> -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference
>   OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_GETADDRINFO=1 USE_OPENSSL=1
> USE_LUA=1 USE_ZLIB=1
>
> Feature list : +EPOLL -KQUEUE +NETFILTER -PCRE -PCRE_JIT +PCRE2 +PCRE2_JIT
> +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +BACKTRACE -STATIC_PCRE
> -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H
> +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4 +ZLIB -SLZ +CPU_AFFINITY +TFO
> +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD -OBSOLETE_LINKER +PRCTL
> +THREAD_DUMP -EVPORTS
>
> Default settings :
>   bufsize = 16384, maxrewrite = 1024, maxpollevents = 

RE: SSL session resumption

[Johan Andersson]

Hi again

I just saw that I posted an error in the 2.2.4 config file, this should be the 
correct one:

-
global
   # Disable SSLv3 and, for now, TLS 1.3
   ssl-default-bind-options ssl-min-ver TLSv1.0 ssl-max-ver TLSv1.2

   # Lower default dh param (remove this once java7 is no longer a problem)
   tune.ssl.default-dh-param 1024

   # For TLS <= 1.2 (if enabled)
   # Per https://wiki.mozilla.org/Security/Server_Side_TLS, configuration: old 
(backward compatibility), remove DHE-* and DES-*
   ssl-default-bind-ciphers 
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA

   # For TLS = 1.3 (if enabled)
   # Per https://wiki.mozilla.org/Security/Server_Side_TLS, configuration: 
modern (compatibility)
   ssl-default-bind-ciphersuites 
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

   tune.ssl.lifetime 24h
   tune.ssl.cachesize 10

-

Best regards
Johan

-Original Message-
From: Lukas Tribus  
Sent: den 3 februari 2021 14:03
To: Johan Andersson 
Cc: haproxy@formilux.org
Subject: Re: SSL session resumption

Hello Johan,


we are gonna need the outputs of "haproxy -vv" from both situations, as well as 
at the very least *all* the ssl configuration parameters in haproxy that you 
are using.

However, I do not believe it is likely that we can find the root cause, without 
access to those handshakes, since it cannot be reproduced by openssl s_client.


What definitely changed in haproxy 2.2 is that the default minimum TLS version 
is now 1.2. To rollback to TLS 1.0 you can configure:

global
 ssl-default-bind-options ssl-min-ver TLSv1.0



Regards,

Lukas



On Wed, 3 Feb 2021 at 13:36, Johan Andersson  wrote:
>
> To whom it may concern
>
>
>
> We have recently upgraded out HAProxy version from 2.1.3 to 2.2.4.
>
> After the upgrade we got customer complaints that the data usage of their 
> devices had gone up. Our company sells proprietary hardware that logs data 
> and sends that to a web service which we host. These devices are often 
> deployed remotely and connected via shaky 3G connections with data-capped SIM 
> cards, so low data usage is very important.
>
> After some digging with Wireshark, we found that the SSL sessions are not 
> resumed. Instead a new handshake is initiated every time the device sends 
> data. Which is typically once an hour.
>
> We have set the global tune.ssl.lifetime parameter to 24h and the 
> tune.ssl.cachesize to 10 and this has worked since HAProxy version 1.6.9 
> when we first introduced it.
>
> We have also tested with the latest 2.1.11 release of HAProxy and it behaves 
> the same way as the 2.1.3 version. We have also tested with 2.2.0 and 2.2.8 
> and they behave the same as 2.2.4.
>
>
>
> We have tried reproducing this with openssl s_client, saving the session id 
> between requests but can’t reproduce it that way.
>
> We have also pored over the change logs between versions to see if there is 
> some change that could make HAProxy behave this way.
>
>
>
> We’re at a loss here, what could cause this behavior, and how can we fix it?
>
>
>
>
>
> Best regards
>
>
>
> Johan Andersson
>
> Development Engineer
>
> Global Platforms Cloud Team
>
>
>
> HMS Industrial Networks AB
>
> Stationsgatan 37, Box 4126
>
> 300 04 Halmstad, Sweden
>
>
>
> Email: j...@hms-networks.com
>
>
>
>
>
> HALMSTAD | BARCELONA |  BEIJING | BOSTON | BUCHEN | CHICAGO | COVENTRY 
> | DEN BOSCH | DUBAI | IGUALADA |
>
> KARLSRUHE | MILAN | MULHOUSE | NIVELLES | PUNE | RAVENSBURG | SEOUL | 
> SINGAPORE | TOKYO | WETZLAR
>
>

RE: SSL session resumption

[Johan Andersson]

Hi

I have some wireshark logs, but I’ll have to go through them to make sure it 
doesn’t contain any sensitive information.

Best regards
Johan

From: Илья Шипицин 
Sent: den 3 februari 2021 14:10
To: Johan Andersson 
Cc: HAProxy 
Subject: Re: SSL session resumption

Can you provide wireshark capture? It is very useful

On Wed, Feb 3, 2021, 5:39 PM Johan Andersson mailto:j...@hms.se>> 
wrote:
To whom it may concern

We have recently upgraded out HAProxy version from 2.1.3 to 2.2.4.
After the upgrade we got customer complaints that the data usage of their 
devices had gone up. Our company sells proprietary hardware that logs data and 
sends that to a web service which we host. These devices are often deployed 
remotely and connected via shaky 3G connections with data-capped SIM cards, so 
low data usage is very important.
After some digging with Wireshark, we found that the SSL sessions are not 
resumed. Instead a new handshake is initiated every time the device sends data. 
Which is typically once an hour.
We have set the global tune.ssl.lifetime parameter to 24h and the 
tune.ssl.cachesize to 10 and this has worked since HAProxy version 1.6.9 
when we first introduced it.
We have also tested with the latest 2.1.11 release of HAProxy and it behaves 
the same way as the 2.1.3 version. We have also tested with 2.2.0 and 2.2.8 and 
they behave the same as 2.2.4.

We have tried reproducing this with openssl s_client, saving the session id 
between requests but can’t reproduce it that way.
We have also pored over the change logs between versions to see if there is 
some change that could make HAProxy behave this way.

We’re at a loss here, what could cause this behavior, and how can we fix it?


Best regards

Johan Andersson
Development Engineer
Global Platforms Cloud Team

HMS Industrial Networks AB
Stationsgatan 37, Box 4126
300 04 Halmstad, Sweden

Email: j...@hms-networks.com

[cid:image001.png@01D6FA2D.98D58250]

HALMSTAD | BARCELONA |  BEIJING | BOSTON | BUCHEN | CHICAGO | COVENTRY | DEN 
BOSCH | DUBAI | IGUALADA |
KARLSRUHE | MILAN | MULHOUSE | NIVELLES | PUNE | RAVENSBURG | SEOUL | SINGAPORE 
| TOKYO | WETZLAR

RE: SSL session resumption

[Johan Andersson]

Hello Lukas

Output from 2.1.3
-
HA-Proxy version 2.1.3 2020/02/12 - https://haproxy.org/
Status: stable branch - will stop receiving fixes around Q1 2021.
Known bugs: http://www.haproxy.org/bugs/bugs-2.1.3.html
Build options :
  TARGET  = linux-glibc
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement -fwrapv 
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter 
-Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered 
-Wno-missing-field-initializers -Wno-implicit-fallthrough 
-Wno-stringop-overflow -Wno-cast-function-type -Wtype-limits 
-Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference
  OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_GETADDRINFO=1 USE_OPENSSL=1 
USE_LUA=1 USE_ZLIB=1

Feature list : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER -PCRE -PCRE_JIT 
+PCRE2 +PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED -REGPARM 
-STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT 
+CRYPT_H -VSYSCALL +GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4 -MY_ACCEPT4 +ZLIB 
-SLZ +CPU_AFFINITY +TFO +NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD 
-OBSOLETE_LINKER +PRCTL +THREAD_DUMP -EVPORTS

Default settings :
  bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_THREADS=64, default=4).
Built with OpenSSL version : OpenSSL 1.1.1d  10 Sep 2019
Running on OpenSSL version : OpenSSL 1.1.1d  10 Sep 2019
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.3.3
Built with network namespace support.
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND
Built with PCRE2 version : 10.32 2018-09-10
PCRE2 library supports JIT : yes
Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with the Prometheus exporter as a service

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols marked as  cannot be specified using 'proto' keyword)
  h2 : mode=HTTP   side=FE|BE mux=H2
fcgi : mode=HTTP   side=BEmux=FCGI
: mode=HTTP   side=FE|BE mux=H1
: mode=TCPside=FE|BE mux=PASS

Available services :
prometheus-exporter

Available filters :
[SPOE] spoe
[CACHE] cache
[FCGI] fcgi-app
[TRACE] trace
[COMP] compression
-

Output from 2.2.4

-
HA-Proxy version 2.2.4-de45672 2020/09/30 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2 2025.
Known bugs: http://www.haproxy.org/bugs/bugs-2.2.4.html
Running on: Linux 4.19.121-linuxkit #1 SMP Tue Dec 1 17:50:32 UTC 2020 x86_64
Build options :
  TARGET  = linux-glibc
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -Wall -Wextra -Wdeclaration-after-statement -fwrapv 
-Wno-unused-label -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered 
-Wno-missing-field-initializers -Wno-stringop-overflow -Wno-cast-function-type 
-Wtype-limits -Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond 
-Wnull-dereference
  OPTIONS = USE_PCRE2=1 USE_PCRE2_JIT=1 USE_GETADDRINFO=1 USE_OPENSSL=1 
USE_LUA=1 USE_ZLIB=1

Feature list : +EPOLL -KQUEUE +NETFILTER -PCRE -PCRE_JIT +PCRE2 +PCRE2_JIT 
+POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED +BACKTRACE -STATIC_PCRE 
-STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H 
+GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4 +ZLIB -SLZ +CPU_AFFINITY +TFO +NS 
+DL +RT -DEVICEATLAS -51DEGREES -WURFL -SYSTEMD -OBSOLETE_LINKER +PRCTL 
+THREAD_DUMP -EVPORTS

Default settings :
  bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with multi-threading support (MAX_THREADS=64, default=4).
Built with OpenSSL version : OpenSSL 1.1.1d  10 Sep 2019
Running on OpenSSL version : OpenSSL 1.1.1d  10 Sep 2019
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.3.3
Built with network namespace support.
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), 

Re: SSL session resumption

[Илья Шипицин]

Can you provide wireshark capture? It is very useful

On Wed, Feb 3, 2021, 5:39 PM Johan Andersson  wrote:

> To whom it may concern
>
>
>
> We have recently upgraded out HAProxy version from 2.1.3 to 2.2.4.
>
> After the upgrade we got customer complaints that the data usage of their
> devices had gone up. Our company sells proprietary hardware that logs data
> and sends that to a web service which we host. These devices are often
> deployed remotely and connected via shaky 3G connections with data-capped
> SIM cards, so low data usage is very important.
>
> After some digging with Wireshark, we found that the SSL sessions are not
> resumed. Instead a new handshake is initiated every time the device sends
> data. Which is typically once an hour.
>
> We have set the global tune.ssl.lifetime parameter to 24h and the
> tune.ssl.cachesize to 10 and this has worked since HAProxy version
> 1.6.9 when we first introduced it.
>
> We have also tested with the latest 2.1.11 release of HAProxy and it
> behaves the same way as the 2.1.3 version. We have also tested with 2.2.0
> and 2.2.8 and they behave the same as 2.2.4.
>
>
>
> We have tried reproducing this with openssl s_client, saving the session
> id between requests but can’t reproduce it that way.
>
> We have also pored over the change logs between versions to see if there
> is some change that could make HAProxy behave this way.
>
>
>
> We’re at a loss here, what could cause this behavior, and how can we fix
> it?
>
>
>
>
>
> *Best regards*
>
>
>
> *Johan Andersson*
>
> *Development Engineer*
>
> *Global Platforms Cloud Team*
>
>
>
> HMS Industrial Networks AB
>
> Stationsgatan 37, Box 4126
>
> 300 04 Halmstad, Sweden
>
>
>
> Email: j...@hms-networks.com
>
>
>
>
>
> HALMSTAD | BARCELONA |  BEIJING | BOSTON | BUCHEN | CHICAGO | COVENTRY |
> DEN BOSCH | DUBAI | IGUALADA |
>
> KARLSRUHE | MILAN | MULHOUSE | NIVELLES | PUNE | RAVENSBURG | SEOUL |
> SINGAPORE | TOKYO | WETZLAR
>
>
>

Re: SSL session resumption

[Lukas Tribus]

Hello Johan,


we are gonna need the outputs of "haproxy -vv" from both situations,
as well as at the very least *all* the ssl configuration parameters in
haproxy that you are using.

However, I do not believe it is likely that we can find the root
cause, without access to those handshakes, since it cannot be
reproduced by openssl s_client.


What definitely changed in haproxy 2.2 is that the default minimum TLS
version is now 1.2. To rollback to TLS 1.0 you can configure:

global
 ssl-default-bind-options ssl-min-ver TLSv1.0



Regards,

Lukas



On Wed, 3 Feb 2021 at 13:36, Johan Andersson  wrote:
>
> To whom it may concern
>
>
>
> We have recently upgraded out HAProxy version from 2.1.3 to 2.2.4.
>
> After the upgrade we got customer complaints that the data usage of their 
> devices had gone up. Our company sells proprietary hardware that logs data 
> and sends that to a web service which we host. These devices are often 
> deployed remotely and connected via shaky 3G connections with data-capped SIM 
> cards, so low data usage is very important.
>
> After some digging with Wireshark, we found that the SSL sessions are not 
> resumed. Instead a new handshake is initiated every time the device sends 
> data. Which is typically once an hour.
>
> We have set the global tune.ssl.lifetime parameter to 24h and the 
> tune.ssl.cachesize to 10 and this has worked since HAProxy version 1.6.9 
> when we first introduced it.
>
> We have also tested with the latest 2.1.11 release of HAProxy and it behaves 
> the same way as the 2.1.3 version. We have also tested with 2.2.0 and 2.2.8 
> and they behave the same as 2.2.4.
>
>
>
> We have tried reproducing this with openssl s_client, saving the session id 
> between requests but can’t reproduce it that way.
>
> We have also pored over the change logs between versions to see if there is 
> some change that could make HAProxy behave this way.
>
>
>
> We’re at a loss here, what could cause this behavior, and how can we fix it?
>
>
>
>
>
> Best regards
>
>
>
> Johan Andersson
>
> Development Engineer
>
> Global Platforms Cloud Team
>
>
>
> HMS Industrial Networks AB
>
> Stationsgatan 37, Box 4126
>
> 300 04 Halmstad, Sweden
>
>
>
> Email: j...@hms-networks.com
>
>
>
>
>
> HALMSTAD | BARCELONA |  BEIJING | BOSTON | BUCHEN | CHICAGO | COVENTRY | DEN 
> BOSCH | DUBAI | IGUALADA |
>
> KARLSRUHE | MILAN | MULHOUSE | NIVELLES | PUNE | RAVENSBURG | SEOUL | 
> SINGAPORE | TOKYO | WETZLAR
>
>

SSL session resumption

[Johan Andersson]

To whom it may concern

We have recently upgraded out HAProxy version from 2.1.3 to 2.2.4.
After the upgrade we got customer complaints that the data usage of their 
devices had gone up. Our company sells proprietary hardware that logs data and 
sends that to a web service which we host. These devices are often deployed 
remotely and connected via shaky 3G connections with data-capped SIM cards, so 
low data usage is very important.
After some digging with Wireshark, we found that the SSL sessions are not 
resumed. Instead a new handshake is initiated every time the device sends data. 
Which is typically once an hour.
We have set the global tune.ssl.lifetime parameter to 24h and the 
tune.ssl.cachesize to 10 and this has worked since HAProxy version 1.6.9 
when we first introduced it.
We have also tested with the latest 2.1.11 release of HAProxy and it behaves 
the same way as the 2.1.3 version. We have also tested with 2.2.0 and 2.2.8 and 
they behave the same as 2.2.4.

We have tried reproducing this with openssl s_client, saving the session id 
between requests but can't reproduce it that way.
We have also pored over the change logs between versions to see if there is 
some change that could make HAProxy behave this way.

We're at a loss here, what could cause this behavior, and how can we fix it?


Best regards

Johan Andersson
Development Engineer
Global Platforms Cloud Team

HMS Industrial Networks AB
Stationsgatan 37, Box 4126
300 04 Halmstad, Sweden

Email: j...@hms-networks.com

[cid:image001.png@01D6FA2D.98D58250]

HALMSTAD | BARCELONA |  BEIJING | BOSTON | BUCHEN | CHICAGO | COVENTRY | DEN 
BOSCH | DUBAI | IGUALADA |
KARLSRUHE | MILAN | MULHOUSE | NIVELLES | PUNE | RAVENSBURG | SEOUL | SINGAPORE 
| TOKYO | WETZLAR

Re: [PATCH v2 0/5] fix check port/addr consistency

[William Dauchy]

On Wed, Feb 3, 2021 at 9:59 AM Christopher Faulet  wrote:
> At first glance, I'm just a bit annoyed with the patch 5. In the 
> documentation,
> it is stated that "addr" option will be used for agent-check too. And there is
> no info about interactions between "addr" and "agent-addr" options when both 
> are
> configured. For me, for an agent-check, the "agent-addr" option must be used 
> in
> priority, regardless the options order. If not defined, the "addr" option must
> be used, if defined. And at the end, we use the server address by default if
> none is specified.

ok I missed that part. it is a bit sad honestly, it makes things less explicit.

> There is another problem with "port" and "agent-port" options. It is mentioned
> in the documentation that "agent-port" is required to perform agent-checks. 
> And
> "port" option is not used for agent-check. It is not really consistent. I
> propose to deal with port/agent-port options in the same way than
> addr/agent-addr ones. And we keep the test to be sure to have a dedicated port
> for the agent-check to not use the server's one. This way, we keep backward
> compatibility and improve consistency.
> Thus, if you agree with these changes, I guess we should keep SRV_F_AGENTADDR
> flag and add SRV_F_AGENTPORT.

ok I will come back with a v3. I honestly don't like to have port/addr
used for agent, as stated previously because it is creating some non
explicit things. But indeed as we need to keep backward compat, I will
fix that.

> About the CLI. I agree, the "check-addr" parameter on the "set server" command
> must be added. And the "agent-port" parameter must bee added too. For me, it 
> is
> a consistency matter. But I understand it is also mandatory for dynamic
> environments.

thanks, let me come back with a v3, so we can move forward for the
next improvements.
-- 
William

Re: Packaging hatop for ubuntu20.04

[Vincent Bernat]

 ❦  3 février 2021 10:23 GMT, Louis Charreau:

> we use hatop daily to monitor in real time haproxy.
> This tool is no longer packaged in ubuntu 20.04 (LTS), which is a pity for 
> such a useful tool.
>
> It's true that the initial project doesn't seem to be maintained
> anymore (last commit 5 years ago) and only works in Python2 which is
> itself deprecated: feurix/hatop (https://github.com/feurix/hatop).
>
> We referred to the jhunt/hatop project
> (https://github.com/jhunt/hatop), which is compatible with Python2 and
> 3. And we integrated it into our private repositories.
>
> Do you think it would be possible and useful for others to reintegrate
> hatop into the official Debian / Ubuntu repositories?

It's already the case:

https://tracker.debian.org/news/1226222/accepted-hatop-080-1-source-all-into-unstable-unstable/
-- 
Write clearly - don't be too clever.
- The Elements of Programming Style (Kernighan & Plauger)

Packaging hatop for ubuntu20.04

[Louis Charreau]

Hello,

we use hatop daily to monitor in real time haproxy.
This tool is no longer packaged in ubuntu 20.04 (LTS), which is a pity for such 
a useful tool.

It's true that the initial project doesn't seem to be maintained anymore (last 
commit 5 years ago) and only works in Python2 which is itself deprecated: 
feurix/hatop (https://github.com/feurix/hatop).

We referred to the jhunt/hatop project (https://github.com/jhunt/hatop), which 
is compatible with Python2 and 3. And we integrated it into our private 
repositories.

Do you think it would be possible and useful for others to reintegrate hatop 
into the official Debian / Ubuntu repositories?

Hoping that this suggestion will generate interest even if it is not directly 
related to haproxy.

Thank you.

Best regards.

Louis

Re: [PATCH v2 0/5] fix check port/addr consistency

[Christopher Faulet]

Le 02/02/2021 à 22:56, William Dauchy a écrit :

Hello Christopher,

As discussed, I revisited my previous series regarding check addr and
port consistency. I don't think I missed anything.

I won't hide my aim here, I would like to add support to set
`check.addr` on the cli like it is possible for the service port. More
and more people have a setup with containers having their own IP, but
with a health check on the host (e.g. on the consul side for example).
So it becomes more and more needed.

That's mostly why I wanted to clarify the situation first with the
different things I've seen while revisting this part of the code.



Thanks William, I will review the series soon.

At first glance, I'm just a bit annoyed with the patch 5. In the documentation, 
it is stated that "addr" option will be used for agent-check too. And there is 
no info about interactions between "addr" and "agent-addr" options when both are 
configured. For me, for an agent-check, the "agent-addr" option must be used in 
priority, regardless the options order. If not defined, the "addr" option must 
be used, if defined. And at the end, we use the server address by default if 
none is specified.


There is another problem with "port" and "agent-port" options. It is mentioned 
in the documentation that "agent-port" is required to perform agent-checks. And 
"port" option is not used for agent-check. It is not really consistent. I 
propose to deal with port/agent-port options in the same way than 
addr/agent-addr ones. And we keep the test to be sure to have a dedicated port 
for the agent-check to not use the server's one. This way, we keep backward 
compatibility and improve consistency.


Thus, if you agree with these changes, I guess we should keep SRV_F_AGENTADDR 
flag and add SRV_F_AGENTPORT.


About the CLI. I agree, the "check-addr" parameter on the "set server" command 
must be added. And the "agent-port" parameter must bee added too. For me, it is 
a consistency matter. But I understand it is also mandatory for dynamic 
environments.


Once that said, I don't really know how all of this is interacting with the 
servers state file. I don't really how this part works, so I may missed something.


--
Christopher Faulet