egghelp.org community

sKy · Op Joined: 14 Apr 2005 Posts: 194 Location: Germany

After uptime for about one year the bot left irc (netsplit) and did not come back. I did wonder why. He is using some random server. It was no problem for me with a regular client to (re) connect to the network.

I telnet the bot and used .console +rv. Message was can not resolve dns.

The bot reconnected before without problems and I did not change anything for a long time. After killing it and restarting he did connect immediately.

If you have a prophecy please tell me.
_________________
socketapi | Code less, create more.

nml375 · Revered One Joined: 04 Aug 2006 Posts: 2857

My guess would be that your sysadmin changed nameservers for that system (by editing /etc/resolv.conf) and made the old dns-server unavailable. Since eggdrop only checks /etc/resolv.conf on startup, it did'nt make notice of the change until you restarted it, and was hence unable to resolve domain names.
_________________
NML_375, idling at #eggdrop@IrcNET

DragnLord · Posted: Sun Mar 18, 2007 12:47 pm Post subject:

Recheck the servers listed in 'set servers' to make sure all listed servers are valid.
It's also quite possible that the nameserver for the IRC network's domain had problems.
To tell if the dns issue is on your shell, use

jarim · Voice Joined: 12 Apr 2007 Posts: 1

Hello! I've had exactly the same problem! The bot connects to irc server just fine when restarted but if my adsl-connection drops for over 10mins or so, the bot doesn't seem to resolve irc servers anymore? Adding same servers to conf file using ip address instead of dns name and the connection works ok. "Smells like a bug?"

[14:42] Trying server irc.xxxxx.fi:6667
[14:42] Failed connect to irc.xxxxx.fi (DNS lookup failed)
[14:42] Trying server irc.xxxxxx.se:6667
[14:42] Failed connect to irc.xxxxxx.se (DNS lookup failed)
[14:42] Trying server irc.xxxxxxx.fi:6667
[14:43] Failed connect to irc.xxxxxxx.fi (DNS lookup failed)
[14:43] Trying server 192.xxx.xxx.xxx:6667
[14:43] Connected to 192.xxx.xxx.xxx
[14:43] -ERROR from server- Closing Link: --[unknown@--.org] (Too many host connections (global))
[14:43] Disconnected from 192.xxx.xxx.xxx
[14:43] Trying server 213.xxx.xxx.xxx:6667
[14:43] Connected to 213.xxx.xxx.xxx
[14:43] -- joined #[channel]

BigG · Voice Joined: 13 Jan 2008 Posts: 2

I also have exactly the same problem. When my connection drops for a short period of time the bot doesn't seem to resolve irc servers anymore.
Only restarting the bot let him connect again. When i for instance do 'ping www.google.be' the dns resolving works fine.

This problem started when i configured a new Debian 4.0 box and moved the bot to this machine. Therefore i upgraded and compiled my old bot from 1.3.x to the latest version but the problem remains.

Anybody an idea ?

Alchera · Posted: Sun Jan 13, 2008 9:44 pm Post subject:

A 1.3.x eggdrop?

You're not using the same configuration file are you?

1.6.18
_________________
Add [SOLVED] to the thread title if your issue has been.
Search | FAQ | RTM

nml375 · Revered One Joined: 04 Aug 2006 Posts: 2857

The cause for this problem is most likely the way the dns-module operates. Upon loading, it will create an udp-socket, which will be used for any further dns-lookups.
Should the network interface go down, this might render the socket unusable on some systems, yet not cause an eof-condition. The result being that no packets generated on that socket will be transmitted, and thus there will never be any replies.

In essence, you'd have to ".unloadmod dns" followed by ".loadmod dns" whenever your network interfaces goes down and up again, as this will close the old socket and create a new one.
_________________
NML_375, idling at #eggdrop@IrcNET

BigG · Voice Joined: 13 Jan 2008 Posts: 2

nml375 · Revered One Joined: 04 Aug 2006 Posts: 2857

It's been a long while since I played 'round with traffic handling within the kernel, so I can't say much 'bout the exact mechanisms, but a few things I do remember:

DHCP negotiations are done in userspace, having a daemon controlling the network interface and using raw sockets to to send requests as the interface is in an address-less state. Upon loss of lease, most clients will revert the interface to an address-less state and then down the interface, causing havoc with currently opened sockets bound to that interface.

Interfaces bound to the IN_ADDR_ANY interface would not get closed/eof'd as the "any" interface will be available as long as any network interface (including localhost) is available. Instead each packet sent here would be matched against the system routing table, possibly resulting in "No route to host", "destination host unavailable", or packet simply dropped. In order for any ICMP-messages to be "recieved", the udp-socket would have to be connected, which I am not sure is done in the dns-module. If not, the only result would be that the packet gets lost in the routing-table.

As for the eof-condition within eggdrop's somewhat complex socket-handling, the SOCK_EOFD flag will be raised on the idx in the event that read(socket) returns any other error then EAGAIN (would-block). Again, if the socket isn't connected, there would be no errors, resulting in no eof-flag.
_________________
NML_375, idling at #eggdrop@IrcNET

Alchera · Posted: Mon Jan 14, 2008 9:06 pm Post subject: