Marc Lehmann wrote:
> when having two servers with the following link lines (without passwords
etc.):
<link name="server2" ipaddr="1.0.0.2"
<link name="server1" ipaddr="1.0.0.1"
I assume you intend to use 10.0.0.x. The address space 1.x.x.x is yet
unallocated,
but not for local use.
then despite trying to connect,t he other server will instantly close the
conenction, without logging a message:
accept(11, {sa_family=AF_INET6, sin6_port=htons(41545), inet_pton(AF_INET6,
"::ffff:1.0.0.1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 23
close(23) = 0
fcntl(23, F_GETFL) = -1 EBADF (Bad file descriptor)
fcntl(23, F_SETFL,
O_ACCMODE|O_CREAT|O_EXCL|O_NOCTTY|O_TRUNC|O_APPEND|O_NONBLOCK|O_SYNC|O_ASYNC|O_DIRECT|O_LARGEFILE|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|O_CLOEXEC|0xfff0003c)
= -1 EBADF (Bad file descriptor)
setsockopt(23, SOL_SOCKET, SO_SNDBUF, [32768], 4) = -1 EBADF (Bad file
descriptor)
The first problem here is that the socket gets close()ed first, and then
inspircd tries to access it - when any multithreadeds modules are in use,
this will poentially damage unrelated file descriptions under the same
file descriptor.
Yes. Could you provide the log of inspircd? It would be interesting to
understand why inspircd closed the connection.
Anyway I agree: it should not access a closes connection.
The second problem is that ipv4 addresses are not matched correctly -
inspircd will try to connect to the correct address, but the receiving
server requires specification of ::ffff:1.0.0.1 instead of just 1.0.0.1
for the ip address to match.
Note: One bug report per problem, so that it is easier to track.
Anyway, I think it is correct to have "::ffff:1.0.0.1": it use the
IPv6 notation. The libc and the kernel will handle such address correctly.
The advantage: we can use one API for both protocols (IPv6 and IPv4).
ciao
cate
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
