Hi Lukas, Provided patch we tried and that didn’t help.
-Roobesh G M -----Original Message----- From: Mohandass, Roobesh Sent: Wednesday, December 26, 2018 6:45 PM To: lu...@ltri.eu Cc: haproxy <haproxy@formilux.org> Subject: RE: Send-proxy not modifying some traffic with proxy ip/port details instead retaining same client ip port Hello Lukas, Sure, we will try the attached patch work and share the feedback to you/team. Thanks for help. Kind regards, Roobesh G M -----Original Message----- From: lu...@ltri.eu <lu...@ltri.eu> Sent: Wednesday, December 26, 2018 6:30 PM To: Mohandass, Roobesh <roobesh_mohand...@mcafee.com> Cc: haproxy <haproxy@formilux.org> Subject: Re: Send-proxy not modifying some traffic with proxy ip/port details instead retaining same client ip port This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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
1.8-SO_ORIGINAL_DST-change.diff
Description: 1.8-SO_ORIGINAL_DST-change.diff
