Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Cyril Bonté]

Le 02/07/2016 à 23:22, Hoggins! a écrit :

Thanks Cyril.

I discovered the answer while you were writing yours. Sorry for the noise.


If you plan to upgrade to 1.6.6, be aware of a regression which may hurt 
you.

Willy has already reverted the commit on the master branch :
http://www.haproxy.org/git?p=haproxy-1.6.git;a=commit;h=2706accd32d05b6be21ae134706aae5468a2bf5d




Hoggins!

Le 02/07/2016 22:48, Cyril Bonté a écrit :

Le 02/07/2016 à 22:45, Hoggins! a écrit :

Oh my !

It's just happening to me on Fedora 24 with version
haproxy-1.6.5-3.fc24.x86_64 !

Well, I have a huge problem since I just upgraded and the mess is all
around, listening on all ports and all IPv4 addresses.

Can you summarize what I should do ? Recompile with which options ?


Upgrade to 1.6.6 :
http://www.haproxy.org/git?p=haproxy-1.6.git;a=commit;h=66dd99c4c9d828c2c2f7295b7db66f7ff6f2fa8e


(or recompile without gcc6)






--
Cyril Bonté

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Hoggins!]

Thanks Cyril.

I discovered the answer while you were writing yours. Sorry for the noise.

Hoggins!

Le 02/07/2016 22:48, Cyril Bonté a écrit :
> Le 02/07/2016 à 22:45, Hoggins! a écrit :
>> Oh my !
>>
>> It's just happening to me on Fedora 24 with version
>> haproxy-1.6.5-3.fc24.x86_64 !
>>
>> Well, I have a huge problem since I just upgraded and the mess is all
>> around, listening on all ports and all IPv4 addresses.
>>
>> Can you summarize what I should do ? Recompile with which options ?
>
> Upgrade to 1.6.6 :
> http://www.haproxy.org/git?p=haproxy-1.6.git;a=commit;h=66dd99c4c9d828c2c2f7295b7db66f7ff6f2fa8e
>
>
> (or recompile without gcc6) 




signature.asc
Description: OpenPGP digital signature

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Cyril Bonté]

Le 02/07/2016 à 22:45, Hoggins! a écrit :

Oh my !

It's just happening to me on Fedora 24 with version
haproxy-1.6.5-3.fc24.x86_64 !

Well, I have a huge problem since I just upgraded and the mess is all
around, listening on all ports and all IPv4 addresses.

Can you summarize what I should do ? Recompile with which options ?


Upgrade to 1.6.6 :
http://www.haproxy.org/git?p=haproxy-1.6.git;a=commit;h=66dd99c4c9d828c2c2f7295b7db66f7ff6f2fa8e

(or recompile without gcc6)


--
Cyril Bonté

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Hoggins!]

Oh my !

It's just happening to me on Fedora 24 with version
haproxy-1.6.5-3.fc24.x86_64 !

Well, I have a huge problem since I just upgraded and the mess is all
around, listening on all ports and all IPv4 addresses.

Can you summarize what I should do ? Recompile with which options ?

Thanks !

Hoggins!

Le 18/05/2016 10:30, Willy Tarreau a écrit :
> Hi Vincent,
>
> On Wed, May 18, 2016 at 09:58:33AM +0200, Vincent Bernat wrote:
>>  ??? 15 mai 2016 09:55 +0200, Vincent Bernat  :
>>
 I suppose that some new features of gcc started to rely on the
 strict-aliasing rule without taking -fno-strict-aliasing into
 consideration. I didn't find anything in the bugzilla, but it's easy to
 miss something as there are about 500 bugs opened about aliasing.

 I'll open a bug about this.
>>> Here is the bug:
>>>  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71120
>>>
>>> With luck, we should get some pointers on why and how.
>> So, it appears this is not a bug in GCC and it is not an aliasing
>> problem but the fact that the compiler doesn't have to use memcpy() to
>> copy the struct, but can copy individual member, padding excluded.
> Yes, this is even a security problem which painfully affects the kernel.
>
>> And sin_addr would be in the padding, so not copied.
> That makes sense then.
>
>> A bug has been filed
>> for the glibc since the bug is in the definition:
>>
>>  https://sourceware.org/bugzilla/show_bug.cgi?id=20111
> Great, thanks for the link and going through this. As was mentionned
> there, sockaddr_storage is expected by users and in literature to be
> able to carry other addresses.
>
>> We could either use an union like discussed previously or locally fix
>> this with a memcpy(). I suppose the union would be a longer term (and
>> safer since we can be exhaustive about it) fix but far more invasive.
> I have the same feeling, but it would make a few switch/case occurences
> cleaner or at least more explicit. For the short term and backports I
> guess only memcpy() will be usable, so we should probably start by this,
> backport it, then work on changing all this to a union.
>
>> I suspect there are other uses of sockaddr_storage that could lead to
>> some bugs.
> If there is one, there are many.
>
>> For example, connection.c:747. ss_family will be set to 0,
>> but eventual port and address can be random. However, it seems that in
>> the remaining of the code, only ss_family is important. But maybe, it
>> would be better to use memset() here.
> Good point.
>
> Maybe we would need to develop a few macros (or inline functions) to
> manipulate sockaddr_storage. We already have a few, I don't think we
> need that many. set_port, set_addr, set_family, copy_addr and I don't
> know what.
>
>> On the other hand, on proto_tcp.c:225, bind_addr is correctly zeroed out
>> with memset. Same on standard.c:829.
>>
>> I also note on proto_http.c:3192, a "struct sockaddr_storage from" that
>> may be more safe to replace by "struct sockaddr_storage *from" since it
>> is used read-only. But maybe the compiler is smart enough to not do a
>> copy and therefore the bug is not triggered here.
> I didn't notice this one, good catch. It should even be a const.
>
>> I didn't review all uses, only uses of "struct sockaddr_storage
>> something". I should check for "struct sockaddr_storage *something" and
>> eventual use of "*something =", but I suspect that it doesn't exist
>> without a "struct sockaddr_storage something_else" around.
> I think that once we get rid of *all* sockaddr_storage we'll find them
> all :-)
>
>> So, quick fix is a memcpy() in cfgparse.c and in proto_http.c:3192 and
>> using memset() in connection.c:747 for consistency (so that somebody
>> doesn't copy this code for something more general).
>>
>> Can do the patches but union would be more work.
> That works for me. Let's have Arthur test them to confirm the issue goes
> away for him.
>
> Thanks!
> Willy
>
>




signature.asc
Description: OpenPGP digital signature

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Arthur Țițeică]

