On Tue, Mar 25, 2003 at 12:28:43PM +0100, Andreas Pflug wrote:
> 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
You mean ::ffff:c0a8:0002 or ::ffff:192.168.0.2?
(::ffff:c0a80002 is not valid.)
> dst->in.sin_addr.s_addr=0xc0a80002.
Which is the right value for it.
> 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.
Something is wrong here. It somehow converted them to host byte
order where it shouldn't.
SockAddr_pton() basicly does:
return inet_pton(AF_INET, src, &sa->in.sin_addr);
Which should return the data in network byte order.
> 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);
Where should you place that?
I can't see anything wrong with the code as it is now. I think I
even tested it for ipv4 and it worked for me, so I have no idea
what's wrong.
I've made alot of changes to the current code but it's not
finnished yet, and really have no time atm. It currently only
compiles on a host that has ipv6 in libc. It shouldn't be too
much work to get it to compile on a host without ipv4.
Kurt
