Alice.tcl and debug WARNING

[FreakyComputer]

Hello

I've loaded alice.tcl and the egghttp.tcl scripts and set it to use the www.alicebot.org (Alice) engine. It's loaded in the conf file, and the bot rehashes/restarts fine. Now whenever I try to "talk" to the bot, I get the following error in the partyline

[23:11] <TheBot> [23:50] WARNING: open_telnet_raw() is about to block in gethostbyname()!
[23:11] <TheBot> [23:50] [mynick!myident@myip.myisp.net] hi TheBot
[23:11] <TheBot> [23:50] net: connect! sock 10
[23:11] <TheBot> [23:50] net: eof!(read) socket 10

I was wondering if it's got anything to do with either, alice, egghttp, or my shell provider?

Thanks
FC

[simonbell]

i cant even get the bot to reply to messages, and it doesnt give any errors in the party line.

Simon

[[Brain]]

i have alice working just fine first try using de "# 2 = a program E server (Phillip) " server and you need to whatch out for version conf like this one

## Let your bot respond to comments in channel when bot's name is mentioned? ##
# (0 = No, 1 = Yes) [ For eggdrop versions less than 1.5.x
# ( 1.5.x+ users should use .chanset #channel +alice ) ]
set alice_respondchan 1

i'm running 1.5.x+ so the first time i start the bot with alice our any time i do .die i have to run ".chanset #channel +alice" if not with my conf he only replay in PVT and not on open channel.

[strikelight]

Hello

I've loaded alice.tcl and the egghttp.tcl scripts and set it to use the www.alicebot.org (Alice) engine. It's loaded in the conf file, and the bot rehashes/restarts fine. Now whenever I try to "talk" to the bot, I get the following error in the partyline

[23:11] <TheBot> [23:50] WARNING: open_telnet_raw() is about to block in gethostbyname()!
[23:11] <TheBot> [23:50] [mynick!myident@myip.myisp.net] hi TheBot
[23:11] <TheBot> [23:50] net: connect! sock 10
[23:11] <TheBot> [23:50] net: eof!(read) socket 10

I was wondering if it's got anything to do with either, alice, egghttp, or my shell provider?

Thanks
FC

Either eggdrop or your shell provider as "gethostbyname()" would suggest.

[strikelight]

i'm running 1.5.x+ so the first time i start the bot with alice our any time i do .die i have to run ".chanset #channel +alice" if not with my conf he only replay in PVT and not on open channel.

If you have a channel file defined in your eggdrop's .conf, you shouldn't
have to be doing .chanset everytime you restart your bot.

[ppslim]

Nope, this is due to one of 2 things.

If your have fast DNS servers, then this should not be an issue.

It's either a hostname being passed to the open_telnet_raw function. To fix this, use an IP for the server being used.

Or a firewall being used, by specifying a hostname rather than a IP.

The only reason you see this message, is because you have it enabled in your console flags.

botnet links, DCC chats and the Tcl connect command, all use this function, and will all display this error.

To say it is an error is incorrect. It's an informative debug message.

[strikelight]

If your have fast DNS servers, then this should not be an issue.
...
Or a firewall being used, by specifying a hostname rather than a IP.

As I said, a problem with the eggdrop or the shell provider. (Which from what you are saying would be the latter of what I said).

[ppslim]

Nope - neither.

This happens on ALL eggdrops. In 99.999% of cases, users do not see the message, because they do not have the console flags enabled to see it.

For every connection eggdrop makes, int he conditions specified above, it will display that message.

A quick glance at the source code (src/net.c:399) shows where the message is displayed, and to what console it goes to. Doing a search for it's containing functions, shows the location where this happens.

As such, it is more common than you think, and should not be blamed on the provider or eggdrop without further evidance.

[strikelight]

Nope - neither.

If your have fast DNS servers, then this should not be an issue.
...
Or a firewall being used, by specifying a hostname rather than a IP.

To have said these things and then say that they are NOT related to the box the bot is running is on, is pure back tracking, when obviously a lack of fast dns server/firewall are issues with the provider.