Regarding migration on version haproxy-1.7.3

[Devendra Joshi]

Hi,
currently we are using haproxy-1.5.14 & now we want to migrate on
haproxy-1.7.3


is there any config changes or need to do some setting.



==
*Devendra Joshi*
*Naap**tol* Online Shopping Pvt. Ltd.
M: +91 8080106035 | Tel: +91 022 61432446

-- 
Disclaimer: This e-mail and any documents, files, or previous e-mail 
messages appended or attached to it may contain confidential and/or 
privileged information. If you are not the intended recipient (or have 
received this e-mail in error) please notify the sender immediately and 
delete this e-mail. Any unauthorized copying, disclosure or distribution of 
the material in this e-mail is strictly forbidden.



-- 
*Disclaimer*: This e-mail and any documents, files, or previous e-mail 
messages appended or attached to it may contain confidential and/or 
privileged information. If you are not the intended recipient (or have 
received this e-mail in error) please notify the sender immediately and 
delete this e-mail. Any unauthorized copying, disclosure or distribution of 
the material in this e-mail is strictly forbidden.

Re: [PATCH]: BUG/MINOR: general build fix for solaris based oses

[Willy Tarreau]

Hi David,

On Wed, Jun 07, 2017 at 08:14:24PM +0100, David CARLIER wrote:
> Hi, just tried a build under Illumos and the CMSG* macros implies XPG4V2
> enabled.
> 
> Hope it is useful.

Sure, now applied, thanks!
Willy

Re: RFC: ipv6mask converter

[Willy Tarreau]

Hi Jarno,

On Wed, Jun 07, 2017 at 08:18:55PM +0300, Jarno Huuskonen wrote:
> So something like:
> > > + { "ipmask", sample_conv_ipmask,ARG2(1,MSK4,MSK6), NULL, SMP_T_ADDR, 
> > > SMP_T_ADDR },
> 
> (using SMP_T_ADDR output type makes stick table complain:
> http-request track-sc0 req.hdr_ip(X,1),ipmask(24,64) table test_be
> ...stick-table 'test_be' uses a type incompatible with the 'track-sc0' rule.

Argh!

> Might work by adding ADDR->IPV4/IPV6 c_none casts to sample_casts
> (or using SMP_T_IPV4 or SMP_T_IPV6 output)).

Or probably that we're missing a case with SMP_T_ADDR in stick tables, as
it was introduced late and we never needed it. I remember there's already
one converter emitting SMP_T_ADDR, I think it's a map so we already have
this problem.

Looking at sample_casts[], it seems to me that we need a set of c_addr2*()
functions taking care of the input type. These ones could possibly even
replace the ip2* and ipv62* casts as it would superset them.

> (setting headers works with SMP_T_ADDR output:
> http-request set-var(sess.myx) req.hdr_ip(X,1),ipmask(24,64)
> http-response set-header X-MY %[var(sess.myx)]
> )

Nice!

Willy

Re: OpenSSL engine and async support

[Willy Tarreau]

Hi Emeric,

On Tue, Jun 06, 2017 at 03:16:39PM +0200, Emeric Brun wrote:
> Here 3 new fixes:
> 
> I noticed a segfault sometime at connection closure (first patch)
> 
> I noticed buffer overflows using the cipher offloading in async:
> 
> The moving or reuse of buffer addresses passed to SSL_read/write in haproxy
> is not compliant with the ASYNC API. I had a discussion about that on the
> openssl-dev mailing list with Matt Caswell.
> 
> So the second patch disables the async mode for the symmetric stuff.
> 
> The last one to not call directly the conn_fd_handler from the 
> async_fd_handler.

All applied, thanks Emeric!
Willy

[PATCH]: BUG/MINOR: general build fix for solaris based oses

[David CARLIER]

Hi, just tried a build under Illumos and the CMSG* macros implies XPG4V2
enabled.

Hope it is useful.

