New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

$::servers issue with passwords; DNS failure #503

Closed
ghost opened this Issue Jan 8, 2018 · 10 comments

Comments

Projects
None yet
2 participants
@ghost

ghost commented Jan 8, 2018

$::servers normally preserves a space (by creating an extra TCL list element, index 1) to keep a server's local name. The problem is: when using a server with a port and password, the entry becomes a corrupted multi-element list that fails the DNS look-up.

set servers server-IP:6667:password
... immediately followed by this PUTLOG line:
putlog "Servers: $::servers"
[01:40:58] Servers: {server-IP:6667:password } <--- note the extra space
... no other changes to $::servers occurs ...
[01:41:02] Trying server [server-IP:6667:password ]:6667 <--- note the extra space, the unnecessary "[]" square brackets, and extra ":6667"
[01:41:02] DNS Resolver: Used failed record: server-IP:6667:password == ??? <--- notice double (extra) space here
[01:41:02] Failed connect to server-IP:6667:password (DNS lookup failed) <--- note the double (extra) space

The entire list element is sent for DNS look-up (which would obviously fail).

A few seconds later, the same server element is re-tried ($::servers still only has ONE entry):
[01:42:20] Trying server [server-IP]:6667
[01:42:20] Connected to server-IP
... and the password is successfully sent to the server; the bot can connect properly.

.tcl set ::servers
Tcl: {server-IP:6667:password irc.server.network.name} {[server-IP:6667:password ]:6667 }

Why does it work the second time (upon retry), but, not the first time (altered)? Why is the second entry there, with the ([]) square brackets? What added it?

@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg Jan 8, 2018

Collaborator

Are you using an ipv4 or ipv6 address?

Collaborator

vanosg commented Jan 8, 2018

Are you using an ipv4 or ipv6 address?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost commented Jan 13, 2018

v4

@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg Jan 13, 2018

Collaborator

Is your bot already connected to a server during this action, or no? If no, can you try it while it is connected to an IRC server and see if the activity is repeated?

A full screen capture of the activity would be preferred; I cannot reproduce based on my interpretation of your activity, nor a few other variations. Thanks

Collaborator

vanosg commented Jan 13, 2018

Is your bot already connected to a server during this action, or no? If no, can you try it while it is connected to an IRC server and see if the activity is repeated?

A full screen capture of the activity would be preferred; I cannot reproduce based on my interpretation of your activity, nor a few other variations. Thanks

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 17, 2018

This happens on a cold start (the previously-shown log). It does NOT happen on a manual .JUMP.

ghost commented Jan 17, 2018

This happens on a cold start (the previously-shown log). It does NOT happen on a manual .JUMP.

@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg Jan 17, 2018

Collaborator

Setting a port and password for set servers in the config still does not give me the error you are encountering.

