ZNC-module fails, and returns errors from Csocket.cpp #47

Closed
jallakim opened this Issue May 24, 2011 · 13 comments

Projects

None yet

3 participants

@jallakim

When the colloquy-module tries to send a push-notification, it fails with the following error;

Csocket.cpp:882 Connect Failed. ERRNO [22] FD [11]
MOD::C::colloquy::efnet == SockError(Invalid argument)

Looking up that part in Csocket.cpp;

    if( !GetIPv6() )
        ret = connect( m_iReadSock, (struct sockaddr *)m_address.GetSockAddr(), m_address.GetSockAddrLen() );
#ifdef HAVE_IPV6
    else
        ret = connect( m_iReadSock, (struct sockaddr *)m_address.GetSockAddr6(), m_address.GetSockAddrLen6() );
#endif /* HAVE_IPV6 */
#ifndef _WIN32
    if ( ( ret == -1 ) && ( GetSockError() != EINPROGRESS ) )
#else
    if ( ( ret == -1 ) && ( GetSockError() != EINPROGRESS ) && ( GetSockError() != WSAEWOULDBLOCK ) )
#endif /* _WIN32 */

    {
        CS_DEBUG( "Connect Failed. ERRNO [" << GetSockError() << "] FD [" << m_iReadSock << "]" );
        return( false );
    }

I'm no programmer, but could my issue be caused by having IPv6-address with prefix /96? Or maybe something other related to my IPv6-setup?

A complete error-message from ZNC can be found here; http://home.komsys.org/~jocke/colloquypush-error.txt

@psychon
znc member

colloquy is an external module, not part of znc. Sorry.

Also, no idea why connect() fails with EINVAL here. Connecting to colloquy.mobi:7906 should work fine. That address doesn't even have an AAAA record. :-/

@psychon psychon closed this May 24, 2011
@jallakim

I don't know how things are glued together, or how colloquy uses Csocket.cpp, but the error-message deviates from Csocket.cpp, which would suggest the error being in Csocket.cpp? Anyhow, that's why I reported the issue here.

@psychon
znc member

Csocket is the socket abstraction used by znc. Technically, that's yet another seperate project. ;-)

Does this happen for everyone or just for you? Anyone bored enough to strace znc and figure out what the evil arguments to znc were? (strace -e connect znc --foreground --debug; then make it fail connect to colloquy.mobi)

@jallakim
Connecting to [colloquy.mobi:7906] to send...
----------------------------------------------------------------------------
{"device-token":"*snip*","message":"test","sender":"roflmao","badge": 1,"connection":"*snip*","server":"Freenode","sound":"Stoof.aiff"}
----------------------------------------------------------------------------
connect(9, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.10.101.220")}, 16) = 0
connect(8, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("174.121.1.253")}, 16) = -1 EINVAL (Invalid argument)
Csocket.cpp:882 Connect Failed. ERRNO [22] FD [8]
MOD::C::colloquy::freenode == SockError(Invalid argument)

174.121.1.253 is colloquy.mobi. It seems as it uses port 0 as it's destination, which should be 7906? (sin_port=htons(0) should be sin_port=htons(7906), yes?).

@jallakim

Okay, so I guess this discussion can be moved over to the colloquy-module itself.

wired/colloquypush#13

@psychon psychon reopened this May 28, 2011
@psychon psychon was assigned Jun 7, 2011
@psychon
znc member

Fixed:

commit 88e7f09
Author: Uli Schlachter psychon@znc.in
Date: Sun Jun 26 12:11:40 2011 +0200

Update to latest Csocket

Fixes:

- A possible crash bug for empty DNS replies with c-ares. E.g. a AAAA lookup for
  google.com doesn't give any reply but is still successful. This might be a
  c-ares bug (there is ARES_ENODATA) or c-ares just changed its behavior?
  (No bug report, just noticed accidentally)
- Connecting to ipv4-only hosts with a v6 bindhost caused weird errors:
  https://github.com/znc/znc/issues/47
- There was a pull request for some DSA server certificate thingy:
  https://github.com/znc/znc/pull/46