Kind regards.
From 9ec3a111fc885528d7ac5d78d40f0b89079b5bb3 Mon Sep 17 00:00:00 2001
From: David Carlier 
Date: Wed, 7 Jun 2017 20:02:43 +0100
Subject: [PATCH] BUG/MINOR: haproxy/cli : fix for solaris/illumos distros for
 CMSG* macros

control message sockets macros implies (SUS)XPG4V2 enabled under solaris based oses.
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 1c90a3ea..88ba5525 100644
--- a/Makefile
+++ b/Makefile
@@ -286,7 +286,7 @@ ifeq ($(TARGET),solaris)
   # This is for Solaris 8
   # We also enable getaddrinfo() which works since solaris 8.
   USE_POLL   = implicit
-  TARGET_CFLAGS  = -fomit-frame-pointer -DFD_SETSIZE=65536 -D_REENTRANT
+  TARGET_CFLAGS  = -fomit-frame-pointer -DFD_SETSIZE=65536 -D_REENTRANT -D_XOPEN_SOURCE=500 -D__EXTENSIONS__
   TARGET_LDFLAGS = -lnsl -lsocket
   USE_TPROXY = implicit
   USE_LIBCRYPT= implicit
-- 
2.12.2

Re: RFC: ipv6mask converter

[Jarno Huuskonen]

Hi,

On Wed, Jun 07, Willy Tarreau wrote:
> On Sun, Jun 04, 2017 at 07:12:38PM +0300, Jarno Huuskonen wrote:
> > Hi Willy,
> > 
> > On Sat, May 27, Willy Tarreau wrote:
> > > On Sun, May 21, 2017 at 07:49:00PM +0300, Jarno Huuskonen wrote:
> > > > I noticed that ipv6 version of ipmask() converter is missing ?
> > > > 
> > > > I'm attaching an example implementation for ipv6mask (incomplete:
> > > > missing at least documentation / lua) for comments.
> > > > 
> > > > Maybe instead of just working with one mask ipv6mask(converter) could
> > > > take two arguments: first ipv6mask, second(optional) ipv4 mask applied 
> > > > to
> > > > ipv4mapped ipv6 address(:::1.2.3.4).
> > > 
> > > That could indeed be a good idea. Thinking a bit further, shouldn't we
> > > extend the current ipmask to support an optional ipv6 mask as a second
> > > argument (ie exactly what you did but with ipv6 optional instead of
> > > ipv4) ? This would allow it to be used on any address. It would end
> > > up like this :
> > >   - ipv4 in => ipv4 out, using ipv4 mask
> > >   - ipv4-in-ipv6 in => ipv4-in-ipv6 out, using ipv4 mask
> > >   - ipv6 in => ipv6 out, using ipv6 mask
> > 
> > So ipmask would internally work on ipv6 addresses and ipv4
> > addresses are converted to/from mapped (:::1.2.3.4) addresses ?
> 
> No, not necessarily, we know the type of the input sample so we can apply
> the mask we want and emit the same type on output. I was only saying that
> the ipv4 mask should be used when you face ipv4-in-ipv6 addresses.
> 
> > > What do you think ?
> > 
> > ipmask() with optional ipv6mask is fine with me, I guess it won't break
> > existing configs because ipv6 mask is optional. For ipv4 only it probably
> > adds a little overhead when converting to/from mapped :::1.2.3.4 
> > addresses.
> 
> It would cause other trouble such as conversion to strings which will be
> mangled by this ":::" prefix. That's why it's better to maintain the
> same type.
> 
> > @@ -2736,7 +2747,7 @@ static struct sample_conv_kw_list sample_conv_kws = 
> > {ILH, {
> > { "upper",  sample_conv_str2upper, 0,NULL, SMP_T_STR,  
> > SMP_T_STR  },
> > { "lower",  sample_conv_str2lower, 0,NULL, SMP_T_STR,  
> > SMP_T_STR  },
> > { "hex",sample_conv_bin2hex,   0,NULL, SMP_T_BIN,  
> > SMP_T_STR  },
> > -   { "ipmask", sample_conv_ipmask,ARG1(1,MSK4), NULL, SMP_T_IPV4, 
> > SMP_T_IPV4 },
> > +   { "ipmask", sample_conv_ipmask,ARG2(1,MSK4,MSK6), NULL, SMP_T_IPV6, 
> > SMP_T_IPV6 },
> 
> You need to use SMP_T_ADDR instead of SMP_T_IPV6 in order to adapt to any
> address family type and not enforce it. Maybe this is what led you to think
> that you needed to convert ipv4 to ipv6.

I might be finally getting it:)

So something like:
> > +   { "ipmask", sample_conv_ipmask,ARG2(1,MSK4,MSK6), NULL, SMP_T_ADDR, 
> > SMP_T_ADDR },

(using SMP_T_ADDR output type makes stick table complain:
http-request track-sc0 req.hdr_ip(X,1),ipmask(24,64) table test_be
...stick-table 'test_be' uses a type incompatible with the 'track-sc0' rule.
Might work by adding ADDR->IPV4/IPV6 c_none casts to sample_casts
(or using SMP_T_IPV4 or SMP_T_IPV6 output)).

(setting headers works with SMP_T_ADDR output:
http-request set-var(sess.myx) req.hdr_ip(X,1),ipmask(24,64)
http-response set-header X-MY %[var(sess.myx)]
)

and sample_conv_ipmask with SMP_T_ADDR input:
if (smp->data.type == SMP_T_IPV4) {
/* ipv4 address & ipv4 mask */
...
}
else if (smp->data.type == SMP_T_IPV6) {
if (*(uint32_t*)&smp->data.u.ipv6.s6_addr[8] == htonl(0x))...) {
/* ipv4 mapped ipv6 & ipv4mask */
...
}
else if (arg_p[1].type == ARGT_IPV6) {
/* ipv6 & ipv6 mask */
...
}
}

-Jarno

-- 
Jarno Huuskonen

Re: exit error regression on haproxy1.8dev

[Emmanuel Hocdet]

> Le 7 juin 2017 à 15:20, William Lallemand  a écrit :
> 
> On Wed, Jun 07, 2017 at 02:13:58PM +0200, Emmanuel Hocdet wrote:
>> 
>>> Le 7 juin 2017 à 10:34, Emmanuel Hocdet  a écrit :
>>> 
>>> Hi,
>>> 
>>> ok:
 haproxy -f test.cfg -W
 echo $?
>>> 0
>>> 
>>> bad:
 haproxy -f test.cfg
 echo $?
>>> 1
>>> 
>>> With bunch of modified code, i am a little lost to track the bug.
>>> 
>>> Manu
>>> 
>>> 
>> 
> 
> You are right about the regression, however this part of the code should be
> called in daemon mode only, the regression was elsewhere :)
> 
> Fix attached.
> 
> -- 
> William Lallemand
> <0001-BUG-MEDIUM-misplaced-exit-and-wrong-exit-code.patch>

test ok for me

thanks!

Re: exit error regression on haproxy1.8dev

[William Lallemand]

On Wed, Jun 07, 2017 at 02:13:58PM +0200, Emmanuel Hocdet wrote:
> 
> > Le 7 juin 2017 à 10:34, Emmanuel Hocdet  a écrit :
> > 
> > Hi,
> > 
> > ok:
> >> haproxy -f test.cfg -W
> >> echo $?
> > 0
> > 
> > bad:
> >> haproxy -f test.cfg
> >> echo $?
> > 1
> > 
> > With bunch of modified code, i am a little lost to track the bug.
> > 
> > Manu
> > 
> > 
> 
 
You are right about the regression, however this part of the code should be
called in daemon mode only, the regression was elsewhere :)

Fix attached.

