My DCCs are constantly timing out. This just happened for no reason at all, i didnt touch anything. The transfer would start, but 22 seconds later it would time out with no data sent and the error message of "connection failed". Then the bot gives this message "You have a DCC pending, Set your client to receive the transfer. (150 seconds remaining until timeout)". Just how am i supposed to set my client to receive the transfer? Its ALREADY set to automatically accept the transfer.

9 times out of 10 its the senders problem so best contact the owner of the iroffer or xdcc bot and ask them.
also check out this whilst you are at it, it may enlighten you....
CLICK ME

There is also a sticky thread specifically referring to the DCC pending message.

Regards,

Originally Posted By: Constantine

9 times out of 10 its the senders problem

If you're trying to resume the file transfer, then the problem is on your end, either forward some tcp ports to your machine and set mirc to use those ports for dcc, or delete the file and start over.

Reading the OP's post it seems it is timing out 22 seconds after initiating with no data sent so it dont seem to be a resume but a total failure in the 1st place, yes it could be a port forwarding problem however I also read that due to the amount of illegal filesharing from xdcc or iroffer bots that we dont help with this problem. Perhaps a moderator could clarify this position.

Correct. We don't help with filesharing. For port forwarding, we just send people to portforward.com.

As far as ports go, downloading is rarely blocked by your own ports. Only sending is blocked in most cases. And, for resuming, that's almost always on the sender's side due to a bad router setup using NAT.

There's no need for clarification, you provided the link to the sticky post concerning illegal filesharing which was adequate, but I will still help with dcc connection problems all the same. The OP has been warned.

~ Edit ~

Originally Posted By: Riamus2

As far as ports go, downloading is rarely blocked by your own ports.

And, for resuming, that's almost always on the sender's side due to a bad router setup using NAT.

Read up on the dcc resume protocol, when resuming it is the sender that connects to the receiver rather than the receiver connecting to the sender as with normal dcc.

...or maybe it's just passive dcc that works that way, although I was told by qwerty (or Merlin, can't recall which) when passive dcc was first added, that it was basically just using the resume protocol which puts the burden of open ports on the downloader instead of the sender as with normal dcc.

Yes, reverse/passive DCC works backwards from normal. However, this is not the norm for people sending files. Usually, you do not need to forward any ports to download.

And resuming failing *is* caused almost always by the sender's NAT setup in the router. Depending on the router, this can be changed so it works, but some routers don't let you change them, so resuming never works.

Come on man you're contradicting yourself, if dcc resume and passive works backward from normal, then the receiver needs the open ports, not the sender. So it's no wonder that changing router settings on the senders end fails to resolve resume problems, because it's the receiver that needs the open ports. Try as long as you want, you'll never get a cat to bark or a dog to meow.

Re-read what I said.



Resuming isn't the same as passive DCC. Yes, it's similar, but it isn't the same. The problem comes not from ports being open or closed on either end. The problem comes from the NAT configuration of the sender's router. Basically what happens is that the port chosen gets "changed" by the NAT in the router, so that it gets confused because the port that the downloader's mIRC expects and the port that the router tells the sender's mIRC to use don't match. You can search for NAT and resuming on the forum and you'll find more information and better explanations of it than this. However, this is the basic issue. The sender can choose to disable NAT if the router allows that, or possible adjust the router's configuration to not use NAT with IRC (again, if the router allows that). Some routers can be set up to handle resuming, some can't. Others don't have issues with NAT and resume fine without going through hoops. Again, this is on the sender's end, not the downloader's and it isn't because of what port(s) are forwarded.