Hello Roobesh,

On Wed, 26 Dec 2018 at 11:49, Mohandass, Roobesh
<roobesh_mohand...@mcafee.com> wrote:
> RGM: This is reproducible anywhere production/lab but when we see this 
> behavior is a questions
> as I said out of so many large number of requests only for some we will 
> observe this behavior
> (but can be caught very quickly in less than 30mins span of time).

Thanks for clarifying.

I don't have the time to reproduce this today, but could you try the
attached patch please?

It changes the logic around those calls, uses the
getsockopt/SO_ORIGINAL_DST first, checks the return value and then
calls getsockname(). Previously we did not check the return value of
the getsockopt/SO_ORIGINAL_DST. My hope is that that call returns an
error when it returns wrong data - if that's the case, the patch
should fix the issue without sacrificing other haproxy features.

If that doesn't fix the problem we probably have to talk to the
kernel/netfilter folks.


Thanks,
Lukas

Attachment: 1.8-SO_ORIGINAL_DST-change.diff
Description: Binary data

Reply via email to