Re: lua support does not build on FreeBSD

[Willy Tarreau]

On Fri, Dec 23, 2016 at 10:35:13PM +0100, thierry.fourn...@arpalert.org wrote:
> I return true if the largest network contains the smaller. The order of
> networks are not important.
> 
> I wrote this code a long time ago, I'm not remember exactly. Maybe I
> wrote bullshit.
> 
> I write this code for testing:
> 
> 7 a = core.parse_addr("192.168.1.0/24")
> 8 b = core.parse_addr("192.168.1.10/32")
> 9 
>10 print_r(core.match_addr(a, b))
>11 print_r(core.match_addr(b, a))
>12 
>13 a = core.parse_addr("193.168.1.0/24")
>14 b = core.parse_addr("192.168.1.10/32")
>15 
>16 print_r(core.match_addr(a, b))
>17 print_r(core.match_addr(b, a))
> 
> The result is:
> 
>(boolean) true
>(boolean) true
>(boolean) false
>(boolean) false
> 
> It is the expected result.

OK, then I'll have to recheck the code because I must be missing
something.

Thanks,
Willy

Re: lua support does not build on FreeBSD

[thierry . fournier]

On Fri, 23 Dec 2016 22:04:57 +0100
Willy Tarreau  wrote:

> On Fri, Dec 23, 2016 at 09:50:53PM +0100, thierry.fourn...@arpalert.org wrote:
> > On Fri, 23 Dec 2016 18:07:07 +0100
> > Willy Tarreau  wrote:
> > 
> > > On Fri, Dec 23, 2016 at 05:54:47PM +0100, thierry.fourn...@arpalert.org 
> > > wrote:
> > > > Thanks ! Willy, can you apply the patch ?
> > > 
> > > Done, thanks guys.
> > > 
> > > However Thierry my previous question still stands : what *real* type of 
> > > test
> > > is this supposed to validate ? Because in my opinion this test consisting 
> > > in
> > > matching that two networks are part of each other only validates that they
> > > are equal, or certain random cases where the smallest one happens to have
> > > zeroes where it matches the other one.
> > 
> > 
> > It is a comparaison of two networks. One of the network can be
> > condsidered as an IP (/32). The function returns true if one of the
> > network contains the other.
> 
> From what I remember from the code, it returns true if both of them
> contain each other, which is why I claim it cannot work. For example,
> 192.168.1.0/24 contains 192.168.1.10/32 but not the other way around.


I return true if the largest network contains the smaller. The order of
networks are not important.

I wrote this code a long time ago, I'm not remember exactly. Maybe I
wrote bullshit.

I write this code for testing:

7 a = core.parse_addr("192.168.1.0/24")
8 b = core.parse_addr("192.168.1.10/32")
9 
   10 print_r(core.match_addr(a, b))
   11 print_r(core.match_addr(b, a))
   12 
   13 a = core.parse_addr("193.168.1.0/24")
   14 b = core.parse_addr("192.168.1.10/32")
   15 
   16 print_r(core.match_addr(a, b))
   17 print_r(core.match_addr(b, a))

The result is:

   (boolean) true
   (boolean) true
   (boolean) false
   (boolean) false

It is the expected result.

Thierry

Re: lua support does not build on FreeBSD

[Willy Tarreau]

On Fri, Dec 23, 2016 at 09:50:53PM +0100, thierry.fourn...@arpalert.org wrote:
> On Fri, 23 Dec 2016 18:07:07 +0100
> Willy Tarreau  wrote:
> 
> > On Fri, Dec 23, 2016 at 05:54:47PM +0100, thierry.fourn...@arpalert.org 
> > wrote:
> > > Thanks ! Willy, can you apply the patch ?
> > 
> > Done, thanks guys.
> > 
> > However Thierry my previous question still stands : what *real* type of test
> > is this supposed to validate ? Because in my opinion this test consisting in
> > matching that two networks are part of each other only validates that they
> > are equal, or certain random cases where the smallest one happens to have
> > zeroes where it matches the other one.
> 
> 
> It is a comparaison of two networks. One of the network can be
> condsidered as an IP (/32). The function returns true if one of the
> network contains the other.

