dcc chat timeout setting

[agathodaimon]

when i dcc chat with the bot after i while it dies..that means it doesnt answer to the commands..and i have to open a new chat...how do i change this..? any ideas?

[demond]

get a better ISP or shell provider

[De Kus]

rather sounds like a router problem, some routers use very low timeouts for DCC sessions. Use telnet or /ctcp <bot> chat instead if you cannot fix it.

[demond]

rather sounds like a router problem, some routers use very low timeouts for DCC sessions. Use telnet or /ctcp <bot> chat instead if you cannot fix it.

what makes you think it's a router problem? you know a DCC-aware router? there's no information to base that guess upon; if the guy have said he's having the same problem with any TCP connection, then you would have enough info to guess it sounds like a router problem

/ctcp bot chat will establish exactly the same type of connection, and connection deterioration is very unlikely to depend on who initialized it, so that most likely won't help - if it helps, that would mean the connection parameters somehow depend on port number/range, and if that's the case, you (or rather that guy) should ditch the provider anyway

using telnet might help, if the telnet client have the ability to periodically send keepalive packets - if it helps, you can also script some keepalive activity for your DCC sessions

[De Kus]

what makes you think it's a router problem? you know a DCC-aware router? there's no information to base that guess upon; if the guy have said he's having the same problem with any TCP connection, then you would have enough info to guess it sounds like a router problem

I think that way, because I have the same problem, since I heared from others they dont have that problem to that shell, I'm sure the only cause that it left is the DCC implementation of my router.

/ctcp bot chat will establish exactly the same type of connection, and connection deterioration is very unlikely to depend on who initialized it, so that most likely won't help - if it helps, that would mean the connection parameters somehow depend on port number/range, and if that's the case, you (or rather that guy) should ditch the provider anyway

the only time you really make a DCC connection is, when using /dcc <bot>, you can avoid it by using /ctcp <bot> chat, since that way, you wont establish a DCC connection, but in fact a telnet connection to your bot, just your client will think its DCC ^.^.

[demond]

what makes you think it's a router problem? you know a DCC-aware router? there's no information to base that guess upon; if the guy have said he's having the same problem with any TCP connection, then you would have enough info to guess it sounds like a router problem

I think that way, because I have the same problem, since I heared from others they dont have that problem to that shell, I'm sure the only cause that it left is the DCC implementation of my router.

routers know nothing about DCC, they know about network-level protocols like TCP, not application-level; read again my post

/ctcp bot chat will establish exactly the same type of connection, and connection deterioration is very unlikely to depend on who initialized it, so that most likely won't help - if it helps, that would mean the connection parameters somehow depend on port number/range, and if that's the case, you (or rather that guy) should ditch the provider anyway

the only time you really make a DCC connection is, when using /dcc <bot>, you can avoid it by using /ctcp <bot> chat, since that way, you wont establish a DCC connection, but in fact a telnet connection to your bot, just your client will think its DCC ^.^.

you are confused; /ctcp bot chat makes your bot to initiate DCC connection with you - offer you DCC CHAT; either way, it's a TCP connection; DCC itself is only a mean of automatically negotiating TCP connection on IRC

[De Kus]

have you ever heared about the "DCC module" for iptables?
do a search for 'ip_nat_irc' or 'router "direct client to client"' on google and you will find a lot of infos related to DCC. in fact the router will manupulate the CTCP DCC packet confirming it contains the external IP and opens a new port.
If I do a dcc chat it will look like that on the bot:

Code: Select all

<StarZ|Clan> [10:46:54] tcl: evaluate (.tcl): exec netstat -na
<StarZ|Clan> Tcl: Active Internet connections (including servers)
<StarZ|Clan> Tcl: Proto Recv-Q Send-Q Local Address Foreign Address (state)
<StarZ|Clan> Tcl: tcp 0 0 192.168.1.104.6285 84.173.x.x.64415 ESTABLISHED
...

but it will look like that on my computer:

Code: Select all

C:\Dokumente und Einstellungen\De Kus>netstat -na

Aktive Verbindungen

  Proto  Lokale Adresse         Remoteadresse          Status
...
  TCP    192.168.178.4:20150    84.173.x.x:64416    HERGESTELLT
...

(privat IP censored)
If I do a "/ctcp <bot> chat" it will be a single "normal" TCP connection without a tunnel. The shell I used as example currently has port forwarding problems, so I can't give new logs, but you can try yourself, in fact your bot will make mIRC to connect to the telnet port and not one of the reserved DCC (file) ports. This might be caused because the kernel of the shell has no DCC module installed, but its always worth a try, because it makes a diffrence which way you establish the connection for the timeout.

[demond]

have you ever heared about the "DCC module" for iptables?

since I wrote about it in the top sticky topic of this forum, I must have heard about it, don't you think?

do a search for 'ip_nat_irc' or 'router "direct client to client"' on google and you will find a lot of infos related to DCC. in fact the router will manupulate the CTCP DCC packet confirming it contains the external IP and opens a new port.

I would have never guessed that if it wasn't for you to enlighten me

dude, I've been running firewall and packet filtering software likely before you got on the Internet for the first time; and I know how it works, I don't need to google for it

iptables isn't router, iptables is kernel software framework that provides packet filtering, NAT, and other packet mangling; router is a device that handles packet transfers between computer systems, not an iptables module that knows about CTCP DCC, okay?

If I do a "/ctcp <bot> chat" it will be a single "normal" TCP connection without a tunnel. The shell I used as example currently has port forwarding problems, so I can't give new logs, but you can try yourself, in fact your bot will make mIRC to connect to the telnet port and not one of the reserved DCC (file) ports. This might be caused because the kernel of the shell has no DCC module installed, but its always worth a try, because it makes a diffrence which way you establish the connection for the timeout.

you simply don't know what you are talking about

a tunnel? what tunnel?? that's totally irrelevant

and you can't speculate about the difference in connection quality depending on initiating end point - observing such effect on your system doesn't mean anything in general

[Alchera]

you simply don't know what you are talking about

Would appear there's not much understanding.