Ok Bruce,
I found out what's happening.
I'm running a Suse 8.1 2.4.19 standard kernel which has IPV6 enabled by
default. When connecting locally over IP (pgaccess), hba is checked
against IPV6 patterns in pg_hba.conf.
My pgadmin2 machine will connect with an IP4-to-6 mapped address of
0:ffff:c0a80002 (192.168.0.2), which convSockAddr6to4 will convert to
dst->in.sin_addr.s_addr=0xc0a80002. On the other side, SockAddr_pton
will convert my 192.168.0.0/255.255.255.0 entry to a8c0/ffffff, and
consequently rangeSockAddr will fail.
If your kernel isn't V6 enabled, the incoming socket will be AF_INET,
and no conversion is done, that's why you don't get the problem.
To fix this, the [12]..[15] indices need to be reversed (for Intel).
This might be machine specific... Maybe for all big-endian machines the
current code is ok, and needs reversal for little-endian processors.
I wonder if the following is completely portable, could be:
dst->in.sin_addr.s_addr = *(in_addr_t*)(src->in4.sin6_addr.s6_addr+12);
Regards,
Andreas
PS Your mail host candle.pha.pa.us rejected this mail as spam?!?
Bruce Momjian wrote:
>That's strange. I just tested it here, and it worked. I have IPv6 code
>enabled. but no IPv6 in my kernel, so there are just IPv4 connections.
>
>Can you peek in this funciton and see where it is failing:
>
> int
> rangeSockAddrAF_INET(const SockAddr *addr, const SockAddr *netaddr,
> const SockAddr *netmask)
> {
> if (addr->sa.sa_family != AF_INET ||
> netaddr->sa.sa_family != AF_INET ||
> netmask->sa.sa_family != AF_INET)
> return 0;
> if (((addr->in.sin_addr.s_addr ^ netaddr->in.sin_addr.s_addr) &
> netmask->in.sin_addr.s_addr) == 0)
> return 1;
> else
> return 0;
> }
>
>That is the IPv4 function.
>
>
>
>