>From what I remember from the code, it returns true if both of them
contain each other, which is why I claim it cannot work. For example,
192.168.1.0/24 contains 192.168.1.10/32 but not the other way around.
X-Bogosity: Unsure, tests=bogofilter, spamicity=0.496770, version=1.2.4

Willy

Re: lua support does not build on FreeBSD

[Willy Tarreau]

On Fri, Dec 23, 2016 at 05:54:47PM +0100, thierry.fourn...@arpalert.org wrote:
> Thanks ! Willy, can you apply the patch ?

Done, thanks guys.

However Thierry my previous question still stands : what *real* type of test
is this supposed to validate ? Because in my opinion this test consisting in
matching that two networks are part of each other only validates that they
are equal, or certain random cases where the smallest one happens to have
zeroes where it matches the other one.

Do you have a concrete example of its use case ?

Thanks,
Willy

Re: lua support does not build on FreeBSD

[thierry . fournier]

Thanks ! Willy, can you apply the patch ?


On Fri, 23 Dec 2016 19:47:10 +0300
Dmitry Sivachenko  wrote:

> 
> > On 23 Dec 2016, at 19:07, thierry.fourn...@arpalert.org wrote:
> > 
> > Ok, thanks Willy.
> > 
> > The news path in attachment. David, can you test the FreeBSD build ?
> > The patch is tested and validated for Linux.
> 
> 
> 
> Yes, it does fix FreeBSD build.
> 
> 
> 
> > 
> > Thierry
> > 
> > 
> > On Fri, 23 Dec 2016 14:50:38 +0100
> > Willy Tarreau  wrote:
> > 
> >> On Fri, Dec 23, 2016 at 02:37:13PM +0100, thierry.fourn...@arpalert.org 
> >> wrote:
> >>> thanks Willy for the idea. I will write a patch ASAP, but. why a 32bits
> >>> cast and not a 64 bit cast ?
> >> 
> >> First because existing code uses this already and it works. Second because
> >> the 64-bit check might be more expensive for 32-bit platforms than the
> >> double 32-bit check is for 64-bit platforms (though that's still to be
> >> verified in the assembly code, as some compilers manage to assign register
> >> pairs correctly).
> >> 
> >> Willy
> >> 
> > <0001-BUILD-lua-build-failed-on-FreeBSD.patch>
> 
>From d5995d34504daf2a66a6b046ecd5da0477f6036e Mon Sep 17 00:00:00 2001
From: Thierry FOURNIER 
Date: Fri, 23 Dec 2016 17:03:25 +0100
Subject: [PATCH] BUILD: lua: build failed on FreeBSD.
X-Bogosity: Ham, tests=bogofilter, spamicity=0.00, version=1.2.4

s6_addr* fields are not available in the userland on
BSD systems in general.

bug reported by David Carlier

needs backport to 1.7.x
---
 src/hlua_fcn.c |   18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/src/hlua_fcn.c b/src/hlua_fcn.c
