This happens when you have set mIRC to limit the range of ports it uses for DCC sends when you are behind certain routers. Sending files works OK, but if the send is interupted and you resend the file you are not able to resume because the client requesting the resume requests it on a port that is not in the range that was specified by the sender so the resume is rejected. No matter what port the original send was on mIRC always requests the resume with the default ports. This gets increasingly annoying on large files.

Please note that mIRC's DCC capabilities are not the best option for sending large files. An FTP is far superior.

I'm not discounting your report by stating this, but it's something you might consider looking into if you're sending/receiving large files on a regular basis.

Im quite familiar with FTP and I know as you said you didn't mean to discount the issue at hand... I just feel it's something important to address as FServes are a very common thing with mIRC.

Sounds like your router is attempting to perform ALG functions, especially because you specified "behind certain routers". I've yet to see one that doesn't screw it up horribly.

This isn't something mIRC can do anything about, since the router is messing directly with the packets. Disable the functionality in the router or use a server port other than 6667 (I haven't seen one yet that did this stuff on ports other than 6667).

Connect to a server on a port other than 6667 and test a send/resume, I bet the ports will match.

What I suspect is happening is the router doesn't recognize DCC resumes. It is altering the ip/port in the CTCP message when you first send the file but it is not doing it to the resume message, thus the discrepancy.

I've changed the port as I've read that somewhere before that that should fix it. I successfully resumed 1 send after I did that... but since then they still fail.