I tried it two ways (I don't have a non-SSL-allowing server requiring a password):

{irc.freenode.net:6667:forfunsies }

and then it joins on the first try with:

[04:11:55] Trying server [irc.freenode.net]:6667

and also on a server that actually requires a password, but with SSL:

{server.org:+7000:password }

and connecting I get

[04:04:47] Trying server [server.org]:+7000

and in the name of thoroughness,

[04:16:02] {91.217.189.42:6667:forfunsies }
[04:16:03] Trying server [91.217.189.42]:6667

I'd have to look at the exact server address you were using, I suppose? Trying to replicate, I get no error and it connects on first try.

Collaborator

vanosg commented Jan 17, 2018

Setting a port and password for set servers in the config still does not give me the error you are encountering.

I tried it two ways (I don't have a non-SSL-allowing server requiring a password):

{irc.freenode.net:6667:forfunsies }

and then it joins on the first try with:

[04:11:55] Trying server [irc.freenode.net]:6667

and also on a server that actually requires a password, but with SSL:

{server.org:+7000:password }

and connecting I get

[04:04:47] Trying server [server.org]:+7000

and in the name of thoroughness,

[04:16:02] {91.217.189.42:6667:forfunsies }
[04:16:03] Trying server [91.217.189.42]:6667

I'd have to look at the exact server address you were using, I suppose? Trying to replicate, I get no error and it connects on first try.

@Cizzle

This comment has been minimized.

Show comment
Hide comment
@Cizzle

Cizzle Jan 21, 2018

Member

Same here, can't replicate. Might be interesting what "password" exactly is?

Member

Cizzle commented Jan 21, 2018

Same here, can't replicate. Might be interesting what "password" exactly is?

@vanosg vanosg closed this Mar 11, 2018

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 7, 2018

I've been able to re-produce this bug on servers that have NO password listed.

[2018-05-06 21:35:04 -0800] [00:35:05] Trying server [IP:6667 ]:6667
[2018-05-06 21:35:04 -0800] [00:35:05] DNS resolve failed for IP:6667
[2018-05-06 21:35:04 -0800] [00:35:05] Failed connect to IP:6667 (DNS lookup failed)

Again, it's taking the port and considering part of the server *name* instead of the port.

.tcl return $::servers
{IP:6667 Server.name} {[IP:6667 ]:6667 }

Notice the brackets [and the space] in index #1? That's what's driving us nuts.

From teh config file:

set servers {
IP:6667
}
... and ...
set default-port 6667

Yes, only ONE entry in $servers; why there are two after bot start up is not understood.

I've put a zillion DEBUGS into all scripts, *AND* , I've run the bot with *NO* scripts at all.

You know me to be thorough, so, don't think me crazy and dismiss this. Well, one of you, anyway.

ghost commented May 7, 2018

I've been able to re-produce this bug on servers that have NO password listed.

[2018-05-06 21:35:04 -0800] [00:35:05] Trying server [IP:6667 ]:6667
[2018-05-06 21:35:04 -0800] [00:35:05] DNS resolve failed for IP:6667
[2018-05-06 21:35:04 -0800] [00:35:05] Failed connect to IP:6667 (DNS lookup failed)

Again, it's taking the port and considering part of the server *name* instead of the port.

.tcl return $::servers
{IP:6667 Server.name} {[IP:6667 ]:6667 }

Notice the brackets [and the space] in index #1? That's what's driving us nuts.

From teh config file:

set servers {
IP:6667
}
... and ...
set default-port 6667

Yes, only ONE entry in $servers; why there are two after bot start up is not understood.

I've put a zillion DEBUGS into all scripts, *AND* , I've run the bot with *NO* scripts at all.

You know me to be thorough, so, don't think me crazy and dismiss this. Well, one of you, anyway.

@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg May 7, 2018

Collaborator

Still can't repliacte. Can you try joining it to freenode and see if it will replicate there? Can you paste your config file so we can review it? Are you using 1.8.3? I've tried every setting I can think of that deals with IPv4/6, and I don't see this issue.

Full logs of actual connections and your config file is likely the only way we'll be able to resolve this. And by full log, I mean from the start of the bot all the way to the error occurring, not just the error, so we can better gauge context. Thanks

Collaborator

vanosg commented May 7, 2018

Still can't repliacte. Can you try joining it to freenode and see if it will replicate there? Can you paste your config file so we can review it? Are you using 1.8.3? I've tried every setting I can think of that deals with IPv4/6, and I don't see this issue.

Full logs of actual connections and your config file is likely the only way we'll be able to resolve this. And by full log, I mean from the start of the bot all the way to the error occurring, not just the error, so we can better gauge context. Thanks

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 16, 2018

... then let this remain closed.

The owner of the bot in question has it on a private network and will not allow me to post that info. I will try to set-up a bot on a "public" server to replicate under (otherwise) the same circumstances. If I succeed, I will contact you.

ghost commented May 16, 2018

... then let this remain closed.

The owner of the bot in question has it on a private network and will not allow me to post that info. I will try to set-up a bot on a "public" server to replicate under (otherwise) the same circumstances. If I succeed, I will contact you.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost May 24, 2018

I found the problem after some extensive testing.

Filing new bug. (Tried to get help on freenode; got something else instead.)

ghost commented May 24, 2018

I found the problem after some extensive testing.

Filing new bug. (Tried to get help on freenode; got something else instead.)

@ghost ghost referenced this issue Aug 24, 2018

Open

$::servers #559

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment