Ipv6 connect taking long #307
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/znc#307
Reference in new issue
Block a user
For some reason connecting to my znc server over ipv6 works, but takes up to one minute to connect. It runs fine on Ipv4 though, instant connection.
Seems to be a bug, tested from 2 different machines. Server is hosted on a dedicated server, I am using a tunnelbroker.net HEnet ipv6 tunnel.
How long is SSH connection to your server?
About 1 to 2 seconds.
By both IPv4 and IPv6?
2014-03-13 10:28 GMT+00:00 Keridos notifications@github.com:
Yes, takes about 1 second longer with ipv6, but ZNC is taking a lot longer, more like 10-60 seconds
On my second pc it takes about 1 Minute to connect, on my main PC it takes about 15 seconds. The Main PC is quite a lot faster im terms of CPU, do not know if that relates to it.
I think that it may be caused by a failed revers ip check, it works for ipv4 on the server but not for ipv6.
Show znc --version
ZNC 1.2 - http://znc.in
IPv6: yes, SSL: yes, DNS: threads
Compiled it from source about 2 months ago.
Run
strace znc -Dand notice what happens when you're trying to connect via IPv4, and via IPv6.You mean
strace -tt znc -D, right?ran strace -tt znc -d and got this:
http://paste.ubuntu.com/7090232/
Now change your password to something else, as you didn't remove it from
paste and published it...
2014-03-14 13:29 GMT+00:00 Keridos notifications@github.com:
derp, did not notice that in that wall of text, thanks, changed it ...
There is not a single incoming ipv6 connection in there.
Incoming IPv4 connections at:
14:17:12.638277, fd 7, handhsake finished at 14:17:13.570717
14:17:12.664294, fd 8, handshake finished at 14:17:13.594572
14:27:04.115732, fd 7, ssl handshake finished (= first data received from client) at 14:27:05.046289
14:27:04.127797, fd 8, handshake till 14:27:05.079919
No successful outgoing connections in there, but something like a million failed one (I am exagerating). All of them fail due to a wrong IPv6 bindhost (bind() fails with EINVAL)
Edit: Whoops, mixed up some timestamps on my first try. Didn't notice that the first two clients disconnected
Had some derpup in the bindhosts that made that fail when i restarted. Since i removed it I can connect to IRC normally but the ipv6 connection still takes a longer time.
Here is a more recent log: First ipv6 connect, then ipv4.
http://paste.ubuntu.com/7090352/
Joining took noticable more time when connecting via ipv6, ipv4 was nearly instant.
Search for "datpw" when trying to find the login time.
Still no update? No one was able to find the cause of it?
109.91.114.9 doesn't look like IPv6...
The IPv6 connection from client, even it was attempted, didn't reach ZNC.
Does your client machine have working IPv6?
(nothing changed since psychon's reply)
10/10 for your IPv6 stability and readiness, when publishers are forced to go IPv6 only on test-ipv6.com and i can ping ipv6 addresses.
got the same issue from different IRC clients aswell, looks as if my weechat is having the same issue.
Seems it tries to connect via IPv6, that fails and it fallbacks to ipv4.
Another thing: In the webconfig the ipv6 listening is turned on for my port on BindHost *, but it does not seem as if it was actually listening at that address. Will I have to enable it via some tweak?
How did you check that “it does not seem”? The tweak is exactly “In the webconfig the ipv6 listening is turned on”
You can try telnet to localhost from that server, and from some other machine (including your client)
tunnelbroker.net blocks IRC traffic by default, see their FAQ https://ipv6.he.net/certification/faq.php.
Choosing another port worked for me too.
Yeah that was it, derp derp, closing the issue now, thanks for the help.