I'm writing a telnet client to communicate with an eggdrop via an IRC channel. It is working but one thing is extremely irritating. To illustrate, the following is typical of the partyline output when the socket first connects :-
[00:00] <infidel> [07:17] Telnet connection: cpc1-oldh9-2-0-cust32.10-1.cable.virginmedia.com/54485
[00:00] <infidel> [07:17] Timeout/EOF ident connection
It takes a finite yet seemingly variable length of time for the second of those lines to occur. Sometimes a few seconds. Nothing occurs over the telnet connection until the second of those two lines is output. It is as though the connection is waiting for some form of identification. This even occurs using a telnet client such as putty.
Has anybody any idea what information should be sent over the socket as soon as it connects in order to circumvent this annoying delay?
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.
telnet
This is the identd request timing out, I believe there is a config-setting for this timeout in the config. It is required to properly identify incoming telnet connections to the bot partyline, as these connections are matched against -telnet!<theident>@<thehost> in the userlist.
Best way to avoid these, is to use native tcl sockets rather than the connect/listen/control mechanisms in eggdrop.
The other option would be to tell your clients to install proper identd services...
Best way to avoid these, is to use native tcl sockets rather than the connect/listen/control mechanisms in eggdrop.
The other option would be to tell your clients to install proper identd services...
NML_375
Thanks for your time again.
I did build a client using the eggdrop Tcl connect/control commands but, though working, wasn't ideal. I found it very difficult to reliably code all possible events. For one thing the connect command returns a DCC channel ID irrespective of the status of the connection. For example, contrary to the documentation, it does not even seem to return an error if the host can't be resolved.
I also could not find any which way to detect the EOF that is supposedly returned if the connection otherwise fails. Obviously [eof $ID] could not be used since a DCC channel id is not a channel in the Tcl sense of the word.
The script I'm working on at the moment is a pure Tcl socket. The annoying delay may or may not have something to do with the 'Timeout/EOF ident connection' event in the partyline. I can't be sure.
I have reduced the 'set ident-timeout' setting in the .conf to 1 second but doesn't seem to make a blind bit of difference. I really can't imagine why an ident is needed anyway because I also have 'set protect-telnet 0' (ie. it will not drop connections from unknown hosts).
I am quite possibly wrong about this event being related to the delay in receiving a data stream.
As I have said, a telnet connection to the bot via putty also results in the 'Timeout/EOF ident connection' event. However, I have just noticed that there is no such delay in receiving data streams from the bot. I am therefore presently going with the idea that a client should send some sort of telnet protocol string to the server immediately it connects. Possibly IAC GA (go ahead). I will do some research along those lines.
I did build a client using the eggdrop Tcl connect/control commands but, though working, wasn't ideal. I found it very difficult to reliably code all possible events. For one thing the connect command returns a DCC channel ID irrespective of the status of the connection. For example, contrary to the documentation, it does not even seem to return an error if the host can't be resolved.
I also could not find any which way to detect the EOF that is supposedly returned if the connection otherwise fails. Obviously [eof $ID] could not be used since a DCC channel id is not a channel in the Tcl sense of the word.
The script I'm working on at the moment is a pure Tcl socket. The annoying delay may or may not have something to do with the 'Timeout/EOF ident connection' event in the partyline. I can't be sure.
I have reduced the 'set ident-timeout' setting in the .conf to 1 second but doesn't seem to make a blind bit of difference. I really can't imagine why an ident is needed anyway because I also have 'set protect-telnet 0' (ie. it will not drop connections from unknown hosts).
I am quite possibly wrong about this event being related to the delay in receiving a data stream.
As I have said, a telnet connection to the bot via putty also results in the 'Timeout/EOF ident connection' event. However, I have just noticed that there is no such delay in receiving data streams from the bot. I am therefore presently going with the idea that a client should send some sort of telnet protocol string to the server immediately it connects. Possibly IAC GA (go ahead). I will do some research along those lines.
I must have had nothing to do
Ident lookups are done irregardless of the protect-telnet setting, since any listen-port may have an associated mask with it.
The "Telnet connection" log message would not appear if you were using tcl server sockets rather than eggdrop's "listen" ports.. And as such, the latter will not call the callback proc until the idx is properly setup (identd request completed). Thus, nothing "happens" on the connection until the ident succeeds or times out.
This is where the "issue" lies, you should use tcl server sockets rather than "listen" to avoid issues with identd-lookups. Altering the ident-timeout setting will not stop this issue, just reduce the time it'll take until the identd-request fails.
The "Telnet connection" log message would not appear if you were using tcl server sockets rather than eggdrop's "listen" ports.. And as such, the latter will not call the callback proc until the idx is properly setup (identd request completed). Thus, nothing "happens" on the connection until the ident succeeds or times out.
This is where the "issue" lies, you should use tcl server sockets rather than "listen" to avoid issues with identd-lookups. Altering the ident-timeout setting will not stop this issue, just reduce the time it'll take until the identd-request fails.
NML_375
Sorry, I think perhaps I haven't explained mysef very well.
I'm building a telnet client to be loaded on one of my bots, to connect to the existing telnet servers on any of my other bots and, in effect, manipulate their partyline via an IRC channel. My client will automatically send username and password when prompted to do so by the server it is connected to. I'm not aware I have a choice other than to use the configured telnet listening ports on the bots I'm connecting to.
The existing eggdrop telnet servers look to be very simplistic in nature, uncluttered by the usual telnet protocol negotiation. In fact, other than what appears to be something like an IAC WILL ECHO sequence immediately after the server sends 'Enter your password.', I haven't yet seen any others. This makes coding my client very much easier as I can completely ignore (regsub out) telnet protocol from the incoming data stream.
Technically therefore, these are the facts. My client, using a native Tcl socket, behaves pretty much as putty would in establishing a telnet connection. Both cause a 'Timeout/EOF ident' partyline log on the bot they connect to. However, putty receives a data stream pretty much immediately whilst my client has a tendency for this smallish yet annoying delay of sometimes a few seconds. I had assumed it was sometimes a mite longer than could simply be explained by lag in outputting to an IRC channel, though I am not certain.
Possibly the difference is that a proper telnet client sends some sort of telnet protocol connection string immediately the connection is established, which relates to my origional question. If anyone has any thoughts on this, I would appreciate some feedback.
I can now confirm that 'set ident-timeout' in the desination bot's .conf file has nothing to do with this connection. I temporarily set it to 60 seconds. This had no effect on the connection and no effect on receipt of the party line logged 'Timeout/EOF ident connection'.
Anyway, other than this minor 'delay' issue, the client is functioning well as per the following screenshot.
I'm building a telnet client to be loaded on one of my bots, to connect to the existing telnet servers on any of my other bots and, in effect, manipulate their partyline via an IRC channel. My client will automatically send username and password when prompted to do so by the server it is connected to. I'm not aware I have a choice other than to use the configured telnet listening ports on the bots I'm connecting to.
The existing eggdrop telnet servers look to be very simplistic in nature, uncluttered by the usual telnet protocol negotiation. In fact, other than what appears to be something like an IAC WILL ECHO sequence immediately after the server sends 'Enter your password.', I haven't yet seen any others. This makes coding my client very much easier as I can completely ignore (regsub out) telnet protocol from the incoming data stream.
Technically therefore, these are the facts. My client, using a native Tcl socket, behaves pretty much as putty would in establishing a telnet connection. Both cause a 'Timeout/EOF ident' partyline log on the bot they connect to. However, putty receives a data stream pretty much immediately whilst my client has a tendency for this smallish yet annoying delay of sometimes a few seconds. I had assumed it was sometimes a mite longer than could simply be explained by lag in outputting to an IRC channel, though I am not certain.
Possibly the difference is that a proper telnet client sends some sort of telnet protocol connection string immediately the connection is established, which relates to my origional question. If anyone has any thoughts on this, I would appreciate some feedback.
I can now confirm that 'set ident-timeout' in the desination bot's .conf file has nothing to do with this connection. I temporarily set it to 60 seconds. This had no effect on the connection and no effect on receipt of the party line logged 'Timeout/EOF ident connection'.
Anyway, other than this minor 'delay' issue, the client is functioning well as per the following screenshot.
I must have had nothing to do
The IAC WILL ECHO sequence is simply part of hiding the password from being echo'ed on the local terminal.
As for putty vs. "relay"; as soon as the outbound connection to port 113 is rejected, dropped, ignored (timeout), or accepted/responded, the dcc_telnet_got_ident() function is called. This will have the purpose of matching a handle to the incoming connection, determining access rights, test the kind of "listen" (user/bot/all/script).
With the exception of the last one, socket buffering is disabled, any banner is sent, and the login message is sent.
Technically put, eggdrop has no telnet engine, and have no understanding of received telnet control codes/sequences. It uses tcp sockets over the ip layer to establish a data channel (socket), and transfers plain simple text through this. User-controlled sequences may be sent, but your eggdrop has no means to make sense of these.
Regarding the "smallish" delay, this could very well be part of the limitations of tcl-events in eggdrops. The Tcl_DoOneEvent() function is called in the beginning of the main-loop, meaning all other eggdrop events will be parsed inbetween, including scanning all idx'es for new input. You have to keep in mind that in some views, eggdrop is a behemoth trying to do vast number of tasks at the very same time - while still remaining single-threaded to a large degree...
As for putty vs. "relay"; as soon as the outbound connection to port 113 is rejected, dropped, ignored (timeout), or accepted/responded, the dcc_telnet_got_ident() function is called. This will have the purpose of matching a handle to the incoming connection, determining access rights, test the kind of "listen" (user/bot/all/script).
With the exception of the last one, socket buffering is disabled, any banner is sent, and the login message is sent.
Technically put, eggdrop has no telnet engine, and have no understanding of received telnet control codes/sequences. It uses tcp sockets over the ip layer to establish a data channel (socket), and transfers plain simple text through this. User-controlled sequences may be sent, but your eggdrop has no means to make sense of these.
Regarding the "smallish" delay, this could very well be part of the limitations of tcl-events in eggdrops. The Tcl_DoOneEvent() function is called in the beginning of the main-loop, meaning all other eggdrop events will be parsed inbetween, including scanning all idx'es for new input. You have to keep in mind that in some views, eggdrop is a behemoth trying to do vast number of tasks at the very same time - while still remaining single-threaded to a large degree...
NML_375
Ok, thanks for that.
I just have a remaining question regarding the port 113 communication you spoke of.
My client connects on the destination eggdrop's listening port (not port 113). There is no outbound connection to port 113. Are you saying that the destination eggdrop sends a port 113 ident request to the client's IP as soon as the connection is made? At the moment, my client bot is a windrop with winident.tcl. If this is the case I was rather hoping my windrop would respond.
I just have a remaining question regarding the port 113 communication you spoke of.
My client connects on the destination eggdrop's listening port (not port 113). There is no outbound connection to port 113. Are you saying that the destination eggdrop sends a port 113 ident request to the client's IP as soon as the connection is made? At the moment, my client bot is a windrop with winident.tcl. If this is the case I was rather hoping my windrop would respond.
I must have had nothing to do
Whenever your eggdrop receives an incoming connection (to a port opened using listen), it will make an identd request (that is, connect to port 113 of the remote host, and make a request according to rfc1413).
As for winident.tcl, I have a faint memory that it'll only answer incoming requests when your eggdrop is currently connecting to a server...
As for winident.tcl, I have a faint memory that it'll only answer incoming requests when your eggdrop is currently connecting to a server...
NML_375