Hello Roobesh, On Wed, 26 Dec 2018 at 08:31, Mohandass, Roobesh <[email protected]> wrote: > > Hello, > > > > We are using haproxy version 1.8.14-1 in a docker container running ubuntu > 14.04 / kernel: 4.15.0-39-generic (Base host where container is running 18.04 > / kernel 4.15.0-39-generic) > > getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is in fact sometimes > returning the source IP instead the destination IP. > > Using getsockname() instead looks like solving the issue. > > > > https://stackoverflow.com/questions/11417187/getsockopt-so-original-dst-occasionally-returns-client-address > > For example: Out of 6569124 requests , 4 requests were wrong 0.000060891 % > > > > Can we file this as bug ? Get the fixed version in next release ? > > Also getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is used only for > send-proxy feature (for connected proxy IP) or any other feature in haproxy > also using this ?
For the record, the initial thread with you is on discourse: https://discourse.haproxy.org/t/send-proxy-not-modifying-some-traffic-with-proxy-ip-port-details/3336 Martin Zielinski mentioned the hint that SO_ORIGINAL_DST sometimes fails and omitting that call (returning the result of getsockname()) works around the issue. You confirmed this by compiling with USE_TPROXY= which disables the code path in question (SO_ORIGINAL_DST). SO_ORIGINAL_DST is certainly a feature that is required when haproxy binds to redirected sockets, otherwise we don't know the correct destination IP, so I don't think we can simply drop the call. Looking some further in into the root cause is what is required to get a better understanding of this. What I would ask you is to clarify how this can be reproduced? Do you only see this in production, or can you reproduce this also in a lab? If so, how do you reproduce it? Thanks, Lukas
