i don't know if this just happens when you try to send a file to yourself, but when i send me a file (i was testing a script) i got this:
CTCP: GenderChanger - DCC RESUME file.ext 38142 12288
DCC Resume from GenderChanger rejected (invalid parameters)
instead of the real filename, mirc sent a "file.ext"
even if it is not a bug, can someone explain me what the problem is?
What version of mIRC are you running, and were you sending between the same client? (or did you open a second mIRC?)
The "file.ext" only exists to maintain backwards compatibility with older clients, as it is redundant. That is, the clients don't have to send the filename back and forth to each other, as the port allows them to identify what file they're talking about (one port per number, per machine, hence the port number is unique to the sendee machine).
I have got this problem once, and when I tried to reproduce it it was gone. If the problem still persists, it might be helpful to paste the full dcc negotiation.
Hope that helps.
i'm running 6.03, and i was sending in one client
i don't know where to get more information about the transfer, but i can reproduce the problem as often as i want.
i'm behind a router to add that, and i haven't my dcc ports forwarded, but normally on dcc sends i get "unable to connect"
type /debug -p @debug, then start(or attempt) the transfer as normal and copy/paste the output.
This might be mirc doing a little sanity checking (IP is bad? Resume range > File size etc.).
The filename in the RESUME CTCP is purely a placeholder. mIRC uses the IP and Port to figure out which DCC it is resuming, and ignores that parameter.
What is breaking your DCC resumes is your firewall/router software. It has a module loaded that intercepts DCC CTCPs and changes the IP/Port to that of the firewall, so that the person you are sending to connects to it instead of trying to connect to your inaccessable private IP. When the recipient requests a RESUME, the IP and Port included in the request are that of the firewall/router, not your local machine, so they don't match up with any of mIRC's pending transfers, causing the 'invalid parameters' rejection. Either disable this module/feature on your firewall/router and use static port forwarding, or update your firewall/router software with a version that corrects the RESUME bug.
I have a gvc (gnet) ip0006 internet gateway, and I get the same problem. I can't disable the module nor does my company have a firmware upgrade, what else can I do the get rid of this problem?
why my modem zyxel parks prestige 642r-11 only send files with lookup method normal? and resume don't work?
i see others dsl modens and these modens send files with lookup method server
obs.: others programs send and resume files as ftp, icq, kazaa and others.
I solved this problem on my Zyxel Zywall by setting
ip nat service irc off
If I am using a U.S. Robotics Broadband Router (Model # USR8000, Version V1.23), what should I check for?
ok, i tried everything i found here and everywhere else... upgrading firmware, disabling firewall... messed up with my router configuration about 3 times... (and it was hard to get it up again). and here is what i got:
my adsl modem is a zyxel prestige 642r (router) working with PPPoE, i had all ports forwarded by SUA and still someway, my outgoing DCC SENDs were having the ports somewhat changed into sth near 10000-14000, no matter what...
analyzing that this could be a router funcion somewhat like a NAT, and as i didnt found a way to disable it, i started thinking to throw it out by the window, using it as a bed warmer or sth like that....
but than i though... HTF could my router detect mirc's DCC send command?? well.. it usually goes out by port 6667... so, if there is anything with syntax "DCC SEND filename ip port size" stuff, it could possibly detect it and change port name...
WHAT IF I WERE TO BE CONNECTED TO THE IRC SERVER AT PORT 7000 (for example?)
no more chaning ports... DCC RESUME WORKS!!! now the port that is sent, is the same that i receive in the DCC RESUME command
i hope this topic can help someone....
i have not tested other ports, as i spent the last 7 hours trying to fix this, maybe every port except 6667 willl work... if someone tests it, please post results
wad if tt irc network only opens 6667 ?
I have had exactly the same problem. Tearing my hair out. Resume working on one network and channel but not on others. Eventually my Googling turned up this, and now after connecting to the problem server using 6669 instead of the previous 6667 all my problems are solved. The resume that failed about half a dozen times is now finishing off nicely. I'm still not sure why connecting to the server using 6669 instead of 6667 would make any difference, I still have the same ports forwarded and haven't changed anything else, but the proof is in the pudding as they say, and it's relief enough that it's working.
I've just been having problems when connected to port 6668 as well. Same network as before. Force it back onto 6669 and problems solved and my resume works again. And it isn't coincidence. 3 failed resumes when connected on 6668, followed by a perfect resume after connecting on 6669.
Hellow, I know this is a really old post, but I have this problem. I'm trying to connct in port 6669, it works, but my client can't resume.
Could you help me please.
how do i solve this?
someone please help, thanks!