-- 
William Lallemand
>From 4171380e2ff3d562bfcf4f7aa5325d79ccda025b Mon Sep 17 00:00:00 2001
From: William Lallemand 
Date: Wed, 7 Jun 2017 15:04:47 +0200
Subject: [PATCH] BUG/MEDIUM: misplaced exit and wrong exit code

Commit cb11fd2 ("MEDIUM: mworker: wait mode on reload failure")
introduced a regression, when HAProxy is used in daemon mode, it exits 1
after forking its children.

HAProxy should exit(0), the exit(EXIT_FAILURE) was expected to be use
when the master fail in master-worker mode.

Thanks to Emmanuel Hocdet for reporting this bug. No backport needed.
---
 src/haproxy.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index 60bd334b..51cdf48e 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2574,12 +2574,13 @@ int main(int argc, char **argv)
 			if (global.mode & MODE_MWORKER) {
 protocol_unbind_all();
 mworker_wait();
+/* should never get there */
+exit(EXIT_FAILURE);
 			}
 #ifndef OPENSSL_NO_DH
 			ssl_free_dh();
 #endif
-			/* should never get there */
-			exit(EXIT_FAILURE);
+			exit(0); /* parent must leave */
 		}
 
 		/* child must never use the atexit function */
-- 
2.13.0

Re: exit error regression on haproxy1.8dev

[Emmanuel Hocdet]

> Le 7 juin 2017 à 10:34, Emmanuel Hocdet  a écrit :
> 
> Hi,
> 
> ok:
>> haproxy -f test.cfg -W
>> echo $?
> 0
> 
> bad:
>> haproxy -f test.cfg
>> echo $?
> 1
> 
> With bunch of modified code, i am a little lost to track the bug.
> 
> Manu
> 
> 


This patch seem correct the problem, but…

diff --git a/src/haproxy.c b/src/haproxy.c
index 60bd334..1cc39b0 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2495,9 +2495,9 @@ int main(int argc, char **argv)
 * process live in background before forking children
 */
 