În ziua de miercuri, 18 mai 2016, la 10:30:56 EEST, Willy Tarreau a scris:
> That works for me. Let's have Arthur test them to confirm the issue goes
> away for him.

I'm glad to help.

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

Hi Vincent,

On Wed, May 18, 2016 at 09:58:33AM +0200, Vincent Bernat wrote:
>  ??? 15 mai 2016 09:55 +0200, Vincent Bernat  :
> 
> >> I suppose that some new features of gcc started to rely on the
> >> strict-aliasing rule without taking -fno-strict-aliasing into
> >> consideration. I didn't find anything in the bugzilla, but it's easy to
> >> miss something as there are about 500 bugs opened about aliasing.
> >>
> >> I'll open a bug about this.
> >
> > Here is the bug:
> >  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71120
> >
> > With luck, we should get some pointers on why and how.
> 
> So, it appears this is not a bug in GCC and it is not an aliasing
> problem but the fact that the compiler doesn't have to use memcpy() to
> copy the struct, but can copy individual member, padding excluded.

Yes, this is even a security problem which painfully affects the kernel.

> And sin_addr would be in the padding, so not copied.

That makes sense then.

> A bug has been filed
> for the glibc since the bug is in the definition:
> 
>  https://sourceware.org/bugzilla/show_bug.cgi?id=20111

Great, thanks for the link and going through this. As was mentionned
there, sockaddr_storage is expected by users and in literature to be
able to carry other addresses.

> We could either use an union like discussed previously or locally fix
> this with a memcpy(). I suppose the union would be a longer term (and
> safer since we can be exhaustive about it) fix but far more invasive.

I have the same feeling, but it would make a few switch/case occurences
cleaner or at least more explicit. For the short term and backports I
guess only memcpy() will be usable, so we should probably start by this,
backport it, then work on changing all this to a union.

> I suspect there are other uses of sockaddr_storage that could lead to
> some bugs.

If there is one, there are many.

> For example, connection.c:747. ss_family will be set to 0,
> but eventual port and address can be random. However, it seems that in
> the remaining of the code, only ss_family is important. But maybe, it
> would be better to use memset() here.

Good point.

Maybe we would need to develop a few macros (or inline functions) to
manipulate sockaddr_storage. We already have a few, I don't think we
need that many. set_port, set_addr, set_family, copy_addr and I don't
know what.

> On the other hand, on proto_tcp.c:225, bind_addr is correctly zeroed out
> with memset. Same on standard.c:829.
> 
> I also note on proto_http.c:3192, a "struct sockaddr_storage from" that
> may be more safe to replace by "struct sockaddr_storage *from" since it
> is used read-only. But maybe the compiler is smart enough to not do a
> copy and therefore the bug is not triggered here.

I didn't notice this one, good catch. It should even be a const.

> I didn't review all uses, only uses of "struct sockaddr_storage
> something". I should check for "struct sockaddr_storage *something" and
> eventual use of "*something =", but I suspect that it doesn't exist
> without a "struct sockaddr_storage something_else" around.

I think that once we get rid of *all* sockaddr_storage we'll find them
all :-)

> So, quick fix is a memcpy() in cfgparse.c and in proto_http.c:3192 and
> using memset() in connection.c:747 for consistency (so that somebody
> doesn't copy this code for something more general).
> 
> Can do the patches but union would be more work.

That works for me. Let's have Arthur test them to confirm the issue goes
away for him.

Thanks!
Willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Vincent Bernat]

 ❦ 15 mai 2016 09:55 +0200, Vincent Bernat  :

>> I suppose that some new features of gcc started to rely on the
>> strict-aliasing rule without taking -fno-strict-aliasing into
>> consideration. I didn't find anything in the bugzilla, but it's easy to
>> miss something as there are about 500 bugs opened about aliasing.
>>
>> I'll open a bug about this.
>
> Here is the bug:
>  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71120
>
> With luck, we should get some pointers on why and how.

So, it appears this is not a bug in GCC and it is not an aliasing
problem but the fact that the compiler doesn't have to use memcpy() to
copy the struct, but can copy individual member, padding excluded. And
sin_addr would be in the padding, so not copied. A bug has been filed
for the glibc since the bug is in the definition:

 https://sourceware.org/bugzilla/show_bug.cgi?id=20111

We could either use an union like discussed previously or locally fix
this with a memcpy(). I suppose the union would be a longer term (and
safer since we can be exhaustive about it) fix but far more invasive.

I suspect there are other uses of sockaddr_storage that could lead to
some bugs. For example, connection.c:747. ss_family will be set to 0,
but eventual port and address can be random. However, it seems that in
the remaining of the code, only ss_family is important. But maybe, it
would be better to use memset() here.

On the other hand, on proto_tcp.c:225, bind_addr is correctly zeroed out
with memset. Same on standard.c:829.

I also note on proto_http.c:3192, a "struct sockaddr_storage from" that
may be more safe to replace by "struct sockaddr_storage *from" since it
is used read-only. But maybe the compiler is smart enough to not do a
copy and therefore the bug is not triggered here.

I didn't review all uses, only uses of "struct sockaddr_storage
something". I should check for "struct sockaddr_storage *something" and
eventual use of "*something =", but I suspect that it doesn't exist
without a "struct sockaddr_storage something_else" around.

So, quick fix is a memcpy() in cfgparse.c and in proto_http.c:3192 and
using memset() in connection.c:747 for consistency (so that somebody
doesn't copy this code for something more general).

Can do the patches but union would be more work.
-- 
A light wife doth make a heavy husband.
-- Wm. Shakespeare, "The Merchant of Venice"

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Vincent Bernat]

 ❦ 15 mai 2016 09:45 +0200, Vincent Bernat  :

