Re: [PR] fix show-sess-to-flags.sh cob fd state

[Willy Tarreau]

Hi!

On Tue, May 07, 2024 at 02:23:02AM +, PR Bot wrote:
> Author: zhibin.zhu 
> Number of patches: 1
> 
> This is an automated relay of the Github pull request:
>fix show-sess-to-flags.sh cob fd state
(...)

> From 95be08c6f4f382ec1b0e34765d4c1f09ddcdebb6 Mon Sep 17 00:00:00 2001
> From: "zhibin.zhu" 
> Date: Wed, 1 May 2024 18:51:26 +0800
> Subject: [PATCH] fix show-sess-to-flags.sh cob fd state
> 
> ---
>  dev/flags/show-sess-to-flags.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/dev/flags/show-sess-to-flags.sh b/dev/flags/show-sess-to-flags.sh
> index 79003a4f25d8..b352709f3a39 100755
> --- a/dev/flags/show-sess-to-flags.sh
> +++ b/dev/flags/show-sess-to-flags.sh
> @@ -195,7 +195,7 @@ while read -r; do
>  ! [[ "$REPLY" =~ [[:blank:]]h2c.*\.flg=([0-9a-fx]*) ]] || 
> append_flag b.h2c.flg   h2c  "${BASH_REMATCH[1]}"
>  elif [ $ctx = cob ]; then
>  ! [[ "$REPLY" =~ [[:blank:]]flags=([0-9a-fx]*) ]]  || 
> append_flag b.co.flgconn "${BASH_REMATCH[1]}"
> -! [[ "$REPLY" =~ [[:blank:]]fd.state=([0-9a-fx]*) ]]   || 
> append_flag b.co.fd.st  fd   "${BASH_REMATCH[1]}"
> +! [[ "$REPLY" =~ [[:blank:]]fd.state=([0-9a-fx]*) ]]   || 
> append_flag b.co.fd.st  fd   0x"${BASH_REMATCH[1]#0x}"
>  elif [ $ctx = res ]; then
>  ! [[ "$REPLY" =~ [[:blank:]]\(f=([0-9a-fx]*) ]]|| 
> append_flag res.flg chn  "${BASH_REMATCH[1]}"
>  ! [[ "$REPLY" =~ [[:blank:]]an=([0-9a-fx]*) ]] || 
> append_flag res.ana ana  "${BASH_REMATCH[1]}"

Hmm why, what is the problem it tries to solve ? Maybe we don't always
emit the 0x on the output ? Please try to provide a bit of info that
can be added to the commit message.

Thanks!
Willy

[PR] fix show-sess-to-flags.sh cob fd state

[PR Bot]

Dear list!

Author: zhibin.zhu 
Number of patches: 1

This is an automated relay of the Github pull request:
   fix show-sess-to-flags.sh cob fd state

Patch title(s): 
   fix show-sess-to-flags.sh cob fd state

Link:
   https://github.com/haproxy/haproxy/pull/2560

Edit locally:
   wget https://github.com/haproxy/haproxy/pull/2560.patch && vi 2560.patch

Apply locally:
   curl https://github.com/haproxy/haproxy/pull/2560.patch | git am -

Description:
   PR to fix show-sess-to-flags.sh

Instructions:
   This github pull request will be closed automatically; patch should be
   reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is
   invited to comment, even the patch's author. Please keep the author and
   list CCed in replies. Please note that in absence of any response this
   pull request will be lost.

Re: Error While deviceatlas 3.2.2 and haproxy 2.9.6 make from source

[David CARLIER]

hi and sorry for the long reply.

I will let you know once it is officially release, it needs to pass our QA
test still.

Kind regards.

On Mon, 6 May 2024 at 22:52, Mahendra Patil 
wrote:

> any update when we can get  3.2.3 release
>
> On Wed, Apr 3, 2024 at 10:51 AM David CARLIER  wrote:
>
>> Hi all,
>>
>> Thanks for your report. This is a known issue the 3.2.3 release is
>> scheduled within this month.
>>
>> Regards.
>>
>> On Wed, 3 Apr 2024 at 04:38, Willy Tarreau  wrote:
>>
>>> Hello,
>>>
>>> On Wed, Apr 03, 2024 at 05:21:03AM +0530, Mahendra Patil wrote:
>>> > /opt/deviceatlas/Src//dac.c: In function ātoverdecā:
>>> > /opt/deviceatlas/Src//dac.c:714:13: warning: implicit declaration of
>>> > function ā__builtin_sadd_overflowā [-Wimplicit-function-declaration]
>>> >  if (DATLAS_A_OFLOW(cur * 10, decrm, )) {
>>> (...)
>>> > /opt/deviceatlas/Src//dac.o: In function `toverdec':
>>> > /opt/deviceatlas/Src//dac.c:714: undefined reference to
>>> > `__builtin_sadd_overflow'
>>> > collect2: error: ld returned 1 exit status
>>> > make: *** [haproxy] Error 1
>>>
>>> From what I'm seeing, __builtin_sadd_overflow() first appeared in gcc-5,
>>> so you don't have it on your system, which seems to be RHEL 7 or CentOS 7
>>> based on the compiler version (gcc 4.8.5).
>>>
>>> I don't know how important is the use of this builtin for Device Atlas,
>>> I'll let David check. As a hack you could verify that it builds when you
>>> change it to:
>>>
>>> if ((r = cur*10 + decrm), 0) {
>>>
>>> But be careful that removing this overflow check might introduce a
>>> vulnerability, so if this builds, please do not deploy such code without
>>> David's approval.
>>>
>>> Another approach could be to build gcc-5.5 on your distro. It's not that
>>> hard but might not be what you were expecting to do. There are various
>>> howtos on the net, such as here:
>>>
>>>   https://gist.github.com/tyleransom/2c96f53a828831567218eeb7edc2b1e7
>>>
>>> Though this one will replace the default compiler in your path, and you
>>> may likely want to add "--program-suffix=-5.5" to the configure (and
>>> replace 5.4 with 5.5 everywhere) so that you can then pass "CC=gcc-5.5"
>>> to haproxy's "make" command line.
>>>
>>> Hoping this helps,
>>> Willy
>>>
>>
>

Re: Error While deviceatlas 3.2.2 and haproxy 2.9.6 make from source

[Mahendra Patil]

any update when we can get  3.2.3 release

On Wed, Apr 3, 2024 at 10:51 AM David CARLIER  wrote:

> Hi all,
>
> Thanks for your report. This is a known issue the 3.2.3 release is
> scheduled within this month.
>
> Regards.
>
> On Wed, 3 Apr 2024 at 04:38, Willy Tarreau  wrote:
>
>> Hello,
>>
>> On Wed, Apr 03, 2024 at 05:21:03AM +0530, Mahendra Patil wrote:
>> > /opt/deviceatlas/Src//dac.c: In function ātoverdecā:
>> > /opt/deviceatlas/Src//dac.c:714:13: warning: implicit declaration of
>> > function ā__builtin_sadd_overflowā [-Wimplicit-function-declaration]
>> >  if (DATLAS_A_OFLOW(cur * 10, decrm, )) {
>> (...)
>> > /opt/deviceatlas/Src//dac.o: In function `toverdec':
>> > /opt/deviceatlas/Src//dac.c:714: undefined reference to
>> > `__builtin_sadd_overflow'
>> > collect2: error: ld returned 1 exit status
>> > make: *** [haproxy] Error 1
>>
>> From what I'm seeing, __builtin_sadd_overflow() first appeared in gcc-5,
>> so you don't have it on your system, which seems to be RHEL 7 or CentOS 7
>> based on the compiler version (gcc 4.8.5).
>>
>> I don't know how important is the use of this builtin for Device Atlas,
>> I'll let David check. As a hack you could verify that it builds when you
>> change it to:
>>
>> if ((r = cur*10 + decrm), 0) {
>>
>> But be careful that removing this overflow check might introduce a
>> vulnerability, so if this builds, please do not deploy such code without
>> David's approval.
>>
>> Another approach could be to build gcc-5.5 on your distro. It's not that
>> hard but might not be what you were expecting to do. There are various
>> howtos on the net, such as here:
>>
>>   https://gist.github.com/tyleransom/2c96f53a828831567218eeb7edc2b1e7
>>
>> Though this one will replace the default compiler in your path, and you
>> may likely want to add "--program-suffix=-5.5" to the configure (and
>> replace 5.4 with 5.5 everywhere) so that you can then pass "CC=gcc-5.5"
>> to haproxy's "make" command line.
>>
>> Hoping this helps,
>> Willy
>>
>

-- 

Re: some QUIC questions

[Björn Jacke]

On 06.05.24 15:34, Shawn Heisey wrote:

On 5/6/24 06:02, Björn Jacke wrote:

frontend ft_443
   bind :::443 ssl crt /ssl/combined.pem
   bind quic6@:443 ssl crt /ssl/combined.pem alpn h3
   option tcp-smart-accept
   http-after-response add-header alt-svc 'h3=":443"; ma=600; 
persistent=1'





frontend ft_quic_test
 mode tcp
 bind quic6@:443 ssl crt /ssl/combined.pem
 use_backend local_smb

this results in this config check error thoug:

[ALERT]    (3611777) : config : frontend 'ft_quic_test' : MUX protocol 
'quic' is not usable for 'bind quic6@:443' at [/etc/haproxy/ 
haproxy.cfg:73].


So a setup like this is not supported by HAProxy's QUIC implementation 
currently, right? Is QUIC in HAProxy HTTP3 only for now?\


The alpn on the first config snippet only includes h3, not quic.  Here 
are alpn and npn settings that allow some of the quic protocol 
variations as well as h3 itself:


for the http frontend sniplet h3 as only alpn protocol was intended. It 
turned out to be a firewall causing making haproxy "ignore" the incoming 
quic traffic, sorry for not finding that earlier.


Continuing the test with connection migration on network changes showed 
that connection migration is not working. I'm not sure though if none of 
the browsers do really support this or if this not being supported on 
the haproxy server side. Does any of the QUIC experts here have some 
insights on that?



The second one is a tcp frontend ... I feel pretty sure that h3/quic 
requires http in the frontend, not tcp.


but for any non-http protocol using QUIC as transport layer a http type 
frontend is obviously not the right choice.


So let me ask the question differently: is QUIC support in haproxy 
currently only targeting at http3 support or is generic QUIC transport 
also on the agenda? From the docs I can't find much about non-http 
related QUIC support.


Thank you
Björn

Re: some QUIC questions

[Shawn Heisey]

On 5/6/24 06:02, Björn Jacke wrote:

frontend ft_443
   bind :::443 ssl crt /ssl/combined.pem
   bind quic6@:443 ssl crt /ssl/combined.pem alpn h3
   option tcp-smart-accept
   http-after-response add-header alt-svc 'h3=":443"; ma=600; persistent=1'





frontend ft_quic_test
     mode tcp
     bind quic6@:443 ssl crt /ssl/combined.pem
     use_backend local_smb

this results in this config check error thoug:

[ALERT]    (3611777) : config : frontend 'ft_quic_test' : MUX protocol 
'quic' is not usable for 'bind quic6@:443' at [/etc/haproxy/ 
haproxy.cfg:73].


So a setup like this is not supported by HAProxy's QUIC implementation 
currently, right? Is QUIC in HAProxy HTTP3 only for now?\


The alpn on the first config snippet only includes h3, not quic.  Here 
are alpn and npn settings that allow some of the quic protocol 
variations as well as h3 itself:


alpn h3,h3-29,h3-28,h3-27 npn h3,h3-29,h3-28,h3-27

The second one is a tcp frontend ... I feel pretty sure that h3/quic 
requires http in the frontend, not tcp.


Thanks,
Shawn

Meeting with LML Studios

[M Sami Kerrouche]

Hi,

I am waiting for you on our call that you booked.

Let me know if you'd like to reschedule.

Here's my phone number, call me for a quicker response.

+44 7577 295184

Best wishes,

*Sami Kerrouche*
Managing Director

London Media Lounge Ltd
16a/17a Windsor St
Uxbridge
Middx
UB8 1AB
www.LondonMediaLounge.co.uk 
https://www.linkedin.com/in/msamikerrouche/

Re: [PATCH] FEATURE: Adding MPTCP with option to disable it and fall-back to TCP

[Björn Jacke]

Hi,

I came up a while ago with a patchset for MPTCP support for HAProxy 
also, see https://github.com/haproxy/haproxy/issues/1028


Back then I also discussed some ideas with Willy how to implement it 
more elegantly in HAProxy. It's still somewhere on my todo list but 
unfortunately I didn't catch that up since then. As I had a good 
real-world usecase recently for MPTCP I though of looking into this 
again also.


Björn

On 25.04.24 00:12, Willy Tarreau wrote:

Hi!

On Wed, Apr 24, 2024 at 05:45:03PM +0200, Nicolas CARPi wrote:

Hello,

On 24 Apr, Dorian Craps wrote:

This attached patch uses MPTCP by default instead of TCP on Linux.

The backward compatibility of MPTCP is indeed a good point toward
enabling it by default. Nonetheless, I feel your message should include
a discussion on the security implications of this change.

As you know, v0 had security issues. v1 addresses them, and we can
likely consider that new attacks targeting this protocol will pop up as
it becomes widespread.

In fact, that's already the case:

See: CVE-2024-26708: mptcp: really cope with fastopen race
or CVE-2024-26826: mptcp: fix data re-injection from stale subflow
or CVE-2024-26782 kernel: mptcp: fix double-free on socket dismantle

The three CVEs above are all from April 2024.

Given that MPTCP v1 is relatively new (2020), and that we do not have
real assurances that it is at least as secure as plain TCP, I would
humbly suggest inverting the logic, and making it an opt-in option.

This way, a vulnerability impacting MPTCP would only impact users that
enabled it, instead of 100% of HAProxy users. In a few years, making it
the default could be reconsidered.

Please note that I'm simply voicing my concern as a user, and the core
dev team might have a very different view about these aspects.


It sounds good to have MPTCP enabled by default

Except when looking at it through the prism of the increased attack
surface! ;)


IPPROTO_MPTCP is defined just in case old libC are being used and
don't have the ref.

Shouldn't it be defined with a value, as per
https://www.mptcp.dev/faq.html#why-is-ipproto_mptcp-not-defined ?
(sorry if it's a dumb remark, I'm not a C dev)


Without going into all the details and comments above, I just want to
say that I'll study this after 3.0 is released, since there's still a
massive amount of stuff to adjust for the release and we're way past
a feature freeze. I *am* interested in the feature, which has been
floating around for a few years already. However I tend to agree with
Nicolas that, at least for the principle of least surprise, I'd rather
not have this turned on by default. There might even be security
implications that some are not willing to take yet, and forcing them
to guess that they need to opt out of something is not great in general
(it might change in the future though, once everyone turns it on by
default, like we did for keep-alive, threads, and h2 for example).

I'm also concerned by the change at the socket layer that will make all
new sockets cause two syscalls on systems where this is not enabled,
and I'd really really prefer that we use the extended syntax for
addresses that offers a lot of flexibility. We can definitely have
"mptcp@address" and probably mptcp as a variant of tcp. Regarding how
we'd deal with the fallback, we'll see, but overall, thinking that
someone would explicitly configure mptcp and not even get an error if
it cannot bind is problematic to me, because among the most common
causes of trouble are things that everyone ignores (module not loaded,
missing secondary IP, firewall rules etc) that usually cause problems.
Those we can discover at boot time should definitely be reported. But
let's discuss this in early June instead (I mean, feel free to discuss
the points together, but I'm not going to invest more time on this at
this moment).

Thanks!
Willy

some QUIC questions

[Björn Jacke]

Hi,

now that HAProxy 2.9  from haproxy.debian.net is usabel with QUIC if you 
(with limited-quic), I finylly gave it a try. I set extended my http 
frontend accordingly like this:


frontend ft_443
  bind :::443 ssl crt /ssl/combined.pem
  bind quic6@:443 ssl crt /ssl/combined.pem alpn h3
  option tcp-smart-accept
  http-after-response add-header alt-svc 'h3=":443"; ma=600; persistent=1'

This is on current Debian bookwork with HAProxy 2.9.7 from 
haproxy.debian.net and openssl 3.0.11 from Debian.


http3 was working successfully in first tests.

Later on I wanted to test if QUIC connection migration (switching 
network conenctions without breaking the established QUIC conncection) 
is working properly. This didn't work for me so I stated up tcpdump on 
the server. What I saw was explaining why connection migration could not 
work. The HAProxy box was receiving initial QUIC packages on port 443 
but it was not replying them in any way. From tcpdump's output I could 
see that some other hosts had obviously been successfully connected via 
QUIC though. The ignored QUIC requests also don't pop up in haproxy's log.


Has anybody seen similar problems? I'm also not sure if this is a 
problem related to HAProxy or openssl here? I suspect HAProxy?



Another thing that I wanted to give a try is see if haproxy could be 
used as a helper to implement SMB over QUIC. The straght forward idea 
would be to set up a tcp frontend with a QUIC listener and a backend 
routing the tcp traffic to a Samba server:


frontend ft_quic_test
mode tcp
bind quic6@:443 ssl crt /ssl/combined.pem
use_backend local_smb

this results in this config check error thoug:

[ALERT](3611777) : config : frontend 'ft_quic_test' : MUX protocol 
'quic' is not usable for 'bind quic6@:443' at [/etc/haproxy/haproxy.cfg:73].


So a setup like this is not supported by HAProxy's QUIC implementation 
currently, right? Is QUIC in HAProxy HTTP3 only for now?


Cheers
Björn

postfix with postscreen behind haproxy

[Rainer Duffner]

Hi,

I am running (trying to, really) postfix with postscreen (really Zimbra) behind 
haproxy.

I enabled proxy protocol support in Zimbra 

08:27:26 (TEST) zimbra@zcs-fe5 [~] $ postconf |grep haproxy
postscreen_upstream_proxy_protocol = haproxy

08:26:47 (TEST) zimbra@zcs-fe6 [~] $ postconf  |grep haproxy
postscreen_upstream_proxy_protocol = haproxy


and have the following backend configuration in haproxy:

backend smtp-zimbra-backend
  balance roundrobin
  mode tcp
  timeout server 1m
  timeout connect 10s
  option smtpchk EHLO lb.server.bla
  #option smtpchk 
  server pm01 192.168.185.206:25 check send-proxy inter 45s fastinter 2s 
downinter 2s 
  server pm02 192.168.185.207:25 check send-proxy inter 45s fastinter 2s 
downinter 2s 



However, this yields a „Layer 7 invalid response: „200-lb.server.bla“

From this article, I deduce that one cannot use smtpcheck with postscreen?

https://www.linuxbabe.com/mail-server/smtp-imap-proxy-with-haproxy-debian-ubuntu-centos
Set Up SMTP and IMAP Proxy with HAProxy (Debian, Ubuntu, CentOS)
linuxbabe.com


Does anybody have some experience with this?

I would really prefer to have „smtpcheck“ to have some sort of health check to 
remove non-working backends from the pool…




Rainer

Re: [PATCH 1/3] BUILD: illumos: pthread_getcpuclockid is not available

[Willy Tarreau]

On Sun, May 05, 2024 at 01:43:33PM +0200,  ??? wrote:
> updated patches.

Cool, thanks, now applied.

> I'll address reorg to "compat.h" a bit later, once it is settled in my head

No worries, I've seen your other comment about the need to include
pthread.h, and this alone would be a good reason for leaving the test
where it is for now.

Willy