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.
This is the new home of the egghelp.org community forum.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
bot can`t connect, can not resolve dns, strage problem
bot can`t connect, can not resolve dns, strage problem
socketapi | Code less, create more.
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
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 in the partyline (requires that use of dcc .tcl command be enabled).
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
Code: Select all
.tcl exec host <machine other then connecting to>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]
[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]
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 ?
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 ?
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.
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
Euhm, in fact, I am
I did not expect that the old configuration file would work, but it did I plan to look in to this when I have some spare time.
Or do you think this could be causing my problem?
I think I understand most of what you are saying, but how come that only few systems show this behaviour? And second, I do not think that the interface really goes down. In my case the system comes back online when the dhcp lease is renewed, or is this what you mean ?nml375 wrote: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.
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.
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