> I suppose that some new features of gcc started to rely on the
> strict-aliasing rule without taking -fno-strict-aliasing into
> consideration. I didn't find anything in the bugzilla, but it's easy to
> miss something as there are about 500 bugs opened about aliasing.
>
> I'll open a bug about this.

Here is the bug:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71120

With luck, we should get some pointers on why and how.
-- 
Modularise.  Use subroutines.
- The Elements of Programming Style (Kernighan & Plauger)

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Vincent Bernat]

 ❦ 15 mai 2016 09:19 +0200, Willy Tarreau  :

>> I think this is an aliasing problem. You cannot have two incompatible
>> variables pointing at the same memory spot. It seems that now
>> sockaddr_storage and sockaddr_in are not compatible anymore.
>
> Here it's not an aliasing problem in my opinion since we build with
> -fno-strict-aliasing for this reason. Also usually when gcc produces
> an unexpected behaviour we at least have a corresponding warning, here
> it simply produces bad code.

In the past, there was a warning and many projects switched to union to
solve this. At some point, the warning disappeared. I don't know if it
was a change in the glibc (for example, the use of "restrict" keyword)
or in gcc. In the bugzilla, there are many reports of this warning
feature not being effective because it's too hard to get it right.

I suppose that some new features of gcc started to rely on the
strict-aliasing rule without taking -fno-strict-aliasing into
consideration. I didn't find anything in the bugzilla, but it's easy to
miss something as there are about 500 bugs opened about aliasing.

I'll open a bug about this.

>> This works when used in place of "struct sockaddr_storage".
>
> This might be something we can switch to in the future to see if we can
> remove -fno-strict-aliasing (but for how long?). The emitted code is
> slightly better without it (less data reloads) and disabling aliasing
> for the whole code just to satisfy a few places is a bit annoying.

We can keep the -fno-strict-aliasing but use the union to be more future
proof. After all, it would result in less undefined behavior. Basically,
it would be to turn all "struct sockaddr" and "struct sockaddr_storage"
to "struct sockaddr_any" which would be an anonymous union of "struct
sockaddr, struct sockaddr_in, struct sockaddr_in6, struct
sockaddr_storage". This may breaks some old code as I tend to remember
that at some point, "struct sockaddr" was not a "concrete" type (no
known size). If that's really important, we could exclude it from the
union and never use "sa_family" but "ss_family".

>> I see the
>> glibc is using an union too instead of struct sockaddr or struct
>> sockaddr_storage. man 7 socket still says to use struct
>> sockaddr_storage.
>
> Yes it depends a lot on the syscalls in fact :-/

On my system, I am refering to this header file:
 /usr/include/x86_64-linux-gnu/sys/socket.h

#v+
extern int accept (int __fd, __SOCKADDR_ARG __addr,
   socklen_t *__restrict __addr_len);
#v-

And __SOCKADDR_ARG is the "universal" union.
-- 
O, it is excellent
To have a giant's strength; but it is tyrannous
To use it like a giant.
-- Shakespeare, "Measure for Measure", II, 2

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

Hi Vincent,

On Sat, May 14, 2016 at 07:08:12PM +0200, Vincent Bernat wrote:
> I think this is an aliasing problem. You cannot have two incompatible
> variables pointing at the same memory spot. It seems that now
> sockaddr_storage and sockaddr_in are not compatible anymore.

Here it's not an aliasing problem in my opinion since we build with
-fno-strict-aliasing for this reason. Also usually when gcc produces
an unexpected behaviour we at least have a corresponding warning, here
it simply produces bad code.

> #v+
> struct sockaddr_storage
>   {
> __SOCKADDR_COMMON (ss_);/* Address family, etc.  */
> __ss_aligntype __ss_align;  /* Force desired alignment.  */
> char __ss_padding[_SS_PADSIZE];
>   };
> 
> struct sockaddr_in
>   {
> __SOCKADDR_COMMON (sin_);
> in_port_t sin_port; /* Port number.  */
> struct in_addr sin_addr;/* Internet address.  */
> 
> /* Pad to size of `struct sockaddr'.  */
> unsigned char sin_zero[sizeof (struct sockaddr) -
>__SOCKADDR_COMMON_SIZE -
>sizeof (in_port_t) -
>sizeof (struct in_addr)];
>   };
> #v-
> 
> If I introduce this type:
> 
> #v+
> struct  sockaddr_storage_universal {
>   union {
>   struct sockaddr_storage sas;
>   struct sockaddr_in sai;
>   struct sockaddr_in6 sai6;
>   };
> };
> #v-
> 
> This works when used in place of "struct sockaddr_storage".

This might be something we can switch to in the future to see if we can
remove -fno-strict-aliasing (but for how long?). The emitted code is
slightly better without it (less data reloads) and disabling aliasing
for the whole code just to satisfy a few places is a bit annoying.

> I see the
> glibc is using an union too instead of struct sockaddr or struct
> sockaddr_storage. man 7 socket still says to use struct
> sockaddr_storage.

Yes it depends a lot on the syscalls in fact :-/

> Searching a bit, there is this old question on StackOverflow:
>  
> http://stackoverflow.com/questions/1429645/how-to-cast-sockaddr-storage-and-avoid-breaking-strict-aliasing-rules

Yep and on this one they were indeed trying *not* to have to use
-fno-strict-aliasing.

Thanks,
Willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Cyril Bonté]

Hi Vincent,

Le 14/05/2016 19:08, Vincent Bernat a écrit :

  ❦ 14 mai 2016 15:20 +0200, Cyril Bonté  :


What is the most important is to report this to the gcc maintainers so that
they can fix the bug. The fix will naturally flow into the distros.



I understand this and of course I could try to fill a bug on their side but
the gcc stuff is a bit out of my league.


After spending some time on this, I'm now able to produce a minimal
test case.

$ gcc-6 -O2 -o debug debug.c && ./debug
0
=> here we have an issue, as it shouldn't be 0

$ gcc-6 -O2 -DDEBUG -o debug debug.c && ./debug
7f01
7f01
=> Suddenly, everything works

And now, what happens with this debug code when -fno-tree-sra is used ?
$ gcc-6 -O2 -fno-tree-sra -DDEBUG -o debug debug.c && ./debug
7f01
0
=> It still doesn't work :-( So, disabling "tree-sra" doesn't
guarantee the right behaviour.

I also attach a debug2.c example, which is also disturbing. It is the
same code, but adds a local variable. Depending on the code order,
strange things happen (looks like a memory alignment issue).
For example :
$ gcc-6 -O2 -o debug2 debug2.c && ./debug2
0
fd7f

Note : my tests were made on a Debian SID with the gcc-6 package.


I think this is an aliasing problem. You cannot have two incompatible
variables pointing at the same memory spot. It seems that now
sockaddr_storage and sockaddr_in are not compatible anymore.

#v+
struct sockaddr_storage
   {
 __SOCKADDR_COMMON (ss_);/* Address family, etc.  */
 __ss_aligntype __ss_align;  /* Force desired alignment.  */
 char __ss_padding[_SS_PADSIZE];
   };

struct sockaddr_in
   {
 __SOCKADDR_COMMON (sin_);
 in_port_t sin_port; /* Port number.  */
 struct in_addr sin_addr;/* Internet address.  */

 /* Pad to size of `struct sockaddr'.  */
 unsigned char sin_zero[sizeof (struct sockaddr) -
__SOCKADDR_COMMON_SIZE -
sizeof (in_port_t) -
sizeof (struct in_addr)];
   };
#v-

If I introduce this type:

#v+
struct  sockaddr_storage_universal {
union {
struct sockaddr_storage sas;
struct sockaddr_in sai;
struct sockaddr_in6 sai6;
};
};
#v-

This works when used in place of "struct sockaddr_storage". I see the
glibc is using an union too instead of struct sockaddr or struct
sockaddr_storage. man 7 socket still says to use struct
sockaddr_storage.

Searching a bit, there is this old question on StackOverflow:
  
http://stackoverflow.com/questions/1429645/how-to-cast-sockaddr-storage-and-avoid-breaking-strict-aliasing-rules


Yes, that's where I stopped too after extracting the test case from the 
whole code.



--
Cyril Bonté

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Vincent Bernat]

 ❦ 14 mai 2016 15:20 +0200, Cyril Bonté  :

>>> What is the most important is to report this to the gcc maintainers so that
>>> they can fix the bug. The fix will naturally flow into the distros.
>>>
>>
>> I understand this and of course I could try to fill a bug on their side but
>> the gcc stuff is a bit out of my league.
>
> After spending some time on this, I'm now able to produce a minimal
> test case.
>
> $ gcc-6 -O2 -o debug debug.c && ./debug
> 0
> => here we have an issue, as it shouldn't be 0
>
> $ gcc-6 -O2 -DDEBUG -o debug debug.c && ./debug
> 7f01
> 7f01
> => Suddenly, everything works
>
> And now, what happens with this debug code when -fno-tree-sra is used ?
> $ gcc-6 -O2 -fno-tree-sra -DDEBUG -o debug debug.c && ./debug
> 7f01
> 0
> => It still doesn't work :-( So, disabling "tree-sra" doesn't
> guarantee the right behaviour.
>
> I also attach a debug2.c example, which is also disturbing. It is the
> same code, but adds a local variable. Depending on the code order,
> strange things happen (looks like a memory alignment issue).
> For example :
> $ gcc-6 -O2 -o debug2 debug2.c && ./debug2
> 0
> fd7f
>
> Note : my tests were made on a Debian SID with the gcc-6 package.

I think this is an aliasing problem. You cannot have two incompatible
variables pointing at the same memory spot. It seems that now
sockaddr_storage and sockaddr_in are not compatible anymore.

#v+
struct sockaddr_storage
  {
__SOCKADDR_COMMON (ss_);/* Address family, etc.  */
__ss_aligntype __ss_align;  /* Force desired alignment.  */
char __ss_padding[_SS_PADSIZE];
  };

struct sockaddr_in
  {
__SOCKADDR_COMMON (sin_);
in_port_t sin_port; /* Port number.  */
struct in_addr sin_addr;/* Internet address.  */

/* Pad to size of `struct sockaddr'.  */
unsigned char sin_zero[sizeof (struct sockaddr) -
   __SOCKADDR_COMMON_SIZE -
   sizeof (in_port_t) -
   sizeof (struct in_addr)];
  };
#v-

If I introduce this type:

#v+
struct  sockaddr_storage_universal {
union {
struct sockaddr_storage sas;
struct sockaddr_in sai;
struct sockaddr_in6 sai6;
};
};
#v-

This works when used in place of "struct sockaddr_storage". I see the
glibc is using an union too instead of struct sockaddr or struct
sockaddr_storage. man 7 socket still says to use struct
sockaddr_storage.

Searching a bit, there is this old question on StackOverflow:
 
http://stackoverflow.com/questions/1429645/how-to-cast-sockaddr-storage-and-avoid-breaking-strict-aliasing-rules
-- 
I think we are in Rats' Alley where the dead men lost their bones.
-- T.S. Eliot

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Cyril Bonté]

Hi all,

Le 14/05/2016 14:06, Arthur Țițeică a écrit :

În ziua de sâmbătă, 14 mai 2016, la 13:57:35 EEST, Willy Tarreau a scris:

What is the most important is to report this to the gcc maintainers so that
they can fix the bug. The fix will naturally flow into the distros.



I understand this and of course I could try to fill a bug on their side but
the gcc stuff is a bit out of my league.


After spending some time on this, I'm now able to produce a minimal test 
case.


$ gcc-6 -O2 -o debug debug.c && ./debug
0
=> here we have an issue, as it shouldn't be 0

$ gcc-6 -O2 -DDEBUG -o debug debug.c && ./debug
7f01
7f01
=> Suddenly, everything works

And now, what happens with this debug code when -fno-tree-sra is used ?
$ gcc-6 -O2 -fno-tree-sra -DDEBUG -o debug debug.c && ./debug
7f01
0
=> It still doesn't work :-( So, disabling "tree-sra" doesn't guarantee 
the right behaviour.


I also attach a debug2.c example, which is also disturbing. It is the 
same code, but adds a local variable. Depending on the code order, 
strange things happen (looks like a memory alignment issue).

For example :
$ gcc-6 -O2 -o debug2 debug2.c && ./debug2
0
fd7f

Note : my tests were made on a Debian SID with the gcc-6 package.

--
Cyril Bonté
#include 
#include 
#include 
#include 
#include 

struct dbg_listener {
	struct sockaddr_storage addr;
};

int main(int argc, char **argv)
{
	struct dbg_listener *l;
	struct sockaddr_storage ss, *ss2, ss3;
	
	memset(, 0, sizeof(ss3));
	ss3.ss_family = AF_INET;
	((struct sockaddr_in *))->sin_addr.s_addr = inet_addr("127.0.0.1");

	ss2 = 

	ss = *ss2;

	l = calloc(1, sizeof(*l));
	l->addr = ss;

#ifdef DEBUG
	printf("%x\n", ntohl(((struct sockaddr_in *)())->sin_addr.s_addr));
#endif
	printf("%x\n", ntohl(((struct sockaddr_in *)(>addr))->sin_addr.s_addr));
	exit(0);
}
#include 
#include 
#include 
#include 
#include 

struct dbg_listener {
	struct sockaddr_storage addr;
};

int main(int argc, char **argv)
{
	struct dbg_listener *l;
	struct sockaddr_storage ss, *ss2, ss3;
	struct sockaddr_storage addr;
	
	memset(, 0, sizeof(ss3));
	ss3.ss_family = AF_INET;
	((struct sockaddr_in *))->sin_addr.s_addr = inet_addr("127.0.0.1");

	ss2 = 

	ss = *ss2;

addr = ss;

	l = calloc(1, sizeof(*l));
	l->addr = ss;

#ifdef DEBUG
	printf("%x\n", ntohl(((struct sockaddr_in *)())->sin_addr.s_addr));
#endif
	printf("%x\n", ntohl(((struct sockaddr_in *)(>addr))->sin_addr.s_addr));
	printf("%x\n", ntohl(((struct sockaddr_in *)())->sin_addr.s_addr));
	exit(0);
}

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Arthur Țițeică]

În ziua de sâmbătă, 14 mai 2016, la 13:57:35 EEST, Willy Tarreau a scris:
> On Sat, May 14, 2016 at 02:36:39PM +0300, Arthur ??i??eic?? wrote:
> > În ziua de vineri, 13 mai 2016, la 23:47:07 EEST, Willy Tarreau a scris:
> > > On Fri, May 13, 2016 at 11:25:28PM +0200, Cyril Bonté wrote:
> > > > > In the mean time, there may be a -fsomething option to disable a
> > > > > bogus optimization which causes this, but that's not easy to spot
> > > > > as it will depend on any side effect of other code :-/
> > > > 
> > > > I was trying to identify one, and indeed, once I add "-fno-tree-sra",
> > > > it
> > > > works as expected.
> > > 
> > > This one already exists in gcc 4 and 5, so its implementation might be
> > > bogus> > 
> > > in 6. The doc says :
> > >-ftree-sra
> > >
> > >Perform scalar replacement of aggregates.  This pass replaces
> > >structure references with scalars to prevent committing
> > > 
> > > structures to memory too early.  This flag is enabled by default at -O
> > > and
> > > higher.
> > > 
> > > Thus I suspect that by delaying memory references a bit too much they
> > > end
> > > up completely forgetting to commit the changes :-/
> > 
> > Thank you everyone for the effort to diagnose this.
> > 
> > I've also managed to build 1.6.5 with "-fno-tree-sra" and I confirm that
> > all seems to be working as expected.
> > 
> > I'll pass the info in this thread to the Arch Linux maintainers.
> > I don't think they'll go back to gcc 5 but so far the additional flag
> > seems
> > like the better option.
> 
> What is the most important is to report this to the gcc maintainers so that
> they can fix the bug. The fix will naturally flow into the distros.
> 

I understand this and of course I could try to fill a bug on their side but 
the gcc stuff is a bit out of my league.

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

On Sat, May 14, 2016 at 02:36:39PM +0300, Arthur ??i??eic?? wrote:
> În ziua de vineri, 13 mai 2016, la 23:47:07 EEST, Willy Tarreau a scris:
> > On Fri, May 13, 2016 at 11:25:28PM +0200, Cyril Bonté wrote:
> > > > In the mean time, there may be a -fsomething option to disable a
> > > > bogus optimization which causes this, but that's not easy to spot
> > > > as it will depend on any side effect of other code :-/
> > > 
> > > I was trying to identify one, and indeed, once I add "-fno-tree-sra", it
> > > works as expected.
> > 
> > This one already exists in gcc 4 and 5, so its implementation might be bogus
> > in 6. The doc says :
> > 
> >-ftree-sra
> >Perform scalar replacement of aggregates.  This pass replaces
> >structure references with scalars to prevent committing
> > structures to memory too early.  This flag is enabled by default at -O and
> > higher.
> > 
> > Thus I suspect that by delaying memory references a bit too much they end
> > up completely forgetting to commit the changes :-/
> > 
> 
> Thank you everyone for the effort to diagnose this.
> 
> I've also managed to build 1.6.5 with "-fno-tree-sra" and I confirm that all 
> seems to be working as expected.
> 
> I'll pass the info in this thread to the Arch Linux maintainers.
> I don't think they'll go back to gcc 5 but so far the additional flag seems 
> like the better option.

What is the most important is to report this to the gcc maintainers so that
they can fix the bug. The fix will naturally flow into the distros.

Willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Arthur Țițeică]

În ziua de vineri, 13 mai 2016, la 23:47:07 EEST, Willy Tarreau a scris:
> On Fri, May 13, 2016 at 11:25:28PM +0200, Cyril Bonté wrote:
> > > In the mean time, there may be a -fsomething option to disable a
> > > bogus optimization which causes this, but that's not easy to spot
> > > as it will depend on any side effect of other code :-/
> > 
> > I was trying to identify one, and indeed, once I add "-fno-tree-sra", it
> > works as expected.
> 
> This one already exists in gcc 4 and 5, so its implementation might be bogus
> in 6. The doc says :
> 
>-ftree-sra
>Perform scalar replacement of aggregates.  This pass replaces
>structure references with scalars to prevent committing
> structures to memory too early.  This flag is enabled by default at -O and
> higher.
> 
> Thus I suspect that by delaying memory references a bit too much they end
> up completely forgetting to commit the changes :-/
> 