- Busy loop waiting for an SSL handshake to finish:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631590
- Some other stuff? No idea what some of the changes in here are actually doing.

Signed-off-by: Uli Schlachter <psychon@znc.in>
@psychon psychon closed this Jun 26, 2011
@jallakim

Great! Thanks!

\o/

@jallakim

So, the issue is still not resolved.

Connecting to [colloquy.mobi:7906] to send...
----------------------------------------------------------------------------
{"device-token":"*snip*","message":"test","sender":"roflmao","badge": 1,"connection":"*snip*","server":"Freenode","sound":"Stoof.aiff"}
----------------------------------------------------------------------------
connect(12, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.10.101.222")}, 16) = 0
connect(11, {sa_family=AF_INET, sin_port=htons(7906), sin_addr=inet_addr("174.121.1.253")}, 16) = -1 EINVAL (Invalid argument)
Csocket.cpp:886 Connect Failed. ERRNO [22] FD [11]
MOD::C::colloquy::freenode == SockError(Invalid argument)

I actually did some tests yesterday, where I had basically done the same change as this commit (setting both IPv4-port and IPv6-port), and it failed the same way. During the tests yesterday, I also had the added debug-part;


Connecting to [colloquy.mobi:7906] to send...
----------------------------------------------------------------------------
{"device-token":"*snip*","message":"test","sender":"roflmao","badge": 1,"connection":"*snip*","server":"Freenode","sound":"Stoof.aiff"}
----------------------------------------------------------------------------
Csocket.h:208 Setting IPv4-port to 0
Csocket.cpp:61 Setting v6 from 0 to 1 due to: Csock::getaddrinfo, got an IPv6
./znc[0x519eae]
./znc[0x519f0c]
./znc(_ZN5Csock11GetAddrInfoERK7CStringR10CSSockAddr+0x7b)[0x521cd7]
./znc(_ZN5Csock9DNSLookupENS_9EDNSLTypeE+0xbb)[0x5220a9]
./znc(_ZN14TSocketManagerI8CZNCSockE4LoopEv+0x9e)[0x54b10c]
./znc(_ZN14TSocketManagerI8CZNCSockE17DynamicSelectLoopEmml+0xde)[0x546088]
./znc(_ZN4CZNC4LoopEv+0x307)[0x52b9d3]
./znc(main+0x11b2)[0x506fc1]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f1fb5ac1c4d]
./znc[0x505429]
Csocket.h:204 Setting IPv6-port to 7906
Csocket.h:208 Setting IPv4-port to 7906
connect(12, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.10.101.222")}, 16) = 0
Csocket.cpp:61 Setting v6 from 1 to 0 due to: dns callback
./znc[0x519eae]
./znc[0x519f0c]
./znc[0x51a104]
/usr/lib/libcares.so.2(+0x3aa1)[0x7f1fb6ba9aa1]
/usr/lib/libcares.so.2(+0x3f75)[0x7f1fb6ba9f75]
/usr/lib/libcares.so.2(+0xaf27)[0x7f1fb6bb0f27]
/usr/lib/libcares.so.2(+0xb0cb)[0x7f1fb6bb10cb]
/usr/lib/libcares.so.2(+0xad33)[0x7f1fb6bb0d33]
/usr/lib/libcares.so.2(+0x97f0)[0x7f1fb6baf7f0]
/usr/lib/libcares.so.2(+0xa475)[0x7f1fb6bb0475]
/usr/lib/libcares.so.2(+0xa6d8)[0x7f1fb6bb06d8]
/usr/lib/libcares.so.2(+0xa974)[0x7f1fb6bb0974]
./znc(_ZN14TSocketManagerI8CZNCSockE6SelectERNSt7__debug3mapIPS0_NS1_9EMessagesESt4lessIS4_ESaISt4pairIKS4_S5_EEEE+0xa4a)[0x550de4]
./znc(_ZN14TSocketManagerI8CZNCSockE4LoopEv+0x489)[0x54b4f7]
./znc(_ZN14TSocketManagerI8CZNCSockE17DynamicSelectLoopEmml+0xde)[0x546088]
./znc(_ZN4CZNC4LoopEv+0x307)[0x52b9d3]
./znc(main+0x11b2)[0x506fc1]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f1fb5ac1c4d]
./znc[0x505429]
connect(11, {sa_family=AF_INET, sin_port=htons(7906), sin_addr=inet_addr("174.121.1.253")}, 16) = -1 EINVAL (Invalid argument)
Csocket.cpp:900 Connect Failed. ERRNO [22] FD [11]
MOD::C::colloquy::freenode == SockError(Invalid argument)
@jallakim

And just so it's been mentioned; I have a ZNC-user connecting to Bitlbee via IPv4 (so no IPv6 bindhost), and Colloquy-push works just fine on this one.

@jallakim

I don't mean to nag or anything, but this was never fixed. The issue is still present, as can be seen in my above post.

@psychon psychon reopened this Aug 17, 2011
@psychon
znc member

Argh, the bug that was fixed was the port number which was set to 0. The bug which is left is a duplicate of issue #37. Sorry 'bout that.

@kylef
znc member

Since this is a duplicate of #37, 717d059 should close this.

@kylef kylef closed this Jan 28, 2012
@jallakim

Hi,

Seems like I don't have permission to re-open this issue. Can someone else do it?

Nevertheless, this issue is not resolved. If you have a v6-only bindhost, Csocket fails to make a connection to a v4-only host).

[2012-05-06 03:04:36.284917] Connecting to [colloquy.mobi:7906] to send...
[2012-05-06 03:04:36.284989] ----------------------------------------------------------------------------
[2012-05-06 03:04:36.285036] {"device-token":"<snip>","message":"testing","sender":"<nick>","badge": 1,"connection":"<snip>","server":"Freenode","sound":"Stoof.aiff"}
[2012-05-06 03:04:36.285084] ----------------------------------------------------------------------------
[2012-05-06 03:04:36.285142] TDNS: initiating resolving of [colloquy.mobi] and bindhost [<IPv6-address>]
[2012-05-06 03:04:36.307553] MOD::C::colloquy::freenode, dns resolving error: Address family of bindhost doesn't match address family of server
[2012-05-06 03:04:36.307624] MOD::C::colloquy::freenode == SockError(Address family of bindhost doesn't match address family of server, Unknown error 18446744073709551615)

I know the error is "logical" in the sense that it's a v6-only bindhost trying to connect to a v4-only host. However, such a connection like this, shouldn't really rely on whatever settings the bindhost has, in my opinion. The system has a usable v4 address, so it should be able to use this, even though it only has a v6-bindhost.

Could one add some kind of option to allow it to use whatever IPv4 bindhost available, even if it's using a v6-only bindhost? Maybe even do something like this by default? Similar the other way around (if using v4-only bindhost, and trying to connect to v6-only host). Maybe like a 'primary v4 and v6 address' that it could fallback to, in case any failures like the above?

@kylef kylef pushed a commit to kylef/znc that referenced this issue Jun 3, 2013
@mxcl mxcl Work even when RUBYLIB='-'
Apparently setting RUBYLIB to '-' causes the library path to be unset. So we need to set our own library path in our scripts.

Fixes Homebrew/homebrew-versions/#47.
128a59c
@MrLenin MrLenin pushed a commit to evilnet/znc that referenced this issue Mar 29, 2014
@psychon psychon Update to latest Csocket
Fixes:

- A possible crash bug for empty DNS replies with c-ares. E.g. a AAAA lookup for
  google.com doesn't give any reply but is still successful. This might be a
  c-ares bug (there is ARES_ENODATA) or c-ares just changed its behavior?
  (No bug report, just noticed accidentally)
- Connecting to ipv4-only hosts with a v6 bindhost caused weird errors:
  znc/znc#47
- There was a pull request for some DSA server certificate thingy:
  znc/znc#46
- Busy loop waiting for an SSL handshake to finish:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631590
- Some other stuff? No idea what some of the changes in here are actually doing.

Signed-off-by: Uli Schlachter <psychon@znc.in>
88e7f09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment