Re: Issues with haproxy 1.5-dev6 2011/04/08 and tproxy Cannot bind to tproxy source address before connect()

From: Willy Tarreau <w#1wt.eu>
Date: Tue, 19 Apr 2011 07:16:15 +0200


On Mon, Apr 18, 2011 at 03:29:43PM +0100, Nick Chalk wrote:
> On 18 April 2011 14:39, Mark Brooks <mark#loadbalancer.org> wrote:
> > We were having problems using transparent proxy and haproxy and
> > 1.5-dev6 2011/04/08, where haproxy would not work with tproxy enabled.
> ...
> > We were able to get it working in 1.5-dev6 by reversing the change
> > made from dev5 to dev6 below is the patch -
> >
> > --- proto_tcp.c-dev6    2011-04-18 14:05:38.000000000 +0100
> > +++ proto_tcp.c 2011-04-18 14:12:31.000000000 +0100
> > @@ -150,7 +150,7 @@
> >
> >        setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, (char *) &one, sizeof(one));
> >        if (foreign_ok) {
> > -               ret = bind(fd, (struct sockaddr *)&bind_addr, get_addr_len(&bind_addr));
> > +               ret = bind(fd, (struct sockaddr *)&bind_addr, sizeof(bind_addr));
> >                if (ret < 0)
> >                        return 2;
> >        }
>
> It appears that bind_addr.ss_family is not being set in
> tcp_bind_socket() before the call to get_addr_len(&bind_addr).
>
> The following allows the use of get_addr_len():
>
>
> --- proto_tcp.c-dev6 2011-04-18 14:05:38.000000000 +0100
> +++ proto_tcp.c 2011-04-18 15:23:41.000000000 +0100
> @@ -138,12 +138,14 @@
> ((struct sockaddr_in
> *)&bind_addr)->sin_addr = ((struct sockaddr_in *)remote)->sin_addr;
> if (flags & 2)
> ((struct sockaddr_in
> *)&bind_addr)->sin_port = ((struct sockaddr_in *)remote)->sin_port;
> + bind_addr.ss_family = AF_INET;
> break;
> case AF_INET6:
> if (flags & 1)
> ((struct sockaddr_in6
> *)&bind_addr)->sin6_addr = ((struct sockaddr_in6 *)remote)->sin6_addr;
> if (flags & 2)
> ((struct sockaddr_in6
> *)&bind_addr)->sin6_port = ((struct sockaddr_in6 *)remote)->sin6_port;
> + bind_addr.ss_family = AF_INET6;
> break;
> }
> }

Thank you guys, indeed this change makes a lot of sense, I did not know the family was not set. It's possible that other places are affected too, though the most common ones appear OK. I'll merge your patch.

Cheers,
Willy Received on 2011/04/19 07:16

This archive was generated by hypermail 2.2.0 : 2011/04/19 07:30 CEST