Thank you everyone for the effort to diagnose this.

I've also managed to build 1.6.5 with "-fno-tree-sra" and I confirm that all 
seems to be working as expected.

I'll pass the info in this thread to the Arch Linux maintainers.
I don't think they'll go back to gcc 5 but so far the additional flag seems 
like the better option.

Regards

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

On Fri, May 13, 2016 at 11:25:28PM +0200, Cyril Bonté wrote:
> > In the mean time, there may be a -fsomething option to disable a
> > bogus optimization which causes this, but that's not easy to spot
> > as it will depend on any side effect of other code :-/
> 
> I was trying to identify one, and indeed, once I add "-fno-tree-sra", it
> works as expected.

This one already exists in gcc 4 and 5, so its implementation might be bogus
in 6. The doc says :

   -ftree-sra
   Perform scalar replacement of aggregates.  This pass replaces
   structure references with scalars to prevent committing structures
   to memory too early.  This flag is enabled by default at -O and
   higher.

Thus I suspect that by delaying memory references a bit too much they end
up completely forgetting to commit the changes :-/

Willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Cyril Bonté]

Le 13/05/2016 23:20, Willy Tarreau a écrit :

On Fri, May 13, 2016 at 11:07:18PM +0200, Cyril Bonté wrote:

At this point, I have an issue in the function str2listener() [cfgparse.c]

