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

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

Reply via email to