On Thu, Sep 04, 2003 at 04:04:38PM -0400, Jan Wieck wrote:
>
> And I agree with Tom that it is very likely that the IPV4/IPV6 stuff is
> the reason. IIRC the postmaster creates the socket and noone ever does
> bind(2) on it - so it uses it's dynamically assigned port number. Both,
> the collector and the backends inherit that socket via fork(2).
Actually, it does a bind (to localhost), but send the port to 0,
so it gets the random port.
Then it connects to itself. I don't get the logic behind that
howver.
It does:
pgStatSock = socket(...);
bind(pgStatSock, ...);
getsockname(pgStatSock, ...);
connect(pgStatSock, ...);
So it creates a socket, binds to it, asks what address/port it's
bound to, and connects to that port.
I don't see the logic behind that connect(), how it can work, and
how it would block anybody from sending to it, but it seems to
work.
> The
> backends use this socket with it's own sockname to send the stats out,
> and the collector reads it with recvfrom(2) and verifies that the from
> address is identical to it's sockname ... that way noone can inject
> faked stat packets. Now this is a lot of sockname usage that could lead
> to either the packets not arriving in the collector, or being thrown
> away by the collector because of failing to see them coming from itself.
I'm trying to think about some kernel bug that sends packets
using the wrong source address ..., but I think that was
connecting to a local address it always showed the loopback
address.
It could be useful to have a warning at the following line:
if (memcmp(&fromaddr, &pgStatAddr, fromlen)) continue;
That way you can rule out that that is a problem.
Anyway, I still didn't see the error message he got in the first
place. Maybe we're looking at the wrong thing?
Kurt