In the port loop :
   for (; port <= end; port++) {
 [...]
 if (l->addr.ss_family == AF_INET) {
   [...]
Here, if I print the content of :
   ((struct sockaddr_in *)(>addr))->sin_addr.s_addr [1]
I obtain 0 while I specified a "bind 127.0.0.1:10001".

But if first, I print the content of :
   ((struct sockaddr_in *)())->sin_addr.s_addr [2]
Both [1] and [2] will have the right value.

Once I compile with -O0, the issue disappears.
I also don't have the issue if I replace :
   ss = *ss2;
with :
   memcpy(, ss2, sizeof(struct sockaddr_storage));


Wow that looks horribly messy! It seems like it's doing some mess
with structure alignments, padding, offsets or anything, but anyway
it's doing something wrong if it doesn't let us write valid C code
anymore. What is worse is that it produces bogus code, that's much
worse than refusing to build. The simple fact that it totally
changes the behaviour if you insert a line before indicates a bug
to me. It's been a very long time since I've met such a beast. I
think it should be reported, but for this a simple reproducer needs
to be found otherwise the authors will not be able to work on it,
which is understandable.

In the mean time, there may be a -fsomething option to disable a
bogus optimization which causes this, but that's not easy to spot
as it will depend on any side effect of other code :-/


I was trying to identify one, and indeed, once I add "-fno-tree-sra", it 
works as expected.




So I'd strongly suggest that people don't use gcc6 for now. We may
add a check with a #error in compiler.h if that can protect users.

Thanks,
Willy




--
Cyril Bonté

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

On Fri, May 13, 2016 at 11:07:18PM +0200, Cyril Bonté wrote:
> At this point, I have an issue in the function str2listener() [cfgparse.c]
> 
> In the port loop :
>   for (; port <= end; port++) {
> [...]
> if (l->addr.ss_family == AF_INET) {
>   [...]
> Here, if I print the content of :
>   ((struct sockaddr_in *)(>addr))->sin_addr.s_addr [1]
> I obtain 0 while I specified a "bind 127.0.0.1:10001".
> 
> But if first, I print the content of :
>   ((struct sockaddr_in *)())->sin_addr.s_addr [2]
> Both [1] and [2] will have the right value.
> 
> Once I compile with -O0, the issue disappears.
> I also don't have the issue if I replace :
>   ss = *ss2;
> with :
>   memcpy(, ss2, sizeof(struct sockaddr_storage));

Wow that looks horribly messy! It seems like it's doing some mess
with structure alignments, padding, offsets or anything, but anyway
it's doing something wrong if it doesn't let us write valid C code
anymore. What is worse is that it produces bogus code, that's much
worse than refusing to build. The simple fact that it totally
changes the behaviour if you insert a line before indicates a bug
to me. It's been a very long time since I've met such a beast. I
think it should be reported, but for this a simple reproducer needs
to be found otherwise the authors will not be able to work on it,
which is understandable.

In the mean time, there may be a -fsomething option to disable a
bogus optimization which causes this, but that's not easy to spot
as it will depend on any side effect of other code :-/

So I'd strongly suggest that people don't use gcc6 for now. We may
add a check with a #error in compiler.h if that can protect users.

Thanks,
Willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Cyril Bonté]

Le 13/05/2016 22:14, Cyril Bonté a écrit :

Hi all,

Le 13/05/2016 21:24, Willy Tarreau a écrit :

On Fri, May 13, 2016 at 10:09:04PM +0300, Arthur ??i??eic?? wrote:

I will attach 2 traces, for 1.6.4 and for 1.6.5.


So indeed in your traces, we see that 1.6.5 does bind(port=443,
addr=0.0.0.0)
while 1.6.4 has the correct address. At this point your kernel is
innocent.
I don't see what could cause this in haproxy and I can't reproduce it.
Thus
I'd really favor the switch to gcc 6 as a primary cause. I fear that
we'll
discover something not fun...


I've just installed gcc 6 and compiled haproxy with it and can confirm I
observe the same issue. Now, I'll try to investigate why.


At this point, I have an issue in the function str2listener() [cfgparse.c]

In the port loop :
  for (; port <= end; port++) {
[...]
if (l->addr.ss_family == AF_INET) {
  [...]
Here, if I print the content of :
  ((struct sockaddr_in *)(>addr))->sin_addr.s_addr [1]
I obtain 0 while I specified a "bind 127.0.0.1:10001".

But if first, I print the content of :
  ((struct sockaddr_in *)())->sin_addr.s_addr [2]
Both [1] and [2] will have the right value.

Once I compile with -O0, the issue disappears.
I also don't have the issue if I replace :
  ss = *ss2;
with :
  memcpy(, ss2, sizeof(struct sockaddr_storage));


--
Cyril Bonté

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Cyril Bonté]

Hi all,

Le 13/05/2016 21:24, Willy Tarreau a écrit :

On Fri, May 13, 2016 at 10:09:04PM +0300, Arthur ??i??eic?? wrote:

I will attach 2 traces, for 1.6.4 and for 1.6.5.


So indeed in your traces, we see that 1.6.5 does bind(port=443, addr=0.0.0.0)
while 1.6.4 has the correct address. At this point your kernel is innocent.
I don't see what could cause this in haproxy and I can't reproduce it. Thus
I'd really favor the switch to gcc 6 as a primary cause. I fear that we'll
discover something not fun...


I've just installed gcc 6 and compiled haproxy with it and can confirm I 
observe the same issue. Now, I'll try to investigate why.



--
Cyril Bonté

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

On Fri, May 13, 2016 at 10:09:04PM +0300, Arthur ??i??eic?? wrote:
> I will attach 2 traces, for 1.6.4 and for 1.6.5.

So indeed in your traces, we see that 1.6.5 does bind(port=443, addr=0.0.0.0)
while 1.6.4 has the correct address. At this point your kernel is innocent.
I don't see what could cause this in haproxy and I can't reproduce it. Thus
I'd really favor the switch to gcc 6 as a primary cause. I fear that we'll
discover something not fun...

Willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

On Fri, May 13, 2016 at 10:09:04PM +0300, Arthur ??i??eic?? wrote:
> În ziua de vineri, 13 mai 2016, la 19:12:23 EEST, Willy Tarreau a scris:
> > On Fri, May 13, 2016 at 06:59:49PM +0300, Arthur ??i??eic?? wrote:
> > > I already went back and forth between the 2 versions to confirm that it's
> > > still working fine in 1.6.4.
> > 
> > But using a version that you rebuilt for this or the version that you had
> > built some time ago ? I just want to ensure that your build environment
> > still produces valid executables in fact (as I trust it used to do last
> > time you built a working 1.6.4).
> 
> They are distro packages. As much as I can see they are built the same. I 
> will 
> put the output of '-vv' at the end the email.
> 
> However, one major change might be that 1.6.4 was built with gcc 5 and 
> haproxy 
> 1.6.5 is built with gcc 6.

OK, one more reason for first trying to build 1.6.4 from sources using the
same procedure you use for 1.6.5, and verifying if it has the same issue.

> > Let's do the strace first :-)
> > 
> 
> I hope you don't mind if I send the traces off-list. I'm not sure how much 
> private info is in there.

Definitely!

> I will attach 2 traces, for 1.6.4 and for 1.6.5.

Thanks.

willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Arthur Țițeică]

În ziua de vineri, 13 mai 2016, la 19:12:23 EEST, Willy Tarreau a scris:
> On Fri, May 13, 2016 at 06:59:49PM +0300, Arthur ??i??eic?? wrote:
> > I already went back and forth between the 2 versions to confirm that it's
> > still working fine in 1.6.4.
> 
> But using a version that you rebuilt for this or the version that you had
> built some time ago ? I just want to ensure that your build environment
> still produces valid executables in fact (as I trust it used to do last
> time you built a working 1.6.4).

They are distro packages. As much as I can see they are built the same. I will 
put the output of '-vv' at the end the email.

However, one major change might be that 1.6.4 was built with gcc 5 and haproxy 
1.6.5 is built with gcc 6.


> Let's do the strace first :-)
> 

I hope you don't mind if I send the traces off-list. I'm not sure how much 
private info is in there.

I will attach 2 traces, for 1.6.4 and for 1.6.5.

Thanks




# haproxy -vv
HA-Proxy version 1.6.5 2016/05/10
Copyright 2000-2016 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
  OPTIONS = USE_GETADDRINFO=1 USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 
USE_PCRE_JIT=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Encrypted password support via crypt(3): yes
Built with zlib version : 1.2.8
Compression algorithms supported : identity("identity"), deflate("deflate"), 
raw-deflate("deflate"), gzip("gzip")
Built with OpenSSL version : OpenSSL 1.0.2h  3 May 2016
Running on OpenSSL version : OpenSSL 1.0.2h  3 May 2016
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports prefer-server-ciphers : yes
Built with PCRE version : 8.38 2015-11-23
PCRE library supports JIT : yes
Built with Lua version : Lua 5.3.2
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT 
IP_FREEBIND

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

On Fri, May 13, 2016 at 06:59:49PM +0300, Arthur ??i??eic?? wrote:
> I already went back and forth between the 2 versions to confirm that it's
> still working fine in 1.6.4.

But using a version that you rebuilt for this or the version that you had
built some time ago ? I just want to ensure that your build environment
still produces valid executables in fact (as I trust it used to do last
time you built a working 1.6.4).

> When I get home I will try to start haproxy in debug mode and I will try to
> strace it (any help on this would be appreciated).

OK thanks. For this, just run ps auxw|grep haproxy, then copy-paste the exact
command line, kill it, and run :

   strace -tts200 -o haproxy.trace [paste-exact-command-line-here]

Once you're confident that it has finished starting, you can press Ctrl-C
(or killall haproxy from another window), and everything will be in
haproxy.trace.

> If all fails I will reboot the server in a non-grsec kernel (4.5.2 btw).

Let's do the strace first :-)

Thanks,
Willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Arthur Țițeică]

I already went back and forth between the 2 versions to confirm that it's
still working fine in 1.6.4.

When I get home I will try to start haproxy in debug mode and I will try to
strace it (any help on this would be appreciated).

If all fails I will reboot the server in a non-grsec kernel (4.5.2 btw).
Pe 13 mai 2016 6:51 p.m., "Willy Tarreau"  a scris:

> On Fri, May 13, 2016 at 06:30:35PM +0300, Arthur ??i??eic?? wrote:
> > Hi,
> >
> > 1.6.4 worked fine with the same config.
> >
> > I noticed this because I have the same port bound on 127.0.0.1 too and
> > haproxy refused to start after upgrade.
> >
> > Another curious thing is that with haproxy bind on *two* ipv4 addresses I
> > also see two *:143 in the 'ss' output.
> >
> > This is not specific to the listen directive. It happens on all ipv4
> > addresses with 'frontend' or 'listen' both TCP and HTTP.
>
> Thus it sounds like something changed in the address parser and affected
> you. The problem is that I'm not seeing any such change.
>
> It would be interesting to try to rebuild 1.6.4 on the same machine to
> see if it suddenly fails, possibly indicating something else has changed
> (eg: libc update, build options, etc).
>
> Thanks
> willy
>
>

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

On Fri, May 13, 2016 at 06:30:35PM +0300, Arthur ??i??eic?? wrote:
> Hi,
> 
> 1.6.4 worked fine with the same config.
> 
> I noticed this because I have the same port bound on 127.0.0.1 too and
> haproxy refused to start after upgrade.
> 
> Another curious thing is that with haproxy bind on *two* ipv4 addresses I
> also see two *:143 in the 'ss' output.
>
> This is not specific to the listen directive. It happens on all ipv4
> addresses with 'frontend' or 'listen' both TCP and HTTP.

Thus it sounds like something changed in the address parser and affected
you. The problem is that I'm not seeing any such change.

It would be interesting to try to rebuild 1.6.4 on the same machine to
see if it suddenly fails, possibly indicating something else has changed
(eg: libc update, build options, etc).

Thanks
willy

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Pavlos Parissis]

On 13/05/2016 04:41 μμ, Arthur Țițeică wrote:
> Hi,
> 
> With the 1.6.5 upgrade I see that a configuration like this
> 
> listen tcp-imap
>   bind 1.2.3.4:143 name imap-v4
> 
> will make haproxy listen on all ipv4 addresses instead.
> 
> # ss -ltnp | column -t| grep 143
> LISTEN  0   50  *:143 *:* users:(("haproxy",pid=13010,fd=19))
> 
> IPv6 works as advertised.
> 
> ​Thanks​
> 

I *can't* reproduce this on 1.6.5


% sudo haproxytool haproxy -F /var/lib/haproxy/stats --release-date
2016/05/10


% sudo haproxytool haproxy -F /var/lib/haproxy/stats --uptime-secs
189253


%sudo haproxytool haproxy -F /var/lib/haproxy/stats --hap-version
1.6.5


% grep bind /etc/haproxy/haproxy.cfg
bind :8080
bind 10.252.12.1:80
bind 10.252.12.1:443 ssl crt /etc/ssl/certs/foo
bind 10.252.12.2:80
bind 10.252.12.2:443 ssl crt /etc/ssl/certs/foo
bind 10.252.12.3:80
bind 10.252.12.3:443 ssl crt /etc/ssl/certs/foo



% sudo ss -ltnp|egrep '80|443'|column -t
LISTEN  0  2048  10.252.12.3:80 *:*  users:(("haproxy",49818,11))
LISTEN  0  2048  10.252.12.2:80 *:*  users:(("haproxy",49818,9))
LISTEN  0  2048  10.252.12.1:80 *:*  users:(("haproxy",49818,6))
LISTEN  0  2048  *:8080 *:*  users:(("haproxy",49818,5))
LISTEN  0  2048  10.252.12.3:443*:*  users:(("haproxy",49818,12))
LISTEN  0  2048  10.252.12.2:443*:*  users:(("haproxy",49818,10))
LISTEN  0  2048  10.252.12.1:443*:*  users:(("haproxy",49818,8))
LISTEN  0  1024  10.196.180.4:2812  *:*  users:(("monit",8746,6))

Cheers,
Pavlos



signature.asc
Description: OpenPGP digital signature

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Arthur Țițeică]

