On 5/7/2022 9:11 AM, Shawn Heisey wrote:
A couple of days ago I noticed that quictls had made a 3.0.3 version available. I upgraded and then tried to rebuild haproxy (master branch). The compile failed. Don't they know they shouldn't change API in a point release? (It's not even a good idea in a minor release unless there is backward compatibility)
Doing a git pull today on both quictls and haproxy before rebuilding has fixed this problem. It looks like the haproxy pull didn't update any quic code, so I'm betting the quictls team didn't mean to break things and have now fixed it. They don't seem to have any actual releases yet, so maybe I shouldn't be expecting stability from them.
If you look closely at the tcpdump output, you'll notice that when haproxy replies, it replies from the actual IP address of the machine (.200) rather than the ucarp VIP (.170) where it received the request. Is this something that can be fixed?
Is it haproxy or quictls that is handling the udp/443 packets? I think that for tcp/443 it is haproxy handling the tcp connection, and it would be my guess that haproxy also does this for udp/443, but I do not know that for sure. I know that much of TCP is actually handled by the OS, but apps CAN get very involved if they want to. I have not dived into haproxy source to the level required to answer these questions.
Thanks, Shawn