-   if ((getenv("HAPROXY_MWORKER_REEXEC") == NULL)
-   && (global.mode & MODE_MWORKER)
-   && (global.mode & MODE_DAEMON)) {
+   if (((getenv("HAPROXY_MWORKER_REEXEC") == NULL)
+&& (global.mode & MODE_MWORKER)  && (global.mode & 
MODE_DAEMON))
+   || (!(global.mode & MODE_MWORKER) && (global.mode & 
MODE_DAEMON))) {
ret = fork();
if (ret < 0) {
Alert("[%s.main()] Cannot fork.\n", argv[0]);

Re: [PATCH] BUG/MINOR: contrib/mod_defender

[Dragan Dosen]

Hi David,

Thanks for feedback!

On 7.6.2017. 12:45, David CARLIER wrote:
> Hi all,
> similarly to modsecurity, here is a proposal for mod_defender.
> 
> Hope it is useful.
> 
> Kind regards.

It looks good to me and can be merged to upstream if there are no
objections from the others.

Best regards,
Dragan Dosen

Re: HaProxy Hang

[Dave Cottlehuber]

On Wed, 7 Jun 2017, at 10:42, David King wrote:
> Just to close the loop on this, last night was the time at which we were
> expecting the next hang. All of the servers we updated haproxy to the
> patched versions did not hang. The test servers which were running the
> older version hung as expected
> 
> Thanks so much to everyone who fixed the issue!

Same here, although as we patched everything we had no issues at all :D
Merci beaucoup!

A+
Dave

[PATCH] BUG/MINOR: contrib/mod_defender

[David CARLIER]

Hi all,
similarly to modsecurity, here is a proposal for mod_defender.

Hope it is useful.

Kind regards.
From 8cbe58187a71eb505f7439b28847dccbc82a328a Mon Sep 17 00:00:00 2001
From: David Carlier 
Date: Wed, 7 Jun 2017 12:39:16 +0100
Subject: [PATCH] BUG/MINOR: contrib/mod_defender: build fix

In similar manner than modsecurity, making the build possible under *BSD flavors, the -lm for ceilf function.
---
 contrib/mod_defender/Makefile | 18 +-
 contrib/mod_defender/spoa.h   |  1 +
 2 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/contrib/mod_defender/Makefile b/contrib/mod_defender/Makefile
index 119d8240..ac17774d 100644
--- a/contrib/mod_defender/Makefile
+++ b/contrib/mod_defender/Makefile
@@ -2,10 +2,10 @@ DESTDIR=
 PREFIX = /usr/local
 BINDIR = $(PREFIX)/bin
 
-CC = gcc
+CC ?= gcc
 LD = $(CC)
 
-CXX = g++
+CXX ?= g++
 
 ifeq ($(MOD_DEFENDER_SRC),)
 MOD_DEFENDER_SRC := ./mod_defender_src
@@ -19,9 +19,17 @@ ifeq ($(APR_INC),)
 APR_INC := /usr/include/apr-1.0
 endif
 
-CFLAGS  = -g -Wall -pthread
-LDFLAGS = -lpthread  -levent -levent_pthreads -lapr-1 -laprutil-1 -lstdc++
-INCS += -I../../include -I../../ebtree -I$(MOD_DEFENDER_SRC) -I$(APACHE2_INC) -I$(APR_INC)
+ifeq ($(EVENT_LIB),)
+EVENT_LIB := -levent
+endif
+
+ifeq ($(EVENT_INC),)
+EVENT_INC := /usr/include
+endif
+
+CFLAGS  += -g -Wall -pthread
+LDFLAGS += -lpthread  $(EVENT_LIB) -levent_pthreads -lapr-1 -laprutil-1 -lstdc++ -lm
+INCS += -I../../include -I../../ebtree -I$(MOD_DEFENDER_SRC) -I$(APACHE2_INC) -I$(APR_INC) -I$(EVENT_INC)
 LIBS =
 
 CXXFLAGS = -g -std=gnu++11
diff --git a/contrib/mod_defender/spoa.h b/contrib/mod_defender/spoa.h
index 332f387d..726007fc 100644
--- a/contrib/mod_defender/spoa.h
+++ b/contrib/mod_defender/spoa.h
@@ -16,6 +16,7 @@
 #define __SPOA_H__
 
 #include 
+#undef LIST_HEAD
 
 #include 
 #include 
-- 
2.13.0

Re: HaProxy Hang

[Willy Tarreau]

Hi David,

On Wed, Jun 07, 2017 at 09:42:58AM +0100, David King wrote:
> Just to close the loop on this, last night was the time at which we were
> expecting the next hang. All of the servers we updated haproxy to the
> patched versions did not hang. The test servers which were running the
> older version hung as expected
> 
> Thanks so much to everyone who fixed the issue!

Feedback much appreciated, thank you! We need to issue 1.7.6 soon with
this fix but other troubling ones being under investigation have delayed
this a bit.

Cheers,
Willy

Re: How to add custom options to CFLAGS

[Dmitry Sivachenko]

> On 07 Jun 2017, at 11:41, Willy Tarreau  wrote:
> 
> Hi Dmitry,
> 
> On Sun, Jun 04, 2017 at 02:54:23PM +0300, Dmitry Sivachenko wrote:
>>> Same here, and it's important not to create confusion on the way
>>> CFLAGS are computed.
>>> 
>>> By the way, usually if I need to add some specific flags (eg #define),
>>> I do it via DEFINE or SMALL_OPTS. If I want to change the optimization
>>> options, I use CPU_CFLAGS or CPU_CFLAGS..
>>> 
>>> So maybe you already have what you need and only the documentation needs
>>> to be improved.
>>> 
>> 
>> FreeBSD ports collection has a rule for CFLAGS customisation: ports framework
>> sets CFLAGS environment and expects it to be used during compilation.
>> 
>> Usually people use it to specify different -On options and other
>> optimisations they want.
>> 
>> So strictly speaking it is not CPU-specific, but rather environment-specific.
> 
> I agree on the general principle, it just happens that for a very long time
> I've had to deal with broken compilers on various CPUs that were producing
> bogus code at certain optimization levels, which is what made the optimization
> level end up in the CPU-specific CFLAGS. Good memories are gcc 3.0.4 on PARISC
> and pgcc on i586.
> 
> While things have significantly evolved since then, there are still certain
> flags which directly affect optimization and which have a different behaviour
> on various architectures (-mcpu, -mtune, -march, -mregparm). Given that in
> general you want to change them when you change the optimization level
> (typically to produce debuggable code), I tend to think it continues to make
> sense to have all of them grouped together.


I see.


> 
>> Right now I see only -O2 in CPU_CFLAGS, so it can be used for that purpose.
>> 
>> If the consensus will be to use CPU_CFLAGS for my purpose, it's OK, I will
>> switch to it.
> 
> If that's OK for you, I indeed would rather avoid touching that sensitive 
> area,
> though we can always extend it but I prefer the principle of least surprize.
> You can probably just do run make "CPU_CFLAGS=$CFLAGS" and achieve exactly 
> what
> you want.
> 

Yes, that is what I was talking about.  I'll stick to that approach then.

Thanks!

Re: HaProxy Hang

[David King]

Just to close the loop on this, last night was the time at which we were
expecting the next hang. All of the servers we updated haproxy to the
patched versions did not hang. The test servers which were running the
older version hung as expected

Thanks so much to everyone who fixed the issue!

On 18 April 2017 at 10:45, Willy Tarreau  wrote:

> Hi David,
>
> On Tue, Apr 18, 2017 at 10:33:40AM +0100, David King wrote:
> > Hi All
> >
> > Just like to confirm Willy's theory, we had the hang at exactly the time
> > specified this morning.
>
> I could recycle myself in a new church of which I would be the prophet...
> well maybe it already exists, we have thousands of adepts after all :-)
>
> More seriously, I think it will be useful to report a bug to the FreeBSD
> project, there are quite a number of elements, possibly nothing that can
> make it obvious where the problem could be, but a number of hypothesis
> can be ruled out already I think. It's possible that some FreeBSD devs
> ask us to monitor a few things or capture some syscall returns, or try
> some workarounds and this might require some dev. So in short, the earlier
> the better if we want to be ready for the next occurrence.
>
> Cheers,
> Willy
>

Re: How to add custom options to CFLAGS

[Willy Tarreau]

Hi Dmitry,

On Sun, Jun 04, 2017 at 02:54:23PM +0300, Dmitry Sivachenko wrote:
> > Same here, and it's important not to create confusion on the way
> > CFLAGS are computed.
> > 
> > By the way, usually if I need to add some specific flags (eg #define),
> > I do it via DEFINE or SMALL_OPTS. If I want to change the optimization
> > options, I use CPU_CFLAGS or CPU_CFLAGS..
> > 
> > So maybe you already have what you need and only the documentation needs
> > to be improved.
> > 
> 
> FreeBSD ports collection has a rule for CFLAGS customisation: ports framework
> sets CFLAGS environment and expects it to be used during compilation.
> 
> Usually people use it to specify different -On options and other
> optimisations they want.
> 
> So strictly speaking it is not CPU-specific, but rather environment-specific.

I agree on the general principle, it just happens that for a very long time
I've had to deal with broken compilers on various CPUs that were producing
bogus code at certain optimization levels, which is what made the optimization
level end up in the CPU-specific CFLAGS. Good memories are gcc 3.0.4 on PARISC
and pgcc on i586.

While things have significantly evolved since then, there are still certain
flags which directly affect optimization and which have a different behaviour
on various architectures (-mcpu, -mtune, -march, -mregparm). Given that in
general you want to change them when you change the optimization level
(typically to produce debuggable code), I tend to think it continues to make
sense to have all of them grouped together.

> So exactly what comment near CFLAGS is about: "".
> Right now I see only -O2 in CPU_CFLAGS, so it can be used for that purpose.
> 
> If the consensus will be to use CPU_CFLAGS for my purpose, it's OK, I will
> switch to it.

If that's OK for you, I indeed would rather avoid touching that sensitive area,
though we can always extend it but I prefer the principle of least surprize.
You can probably just do run make "CPU_CFLAGS=$CFLAGS" and achieve exactly what
you want.

Cheers,
Willy

exit error regression on haproxy1.8dev

[Emmanuel Hocdet]

Hi,

ok:
> haproxy -f test.cfg -W
> echo $?
0

bad:
> haproxy -f test.cfg
> echo $?
1

With bunch of modified code, i am a little lost to track the bug.

Manu

Re: RFC: ipv6mask converter

[Willy Tarreau]

Hi Jarno,

On Sun, Jun 04, 2017 at 07:12:38PM +0300, Jarno Huuskonen wrote:
> Hi Willy,
> 
> On Sat, May 27, Willy Tarreau wrote:
> > On Sun, May 21, 2017 at 07:49:00PM +0300, Jarno Huuskonen wrote:
> > > I noticed that ipv6 version of ipmask() converter is missing ?
> > > 
> > > I'm attaching an example implementation for ipv6mask (incomplete:
> > > missing at least documentation / lua) for comments.
> > > 
> > > Maybe instead of just working with one mask ipv6mask(converter) could
> > > take two arguments: first ipv6mask, second(optional) ipv4 mask applied to
> > > ipv4mapped ipv6 address(:::1.2.3.4).
> > 
> > That could indeed be a good idea. Thinking a bit further, shouldn't we
> > extend the current ipmask to support an optional ipv6 mask as a second
> > argument (ie exactly what you did but with ipv6 optional instead of
> > ipv4) ? This would allow it to be used on any address. It would end
> > up like this :
> >   - ipv4 in => ipv4 out, using ipv4 mask
> >   - ipv4-in-ipv6 in => ipv4-in-ipv6 out, using ipv4 mask
> >   - ipv6 in => ipv6 out, using ipv6 mask
> 
> So ipmask would internally work on ipv6 addresses and ipv4
> addresses are converted to/from mapped (:::1.2.3.4) addresses ?

No, not necessarily, we know the type of the input sample so we can apply
the mask we want and emit the same type on output. I was only saying that
the ipv4 mask should be used when you face ipv4-in-ipv6 addresses.

> > What do you think ?
> 
> ipmask() with optional ipv6mask is fine with me, I guess it won't break
> existing configs because ipv6 mask is optional. For ipv4 only it probably
> adds a little overhead when converting to/from mapped :::1.2.3.4 
> addresses.

It would cause other trouble such as conversion to strings which will be
mangled by this ":::" prefix. That's why it's better to maintain the
same type.

> @@ -2736,7 +2747,7 @@ static struct sample_conv_kw_list sample_conv_kws = 
> {ILH, {
>   { "upper",  sample_conv_str2upper, 0,NULL, SMP_T_STR,  
> SMP_T_STR  },
>   { "lower",  sample_conv_str2lower, 0,NULL, SMP_T_STR,  
> SMP_T_STR  },
>   { "hex",sample_conv_bin2hex,   0,NULL, SMP_T_BIN,  
> SMP_T_STR  },
> - { "ipmask", sample_conv_ipmask,ARG1(1,MSK4), NULL, SMP_T_IPV4, 
> SMP_T_IPV4 },
> + { "ipmask", sample_conv_ipmask,ARG2(1,MSK4,MSK6), NULL, SMP_T_IPV6, 
> SMP_T_IPV6 },

You need to use SMP_T_ADDR instead of SMP_T_IPV6 in order to adapt to any
address family type and not enforce it. Maybe this is what led you to think
that you needed to convert ipv4 to ipv6.

Cheers,
Willy