Hi,

1.6.4 worked fine with the same config.

I noticed this because I have the same port bound on 127.0.0.1 too and
haproxy refused to start after upgrade.

Another curious thing is that with haproxy bind on *two* ipv4 addresses I
also see two *:143 in the 'ss' output.

This is not specific to the listen directive. It happens on all ipv4
addresses with 'frontend' or 'listen' both TCP and HTTP.

Thanks
Pe 13 mai 2016 6:14 p.m., "Willy Tarreau"  a scris:

> Hi Arthur,
>
> On Fri, May 13, 2016 at 05:41:50PM +0300, Arthur ??i??eic?? wrote:
> > Hi,
> >
> > With the 1.6.5 upgrade I see that a configuration like this
> >
> > listen tcp-imap
> >   bind 1.2.3.4:143name imap-v4
> >
> > will make haproxy listen on all ipv4 addresses instead.
> >
> > # ss -ltnp | column -t| grep 143
> > LISTEN  0   50  *:143 *:* users:(("haproxy",pid=13010,fd=19))
> >
> > IPv6 works as advertised.
>
> I can't reproduce this behaviour :
>
> $ ss -ltnp | grep 1143|column -t
> LISTEN  0  128  1.2.3.4:1143  *:*  users:(("haproxy",pid=7547,fd=4))
>
> Are you certain you didn't change the bind address without restarting
> or anything like this ? I guess so but I'm trying to find a rationale
> reason. What version did not exhibit this behaviour previously ?
>
> Thanks,
> Willy
>

Re: Haproxy 1.6.5 listens on all IPv4 addresses

[Willy Tarreau]

Hi Arthur,

On Fri, May 13, 2016 at 05:41:50PM +0300, Arthur ??i??eic?? wrote:
> Hi,
> 
> With the 1.6.5 upgrade I see that a configuration like this
> 
> listen tcp-imap
>   bind 1.2.3.4:143name imap-v4
> 
> will make haproxy listen on all ipv4 addresses instead.
> 
> # ss -ltnp | column -t| grep 143
> LISTEN  0   50  *:143 *:* users:(("haproxy",pid=13010,fd=19))
> 
> IPv6 works as advertised.

I can't reproduce this behaviour :

$ ss -ltnp | grep 1143|column -t
LISTEN  0  128  1.2.3.4:1143  *:*  users:(("haproxy",pid=7547,fd=4))

Are you certain you didn't change the bind address without restarting
or anything like this ? I guess so but I'm trying to find a rationale
reason. What version did not exhibit this behaviour previously ?

Thanks,
Willy