Windows XP SP2 on both computers.

The help file states the following about DCC Resume:

To initiate a DCC Send, User1 sends:
PRIVMSG User2 :DCC SEND filename ipaddress port filesize

If User2 chooses to resume a file transfer of an existing file, the following negotiation takes place:
User2 sends:
PRIVMSG User1 :DCC RESUME filename port position
filename = the filename sent by User1.
port = the port number sent by User1.
position = the current size of the file that User2 has.

So I did the usual /debug @raw and took a look-see.

-> irc.xxx.net PRIVMSG slay :
DCC SEND FxxxSxxx.BIN 1173867117 4170 608163696


Notice the port is set to 4170. But what did I get back?

<- :Slay!Slay.eXe@xxxxxxx.com PRIVMSG w00b :
DCC RESUME "FxxxSxxx.BIN" 2407 153906040


Ah. Port 2407? This is not the same port that I sent. And thus mIRC gives me the glorious error:

[14:38] DCC Resume from Slay rejected (invalid parameters)

Hope you fix this soon Khaled.. DCC Resume is an excellent feature!

confirmed. as for me when I try to resume mp3s I get from other users it doesn't resume at allll.

This isn't a problem with mIRC, but with your router. Routers that use NAT often have this problem. A different router would solve your problem. Of course, that costs money. But afaik, that's the only way to get around it unless there is a setting to disable the NAT (not sure if any routers have such a setting). If you search the forum for "router NAT" (no quotes), you can probably find more information about this problem. Note that this affects RESUMES only.

I don't know that I believe that Riamus2.. And the reason is because the help file is supposed to state how the DCC Resume protocol works, and the mIRC client is not working how it has stated that it should be working. And no features are turned on that would make it work otherwise. Example passive DCC that sets the port parameter to 0. In the GNU world, if it doesn't work how it is documented, it is considered a bug. Also if it is not documented, it is considered a bug. In this case, it is not working how it is documented so I consider it a bug!

Some time ago I ran into the weirdest problem helping a guy with
his sends. It was basically the same problem as yours, but his
port was changed whether resuming or not. We eventually found
that it happened only when he was connected to IRC on port 6667.
I know it sounds dumb but it happened everytime. He stopped using
6667 and his sends have been fine since. It was a Linksys router
if I recall correctly.

Well right now there's nothing here to show that mIRC is causing the port number to change. What you really need to do is debug at both ends of the resume and see what the other mIRC is receiving. There's a chance it really is a router which "supports" DCC and is trying to correct the outgoing port number.

Keep in mind that passive DCC is a fairly new feature and the help file doesn't get updated regularly, so missing information about new features is common. You may consider it a bug, but that's just the way it is.

As for the router issue, take the time to search the forums and you'll find posts that deal with this and explanations as to WHY it fails. What basically happens (very quick summary) is that the router is changing the port from what mIRC expects, so as far as mIRC is concerned, it's trying to resume on a port that it shouldn't and so it fails. That is what happens in various NAT routers. Search the forum and you'll find more information.

Here is one short post for you about this issue.
Here is another.
Here is a possible fix for you and if you look up to Sojourn's post, you'll find probably the best explanation of why it happens.

Just as a sidenote, the passive DCC protocol is actually documented (and has been around longer than the "Passive DCC" option) - see /help DCC Socks5 Protocol

Ok, I worded that incorrectly... Passive DCC as a built-in mIRC option is a fairly new feature.

I apologize for doubting your post.. I don't appreciate my router having the ability to edit my packets though. That's actually kind of scary. Even if it is to help, it's still scary. Thanks for all of the help though! lol

It isn't editing packets; it's changing the port. And that is where the problem occurs.

I believe this might be an issue with opening and forewarding ports. If you have linksys I can walk you through on how to add ports to be allowed on your router. If you have a different router, or not one at all, I am afraid I will not be able to help you as much in this situation.

It isn't forwarding ports that is the problem. It's the NAT. And unless you can disable it, you are pretty much stuck unless you can connect to the server on a port other than 6667.

As was mentioned in other posts, the reason for this is probably that your router is changing the port. This is almost always the reason why people see one port going out and another port coming back.

You can check this by noting what the /debug line shows as the outgoing port, and then using /debug on the other client to see what it is receiving. If it is receiving a different port number, then your router is changing the port.