index 5ac533a..58905d7 100644
--- a/src/hlua_fcn.c
+++ b/src/hlua_fcn.c
@@ -1016,14 +1016,16 @@ int hlua_match_addr(lua_State *L)
 			return 1;
 		}
 	} else {
-		if (((addr1->addr.v6.ip.s6_addr32[0] & addr2->addr.v6.mask.s6_addr32[0]) ==
-		 (addr2->addr.v6.ip.s6_addr32[0] & addr1->addr.v6.mask.s6_addr32[0])) &&
-		((addr1->addr.v6.ip.s6_addr32[1] & addr2->addr.v6.mask.s6_addr32[1]) ==
-		 (addr2->addr.v6.ip.s6_addr32[1] & addr1->addr.v6.mask.s6_addr32[1])) &&
-		((addr1->addr.v6.ip.s6_addr32[2] & addr2->addr.v6.mask.s6_addr32[2]) ==
-		 (addr2->addr.v6.ip.s6_addr32[2] & addr1->addr.v6.mask.s6_addr32[2])) &&
-		((addr1->addr.v6.ip.s6_addr32[3] & addr2->addr.v6.mask.s6_addr32[3]) ==
-		 (addr2->addr.v6.ip.s6_addr32[3] & addr1->addr.v6.mask.s6_addr32[3]))) {
+		int i;
+
+		for (i = 0; i < 16; i += 4) {
+			if ((*(uint32_t *)>addr.v6.ip.s6_addr[i] &
+			 *(uint32_t *)>addr.v6.mask.s6_addr[i]) !=
+			(*(uint32_t *)>addr.v6.ip.s6_addr[i] &
+			 *(uint32_t *)>addr.v6.mask.s6_addr[i]))
+break;
+		}
+		if (i == 16) {
 			lua_pushboolean(L, 1);
 			return 1;
 		}
-- 
1.7.10.4

Re: lua support does not build on FreeBSD

[Dmitry Sivachenko]

> On 23 Dec 2016, at 19:07, thierry.fourn...@arpalert.org wrote:
> 
> Ok, thanks Willy.
> 
> The news path in attachment. David, can you test the FreeBSD build ?
> The patch is tested and validated for Linux.



Yes, it does fix FreeBSD build.



> 
> Thierry
> 
> 
> On Fri, 23 Dec 2016 14:50:38 +0100
> Willy Tarreau  wrote:
> 
>> On Fri, Dec 23, 2016 at 02:37:13PM +0100, thierry.fourn...@arpalert.org 
>> wrote:
>>> thanks Willy for the idea. I will write a patch ASAP, but. why a 32bits
>>> cast and not a 64 bit cast ?
>> 
>> First because existing code uses this already and it works. Second because
>> the 64-bit check might be more expensive for 32-bit platforms than the
>> double 32-bit check is for 64-bit platforms (though that's still to be
>> verified in the assembly code, as some compilers manage to assign register
>> pairs correctly).
>> 
>> Willy
>> 
> <0001-BUILD-lua-build-failed-on-FreeBSD.patch>

Re: lua support does not build on FreeBSD

[thierry . fournier]

Ok, thanks Willy.

The news path in attachment. David, can you test the FreeBSD build ?
The patch is tested and validated for Linux.

Thierry


On Fri, 23 Dec 2016 14:50:38 +0100
Willy Tarreau  wrote:

> On Fri, Dec 23, 2016 at 02:37:13PM +0100, thierry.fourn...@arpalert.org wrote:
> > thanks Willy for the idea. I will write a patch ASAP, but. why a 32bits
> > cast and not a 64 bit cast ?
> 
> First because existing code uses this already and it works. Second because
> the 64-bit check might be more expensive for 32-bit platforms than the
> double 32-bit check is for 64-bit platforms (though that's still to be
> verified in the assembly code, as some compilers manage to assign register
> pairs correctly).
> 
> Willy
> 
>From d5995d34504daf2a66a6b046ecd5da0477f6036e Mon Sep 17 00:00:00 2001
From: Thierry FOURNIER 
Date: Fri, 23 Dec 2016 17:03:25 +0100
Subject: [PATCH] BUILD: lua: build failed on FreeBSD.
X-Bogosity: Ham, tests=bogofilter, spamicity=0.00, version=1.2.4

s6_addr* fields are not available in the userland on
BSD systems in general.

bug reported by David Carlier

needs backport to 1.7.x
---
 src/hlua_fcn.c |   18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/src/hlua_fcn.c b/src/hlua_fcn.c
index 5ac533a..58905d7 100644
--- a/src/hlua_fcn.c
+++ b/src/hlua_fcn.c
@@ -1016,14 +1016,16 @@ int hlua_match_addr(lua_State *L)
 			return 1;
 		}
 	} else {
-		if (((addr1->addr.v6.ip.s6_addr32[0] & addr2->addr.v6.mask.s6_addr32[0]) ==
-		 (addr2->addr.v6.ip.s6_addr32[0] & addr1->addr.v6.mask.s6_addr32[0])) &&
-		((addr1->addr.v6.ip.s6_addr32[1] & addr2->addr.v6.mask.s6_addr32[1]) ==
-		 (addr2->addr.v6.ip.s6_addr32[1] & addr1->addr.v6.mask.s6_addr32[1])) &&
-		((addr1->addr.v6.ip.s6_addr32[2] & addr2->addr.v6.mask.s6_addr32[2]) ==
-		 (addr2->addr.v6.ip.s6_addr32[2] & addr1->addr.v6.mask.s6_addr32[2])) &&
-		((addr1->addr.v6.ip.s6_addr32[3] & addr2->addr.v6.mask.s6_addr32[3]) ==
-		 (addr2->addr.v6.ip.s6_addr32[3] & addr1->addr.v6.mask.s6_addr32[3]))) {
+		int i;
+
+		for (i = 0; i < 16; i += 4) {
+			if ((*(uint32_t *)>addr.v6.ip.s6_addr[i] &
+			 *(uint32_t *)>addr.v6.mask.s6_addr[i]) !=
+			(*(uint32_t *)>addr.v6.ip.s6_addr[i] &
+			 *(uint32_t *)>addr.v6.mask.s6_addr[i]))
+break;
+		}
+		if (i == 16) {
 			lua_pushboolean(L, 1);
 			return 1;
 		}
-- 
1.7.10.4

Re: lua support does not build on FreeBSD

[Willy Tarreau]

On Fri, Dec 23, 2016 at 02:37:13PM +0100, thierry.fourn...@arpalert.org wrote:
> thanks Willy for the idea. I will write a patch ASAP, but. why a 32bits
> cast and not a 64 bit cast ?

First because existing code uses this already and it works. Second because
the 64-bit check might be more expensive for 32-bit platforms than the
double 32-bit check is for 64-bit platforms (though that's still to be
verified in the assembly code, as some compilers manage to assign register
pairs correctly).

Willy

Re: lua support does not build on FreeBSD

[thierry . fournier]

On Wed, 21 Dec 2016 15:44:49 +0100
Willy Tarreau  wrote:

> Hi guys,
> 
> so I've looked a little bit at this and can propose something different.
> 
> On Wed, Dec 14, 2016 at 02:59:50PM +, David CARLIER wrote:
> > Hi,
> > 
> > On 14 December 2016 at 14:48,   wrote:
> > > Hi, thanks for the patch.
> > >
> > > Maybe it is more efficient to simply add a "#define _KERNEL", or the
> > > following code:
> > >
> > > #if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
> > > #define _KERNEL
> > > #endif
> > >
> > 
> > It is easy (and temptating) but not a good practice ... in my opinion :-)
> 
> I find this ugly as well and would prefer to avoid it. The main reason
> it was done is to ensure userspace does *not* use it so we can't claim
> it to be an accident.
> 
> > > I'm not sure that src_hlua.c was the good file for adding these
> > > kinds of defines or includes. Even if these defines are used only in
> > > this file, I suppose that it should be used in other file (in the
> > > future).
> > >
> > 
> > I was not sure myself, I hesitated to put it in one of the headers ...
> > let me know what you all think.
> 
> I'm seeing that in pattern.c we have the same but the entry is called
> "s6_addr", and nobody has ever complained that pattern.c did not build
> since 1.5 or so. Thus in my opinion the correct fix would be to replace
> all those s6_addr32[] with s6_addr[], eg (for 32-bit use) :
> 
>  (*(uint32_t*)>data.u.ipv6.s6_addr[0]
> 
> Thus it would give this :
> 
> 
> diff --git a/src/hlua_fcn.c b/src/hlua_fcn.c
> index 5ac533a..97a4d51 100644
> --- a/src/hlua_fcn.c
> +++ b/src/hlua_fcn.c
> @@ -1016,14 +1016,16 @@ int hlua_match_addr(lua_State *L)
>   return 1;
>   }
>   } else {
> - if (((addr1->addr.v6.ip.s6_addr32[0] & 
> addr2->addr.v6.mask.s6_addr32[0]) ==
> -  (addr2->addr.v6.ip.s6_addr32[0] & 
> addr1->addr.v6.mask.s6_addr32[0])) &&
> - ((addr1->addr.v6.ip.s6_addr32[1] & 
> addr2->addr.v6.mask.s6_addr32[1]) ==
> -  (addr2->addr.v6.ip.s6_addr32[1] & 
> addr1->addr.v6.mask.s6_addr32[1])) &&
> - ((addr1->addr.v6.ip.s6_addr32[2] & 
> addr2->addr.v6.mask.s6_addr32[2]) ==
> -  (addr2->addr.v6.ip.s6_addr32[2] & 
> addr1->addr.v6.mask.s6_addr32[2])) &&
> - ((addr1->addr.v6.ip.s6_addr32[3] & 
> addr2->addr.v6.mask.s6_addr32[3]) ==
> -  (addr2->addr.v6.ip.s6_addr32[3] & 
> addr1->addr.v6.mask.s6_addr32[3]))) {
> + int i;
> +
> + for (i = 0; i < 16; i += 4) {
> + if ((*(uint32_t *)>addr.v6.ip.s6_addr[i] &
> +  *(uint32_t *)>addr.v6.mask.s6_addr[i]) !=
> + (*(uint32_t *)>addr.v6.ip.s6_addr[i] &
> +  *(uint32_t *)>addr.v6.mask.s6_addr[i]))
> + break;
> + }
> + if (i == 16) {
>   lua_pushboolean(L, 1);
>   return 1;
>   }


Hi,

thanks Willy for the idea. I will write a patch ASAP, but. why a 32bits
cast and not a 64 bit cast ?

Thierry


> Also I'm a bot bothered by something I don't understand in the current
> code : we have two masks and we apply one address to the other address'
> mask. In fact I don't understand the intended operation, even after
> reading the doc. The doc says :
> 
>   Match two networks. For example "127.0.0.1/32" matchs "127.0.0.0/8".
>   The order of network is not important.
> 
> And for me this is a perfect example where it's wrong because that doesn't
> make sense. None of this network "match" the other one. The first one is
> included in the second one and not the opposite. I suspect we have
> something deeply wrong there but with a small impact which requires a fix.
> 
> Can someone enlighten me ?
> 
> Willy

Re: lua support does not build on FreeBSD

[Willy Tarreau]

Hi guys,

so I've looked a little bit at this and can propose something different.

On Wed, Dec 14, 2016 at 02:59:50PM +, David CARLIER wrote:
> Hi,
> 
> On 14 December 2016 at 14:48,   wrote:
> > Hi, thanks for the patch.
> >
> > Maybe it is more efficient to simply add a "#define _KERNEL", or the
> > following code:
> >
> > #if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
> > #define _KERNEL
> > #endif
> >
> 
> It is easy (and temptating) but not a good practice ... in my opinion :-)

I find this ugly as well and would prefer to avoid it. The main reason
it was done is to ensure userspace does *not* use it so we can't claim
it to be an accident.

> > I'm not sure that src_hlua.c was the good file for adding these
> > kinds of defines or includes. Even if these defines are used only in
> > this file, I suppose that it should be used in other file (in the
> > future).
> >
> 
> I was not sure myself, I hesitated to put it in one of the headers ...
> let me know what you all think.

I'm seeing that in pattern.c we have the same but the entry is called
"s6_addr", and nobody has ever complained that pattern.c did not build
since 1.5 or so. Thus in my opinion the correct fix would be to replace
all those s6_addr32[] with s6_addr[], eg (for 32-bit use) :

 (*(uint32_t*)>data.u.ipv6.s6_addr[0]

Thus it would give this :


diff --git a/src/hlua_fcn.c b/src/hlua_fcn.c
index 5ac533a..97a4d51 100644
--- a/src/hlua_fcn.c
+++ b/src/hlua_fcn.c
@@ -1016,14 +1016,16 @@ int hlua_match_addr(lua_State *L)
return 1;
}
} else {
-   if (((addr1->addr.v6.ip.s6_addr32[0] & 
addr2->addr.v6.mask.s6_addr32[0]) ==
-(addr2->addr.v6.ip.s6_addr32[0] & 
addr1->addr.v6.mask.s6_addr32[0])) &&
-   ((addr1->addr.v6.ip.s6_addr32[1] & 
addr2->addr.v6.mask.s6_addr32[1]) ==
-(addr2->addr.v6.ip.s6_addr32[1] & 
addr1->addr.v6.mask.s6_addr32[1])) &&
-   ((addr1->addr.v6.ip.s6_addr32[2] & 
addr2->addr.v6.mask.s6_addr32[2]) ==
-(addr2->addr.v6.ip.s6_addr32[2] & 
addr1->addr.v6.mask.s6_addr32[2])) &&
-   ((addr1->addr.v6.ip.s6_addr32[3] & 
addr2->addr.v6.mask.s6_addr32[3]) ==
-(addr2->addr.v6.ip.s6_addr32[3] & 
addr1->addr.v6.mask.s6_addr32[3]))) {
+   int i;
+
+   for (i = 0; i < 16; i += 4) {
+   if ((*(uint32_t *)>addr.v6.ip.s6_addr[i] &
+*(uint32_t *)>addr.v6.mask.s6_addr[i]) !=
+   (*(uint32_t *)>addr.v6.ip.s6_addr[i] &
+*(uint32_t *)>addr.v6.mask.s6_addr[i]))
+   break;
+   }
+   if (i == 16) {
lua_pushboolean(L, 1);
return 1;
}

Also I'm a bot bothered by something I don't understand in the current
code : we have two masks and we apply one address to the other address'
mask. In fact I don't understand the intended operation, even after
reading the doc. The doc says :

  Match two networks. For example "127.0.0.1/32" matchs "127.0.0.0/8".
  The order of network is not important.

And for me this is a perfect example where it's wrong because that doesn't
make sense. None of this network "match" the other one. The first one is
included in the second one and not the opposite. I suspect we have
something deeply wrong there but with a small impact which requires a fix.

Can someone enlighten me ?

Willy

Re: lua support does not build on FreeBSD

[thierry . fournier]

Hi, thanks for the patch.

Maybe it is more efficient to simply add a "#define _KERNEL", or the
following code:

#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
#define _KERNEL
#endif

I'm not sure that src_hlua.c was the good file for adding these
kinds of defines or includes. Even if these defines are used only in
this file, I suppose that it should be used in other file (in the
future).

unfortunately, pattern mathing use only the length in bits of the mask.
I can't compare.

Maybe Willy have an opinion about this ?

Thierry


On Wed, 14 Dec 2016 13:42:26 +
David CARLIER  wrote:

> On Linux it s also an "alias" if I m not mistaken, someone might
> confirm it or not though. Kind regards.
> 
> On 14 December 2016 at 13:32, Dmitry Sivachenko  wrote:
> >
> >> On 14 Dec 2016, at 16:24, David CARLIER  wrote:
> >>
> >> Hi,
> >>
> >> I ve made a small patch for 1.8 branch though. Does it suit ? (ie I
> >> made all the fields available, not sure if would be useful one day).
> >>
> >
> > Well, I was not sure what this s6_addr32 is used for and if it is possible 
> > to avoid it's usage (since it is linux-specific).
> > If not, then this is probably the correct solution.
> >
> 

Re: lua support does not build on FreeBSD

[David CARLIER]

Hi,

On 14 December 2016 at 14:48,   wrote:
> Hi, thanks for the patch.
>
> Maybe it is more efficient to simply add a "#define _KERNEL", or the
> following code:
>
> #if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
> #define _KERNEL
> #endif
>

It is easy (and temptating) but not a good practice ... in my opinion :-)

> I'm not sure that src_hlua.c was the good file for adding these
> kinds of defines or includes. Even if these defines are used only in
> this file, I suppose that it should be used in other file (in the
> future).
>

I was not sure myself, I hesitated to put it in one of the headers ...
let me know what you all think.

Cheers.

> unfortunately, pattern mathing use only the length in bits of the mask.
> I can't compare.
>
> Maybe Willy have an opinion about this ?
>
> Thierry
>
>
> On Wed, 14 Dec 2016 13:42:26 +
> David CARLIER  wrote:
>
>> On Linux it s also an "alias" if I m not mistaken, someone might
>> confirm it or not though. Kind regards.
>>
>> On 14 December 2016 at 13:32, Dmitry Sivachenko  wrote:
>> >
>> >> On 14 Dec 2016, at 16:24, David CARLIER  wrote:
>> >>
>> >> Hi,
>> >>
>> >> I ve made a small patch for 1.8 branch though. Does it suit ? (ie I
>> >> made all the fields available, not sure if would be useful one day).
>> >>
>> >
>> > Well, I was not sure what this s6_addr32 is used for and if it is possible 
>> > to avoid it's usage (since it is linux-specific).
>> > If not, then this is probably the correct solution.
>> >
>>

Re: lua support does not build on FreeBSD

[David CARLIER]

On Linux it s also an "alias" if I m not mistaken, someone might
confirm it or not though. Kind regards.

On 14 December 2016 at 13:32, Dmitry Sivachenko  wrote:
>
>> On 14 Dec 2016, at 16:24, David CARLIER  wrote:
>>
>> Hi,
>>
>> I ve made a small patch for 1.8 branch though. Does it suit ? (ie I
>> made all the fields available, not sure if would be useful one day).
>>
>
> Well, I was not sure what this s6_addr32 is used for and if it is possible to 
> avoid it's usage (since it is linux-specific).
> If not, then this is probably the correct solution.
>

Re: lua support does not build on FreeBSD

[Dmitry Sivachenko]

> On 14 Dec 2016, at 16:24, David CARLIER  wrote:
> 
> Hi,
> 
> I ve made a small patch for 1.8 branch though. Does it suit ? (ie I
> made all the fields available, not sure if would be useful one day).
> 

Well, I was not sure what this s6_addr32 is used for and if it is possible to 
avoid it's usage (since it is linux-specific).
If not, then this is probably the correct solution. 

lua support does not build on FreeBSD

[David CARLIER]

Hi,

I ve made a small patch for 1.8 branch though. Does it suit ? (ie I
made all the fields available, not sure if would be useful one day).

Kind regards.
From 7dff470cdbe0ea00ce78b504e95f8c639a11a365 Mon Sep 17 00:00:00 2001
From: David CARLIER 
Date: Wed, 14 Dec 2016 13:17:04 +
Subject: [PATCH] BUG/MINOR: hlua: *bsd fix

s6_addr* fields are not available in the userland on
BSD systems in general. needs backport to 1.7.x
---
 src/hlua_fcn.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/hlua_fcn.c b/src/hlua_fcn.c
index 5ac533a0..6892fdaf 100644
--- a/src/hlua_fcn.c
+++ b/src/hlua_fcn.c
@@ -39,6 +39,12 @@ static int class_listener_ref;
 
 #define STATS_LEN (MAX((int)ST_F_TOTAL_FIELDS, (int)INF_TOTAL_FIELDS))
 
+#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
+#define s6_addr8	__u6_addr.__u6_addr8
+#define s6_addr16	__u6_addr.__u6_addr16
+#define s6_addr32	__u6_addr.__u6_addr32
+#endif
+
 static struct field stats[STATS_LEN];
 
 int hlua_checkboolean(lua_State *L, int index)
-- 
2.11.0

lua support does not build on FreeBSD

[Dmitry Sivachenko]

Hello,

I am unable to build haproxy-1.7.x on FreeBSD:

cc -Iinclude -Iebtree -Wall -O2 -pipe -O2 -fno-strict-aliasing -pipe  
-fstack-protector   -DFREEBSD_PORTS-DTPROXY -DCONFIG_HAP_CRYPT 
-DUSE_GETADDRINFO -DUSE_ZLIB  -DENABLE_POLL -DENABLE_KQUEUE -DUSE_CPU_AFFINITY 
-DUSE_OPENSSL  -DUSE_LUA -I/usr/local/include/lua53 -DUSE_DEVICEATLAS 
-I/place/WRK/ports/net/haproxy/work/deviceatlas-enterprise-c-2.1 -DUSE_PCRE 
-I/usr/local/include -DUSE_PCRE_JIT  -DCONFIG_HAPROXY_VERSION=\"1.7.1\" 
-DCONFIG_HAPROXY_DATE=\"2016/12/13\" -c -o src/hlua_fcn.o src/hlua_fcn.c
src/hlua_fcn.c:1019:27: error: no member named 's6_addr32' in 'struct in6_addr'
if (((addr1->addr.v6.ip.s6_addr32[0] & addr2->addr.v6.ma...
  ~ ^
src/hlua_fcn.c:1019:62: error: no member named 's6_addr32' in 'struct in6_addr'
  ...if (((addr1->addr.v6.ip.s6_addr32[0] & addr2->addr.v6.mask.s6_addr32[0]...
~~~ ^
src/hlua_fcn.c:1020:27: error: no member named 's6_addr32' in 'struct in6_addr'
 (addr2->addr.v6.ip.s6_addr32[0] & addr1->addr.v6.ma...
  ~ ^
src/hlua_fcn.c:1020:62: error: no member named 's6_addr32' in 'struct in6_addr'
  ...(addr2->addr.v6.ip.s6_addr32[0] & addr1->addr.v6.mask.s6_addr32[0])) &&
   ~~~ ^
src/hlua_fcn.c:1021:27: error: no member named 's6_addr32' in 'struct in6_addr'
((addr1->addr.v6.ip.s6_addr32[1] & addr2->addr.v6.ma...
  ~ ^
src/hlua_fcn.c:1021:62: error: no member named 's6_addr32' in 'struct in6_addr'
  ...((addr1->addr.v6.ip.s6_addr32[1] & addr2->addr.v6.mask.s6_addr32[1]) ==
~~~ ^
src/hlua_fcn.c:1022:27: error: no member named 's6_addr32' in 'struct in6_addr'
 (addr2->addr.v6.ip.s6_addr32[1] & addr1->addr.v6.ma...
  ~ ^
src/hlua_fcn.c:1022:62: error: no member named 's6_addr32' in 'struct in6_addr'
  ...(addr2->addr.v6.ip.s6_addr32[1] & addr1->addr.v6.mask.s6_addr32[1])) &&
   ~~~ ^
src/hlua_fcn.c:1023:27: error: no member named 's6_addr32' in 'struct in6_addr'
((addr1->addr.v6.ip.s6_addr32[2] & addr2->addr.v6.ma...
  ~ ^
src/hlua_fcn.c:1023:62: error: no member named 's6_addr32' in 'struct in6_addr'
  ...((addr1->addr.v6.ip.s6_addr32[2] & addr2->addr.v6.mask.s6_addr32[2]) ==
~~~ ^
src/hlua_fcn.c:1024:27: error: no member named 's6_addr32' in 'struct in6_addr'
 (addr2->addr.v6.ip.s6_addr32[2] & addr1->addr.v6.ma...
  ~ ^
src/hlua_fcn.c:1024:62: error: no member named 's6_addr32' in 'struct in6_addr'
  ...(addr2->addr.v6.ip.s6_addr32[2] & addr1->addr.v6.mask.s6_addr32[2])) &&
   ~~~ ^
src/hlua_fcn.c:1025:27: error: no member named 's6_addr32' in 'struct in6_addr'
((addr1->addr.v6.ip.s6_addr32[3] & addr2->addr.v6.ma...
  ~ ^
src/hlua_fcn.c:1025:62: error: no member named 's6_addr32' in 'struct in6_addr'
  ...((addr1->addr.v6.ip.s6_addr32[3] & addr2->addr.v6.mask.s6_addr32[3]) ==
~~~ ^
src/hlua_fcn.c:1026:27: error: no member named 's6_addr32' in 'struct in6_addr'
 (addr2->addr.v6.ip.s6_addr32[3] & addr1->addr.v6.ma...
  ~ ^
src/hlua_fcn.c:1026:62: error: no member named 's6_addr32' in 'struct in6_addr'
  ...(addr2->addr.v6.ip.s6_addr32[3] & addr1->addr.v6.mask.s6_addr32[3]))) {
   ~~~ ^
16 errors generated.




In netinet6/in6.h I see:

#ifdef _KERNEL  /* XXX nonstandard */
#define s6_addr8  __u6_addr.__u6_addr8
#define s6_addr16 __u6_addr.__u6_addr16
#define s6_addr32 __u6_addr.__u6_addr32
#endif


So it seems that s6_addr32 macro is defined only when this header is included 
during kernel build.