Peter Selinger
2007-Jan-08 02:08 UTC
[Nut-upsdev] Re: [nut-commits] svn commit r714 - in trunk: . server
OK, I have removed the autoconf test for s6_addr32 (which is no longer
used), and wrote a new test for IN6_IS_ADDR_V4MAPPED. The latter is
probably portable, but since we're already in the business of testing,
it does not hurt to do so.
Arjen, I wonder about server/access.c, line 60-61:
return (IN6_IS_ADDR_V4MAPPED(ip6) &&
((((const u_int32_t *)ip6)[3] & (u_int32_t)prefix) ==
net->s_addr));
Comparing this with line 38:
return((((struct sockaddr_in*)ip_addr)->sin_addr.s_addr &
htonl(prefix)) == ((struct sockaddr_in*)net_addr)->sin_addr.s_addr);
I wonder if it shouldn't be htonl(prefix) in line 61, or perhaps
ntohl(net->s_addr) in line 61. I don't understand these data
structures well, and presumably the patch came from someone who tested
it on a little-endian machine, but it seems to me from inet(3) that:
*.s_addr is in network byte order,
((const u_int32_t *)ip6)[3] is in network byte order (???)
prefix is in host byte order.
I cannot find the man page for struct in6_addr, so I am not sure about
the byte order of ip6, but it seems that if it's a byte array
converted to a int32 array, it should be big-endian.
-- Peter
Arjen de Korte wrote:>
> Author: adkorte-guest
> Date: Sun Jan 7 21:37:56 2007
> New Revision: 714
>
> Modified:
> trunk/ChangeLog
> trunk/server/access.c
> Log:
> - server/access.c: replaces previous patch (now uses IN6_IS_ADDR_V4MAPPED)
>
> Modified: trunk/ChangeLog
>
=============================================================================>
--- trunk/ChangeLog (original)
> +++ trunk/ChangeLog Sun Jan 7 21:37:56 2007
> @@ -1,3 +1,7 @@
> +Sun Jan 7 20:35:35 UTC 2007 / Arjen de Korte <arjen@de-korte.org>
> +
> + - server/access.c: replaces previous patch (now uses
IN6_IS_ADDR_V4MAPPED)
> +
> Sun Jan 7 19:28:57 UTC 2007 / Arjen de Korte <arjen@de-korte.org>
>
> - server/access.c: s6_addr32 is not portable, only s6_addr is
>
> Modified: trunk/server/access.c
>
=============================================================================>
--- trunk/server/access.c (original)
> +++ trunk/server/access.c Sun Jan 7 21:37:56 2007
> @@ -57,15 +57,8 @@
> struct in6_addr *ip6 = &((struct sockaddr_in6
*)ip_addr)->sin6_addr;
> struct in_addr *net = &((struct sockaddr_in
*)net_addr)->sin_addr;
>
> - return ((*(u_int32_t *)(&ip6->s6_addr[0]) == 0) &&
> - (*(u_int32_t *)(&ip6->s6_addr[4]) == 0) &&
> - /* (*(u_int32_t *)(&ip6->s6_addr[8]) == ntohl(0x0000ffff))
&& */
> -#if BYTE_ORDER == LITTLE_ENDIAN
> - (*(u_int32_t *)(&ip6->s6_addr[8]) == (u_int32_t)0xffff0000)
&&
> -#else
> - (*(u_int32_t *)(&ip6->s6_addr[8]) == (u_int32_t)0x0000ffff)
&&
> -#endif
> - ((*(u_int32_t *)(&ip6->s6_addr[12]) & (u_int32_t)prefix) ==
net->s_addr));
> + return (IN6_IS_ADDR_V4MAPPED(ip6) &&
> + ((((const u_int32_t *)ip6)[3] & (u_int32_t)prefix) ==
net->s_addr));
> }
> default:
> fatal_with_errno("mask_cmp: Unknown address family");
>
> _______________________________________________
> nut-commits mailing list
> nut-commits@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-commits
>
Arjen de Korte
2007-Jan-08 09:37 UTC
[Nut-upsdev] Re: [nut-commits] svn commit r714 - in trunk: . server
> OK, I have removed the autoconf test for s6_addr32 (which is no longer > used), and wrote a new test for IN6_IS_ADDR_V4MAPPED. The latter is > probably portable, but since we're already in the business of testing, > it does not hurt to do so.The macro is defined in RFC 2553 (and notably, AI_ADDRCONFIG too), so I think it should be portable. But until we're absolutely sure it is, testing for it is probably the right thing to do.> Arjen, I wonder about server/access.c, line 60-61: > > return (IN6_IS_ADDR_V4MAPPED(ip6) && > ((((const u_int32_t *)ip6)[3] & (u_int32_t)prefix) => net->s_addr)); > > Comparing this with line 38: > > return((((struct sockaddr_in*)ip_addr)->sin_addr.s_addr & > htonl(prefix)) == ((struct sockaddr_in*)net_addr)->sin_addr.s_addr); > > I wonder if it shouldn't be htonl(prefix) in line 61, or perhaps > ntohl(net->s_addr) in line 61. I don't understand these data > structures well, and presumably the patch came from someone who tested > it on a little-endian machine, but it seems to me from inet(3) that: > > *.s_addr is in network byte order, > ((const u_int32_t *)ip6)[3] is in network byte order (???) > prefix is in host byte order. > > I cannot find the man page for struct in6_addr, so I am not sure about > the byte order of ip6, but it seems that if it's a byte array > converted to a int32 array, it should be big-endian.You could be right, I didn't look at this. And neither did I for most other things that were introduced with the IPv6 patch. I only have a little endian machine available for testing, so trying this out is not an option. All this juggling with casting data from one type to the the other made my head spin after a couple of hours. :-) For me, the IPv6 patch seems to do what it needs to do, but it would be really useful to try this out on a big endian machine too. Best regards, Arjen -- Eindhoven - The Netherlands Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57
Henning Brauer
2007-Jan-08 10:27 UTC
[Nut-upsdev] Re: [nut-commits] svn commit r714 - in trunk: . server
* Peter Selinger <selinger@mathstat.dal.ca> [2007-01-08 02:09]:> OK, I have removed the autoconf test for s6_addr32 (which is no longer > used), and wrote a new test for IN6_IS_ADDR_V4MAPPED. The latter is > probably portable,should be portable, yes. but keep in mind that there are systems that (purposefully) do not support v4 mapped addresses. -- Henning Brauer, hb@bsws.de, henning@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam