7.4devel auth failed

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.

---------------------------------------------------------------------------

Andreas Pflug wrote:

Trying to connect from pgadmin2, I get the message
"no pg_hba.conf entry for ..."

I found that the ip address matching with rangeSockAdr in line 651 in
hba.c fails.

I get access if I set ipaddr/mask to 0.0.0.0/0.0.0.0 in pg_hba.conf.

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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:

I am confused about using only the last few bytes. Does this
adjustment of IP addresses help:

void
convSockAddr6to4(const SockAddr *src, SockAddr *dst)
{
char addr_str[INET6_ADDRSTRLEN];

dst->in.sin_family = AF_INET;
dst->in.sin_port = src->in6.sin6_port;

	    dst->in.sin_addr.s_addr =
	        (src->in6.sin6_addr.s6_addr[15])
	        + (src->in6.sin6_addr.s6_addr[14] << 8)
	        + (src->in6.sin6_addr.s6_addr[13] << 16)
	        + (src->in6.sin6_addr.s6_addr[12] << 24);
	    SockAddr_ntop(src, addr_str, INET6_ADDRSTRLEN, 0);
	}

Can you supply a patch?

FYI, I do have IPv6 enabled libraries, but not in my kernel.

PS Your mail host candle.pha.pa.us rejected this mail as spam?!?

I have whitelisted web.de. I received spam from them last month, and
didn't know if they were legit or just a spamhouse. Unfortunately, I
don't check each one I blacklist.

---------------------------------------------------------------------------

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
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.

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

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

Shouldn't the fix involve an appropriate use of ntohl or htonl,
instead of ad-hoc shifting?

regards, tom lane

On Wed, Mar 26, 2003 at 12:36:00AM +0100, Andreas Pflug wrote:

Kurt,

for my opinion, ConvSockAddr6to4 works wrong. The resulting ip address
looks good for the eye, but only if printed as an integer which will
interpret it little-endian (host byte order).

Oops, I didn't see that one.

convSockAddr6to4() is obviously wrong. There is where it gets
converted to host order where it shouldn't.

What is that SockAddr_ntop() doing there anyway? Maybe the
inteded code was a combination for SockAddr_ntop() and
SockAddr_pton()?

Kurt

Bruce Momjian writes:

I have whitelisted web.de. I received spam from them last month, and
didn't know if they were legit or just a spamhouse. Unfortunately, I
don't check each one I blacklist.

Maybe you should. You've blacklisted me, too.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut wrote:

Bruce Momjian writes:

I have whitelisted web.de. I received spam from them last month, and
didn't know if they were legit or just a spamhouse. Unfortunately, I
don't check each one I blacklist.

Maybe you should. You've blacklisted me, too.

OK, fixed. You know, I started getting email that is clearly grabbing
from our web page, titled "dpage, ...". Seems that might be how your
address got in. I will look at the next one and see if they appear to
be coming from the original hosts.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Andreas Pflug <Andreas.Pflug@web.de> writes:

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).

I've applied a patch to fix this, but can't try it out here for lack of
any IPv6 infrastructure ... please check it.

regards, tom lane

Looks like Tom just checked a fix into CVS for your reported problem.
Would you please test it?

---------------------------------------------------------------------------

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
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.

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tom Lane wrote:

I've applied a patch to fix this, but can't try it out here for lack of
any IPv6 infrastructure ... please check it.

regards, tom lane

I tried it, and it works.

Regards,

Andreas