IRC Transfers

[KRiSX]

ok.. i have been downloading on several irc servers.. and not 1 problem when i start a new download.. but when i go to resume, it wont do it... i have tried with multiple users.. and nothing... it just will not resume... can someone help me?

[Slacker_au]

hey,

What type of file are they and where are they being saved?

Slacker_au

[KRiSX]

i've tried it with .mp3 and .zip (or .rar not sure really)

[Slacker_au]

ok the next thing to try is to go into the mirc options under dcc and make sure that all the settings are unticked for the auto overwright

[KRiSX]

i fixed it.. i just changed the ports to 3000 as first and 3010 last

ok this worked when i connected to irc on port 6669.. which is not always an option depending on the server...

so i still have the same problem...

[Neterciser]

I use mIRC and have the same file-sharing problems - downloads OK but resumes and sends are no gos - they just hang!

My research so far has narrowed the problem down to NAT firewall: "NAT routers have a natural firewall that rejects any unsolicited data that tries to travel from the Internet to a computer on your LAN. Basically, if you didn't ask for the data, it isn't gonna get past the firewall."

And specifically concerning IRC, "Messaging applications like AIM, ICQ, Netmeeting, Dialpad and others might be able to originate calls or chat sessions, but may not be able to receive calls, because receiving calls means that the data request didn't start out from a machine on your network."

Further, "So what do you want to do if you want to receive data originating from the Internet? The answer goes by many names, i.e. port mapping, port forwarding, DMZ, application rules, etc. But they all boil down to opening holes in the firewall so that unrequested data can come into selected computers on your LAN." (All quotes taken from http://www.practicallynetworked.com/sharing/specialapps.htm)

Further reading suggests the parameters for mIRC DCC / IRC DCC are IN TCP 1024 - 5000 (Watch Out! Opens a wide port range!) It maybe more secure to open up less ports (setup in conjuction with the options in IRC) but this may not allow DCC sharing in all situations.

You will therefore need to find a way to enter this data into your modem/router. Reading my WebExcel 3808 manual, it appears I should enter these parameters in the Virtual Server Configuration page of my modem, although obviously I cannot say where for your modem. I must admit I have not taken this final step as yet as I am loathe to upset my configuration as it took so long to setup and I am a mere novice at such things.

If any of this information is useful to you or, indeed, you make it to the final step and actually succeed in opening up the necessary ports, I would be very interested in the result.

[KRiSX]

well everyone has said it has to do with port forwarding ... i have put ports 1024 to 1029 in my config for this machine (local ip 192.168.1.2)

but it still doesn't work... i can resume on irc servers using port 6669... but 6667 and 6668 r just hopeless.. and unfortunatly.. those ports are what is used most...

i am still trying to work this out...

anyone know if there is a way to disable NAT ... and then use a software firewall.. i tried to disable it but then nothing worked.. couldn't go to sites or anything...

HELP!!!!!

[simonb]

are you trying resuming to the same person each time?

If not - are you sure the other end supports resuming?

[KRiSX]

no its not the same person everytime.. i have tested it on multiple networks with multiple people that do support resume..

everything works fine on port 6669... but i have wasted a big amount of my usage on stuffed up downloads due to this problem.. i know its not a swiftel issue.. but i'd like to know how to fix it..

[forumadmin]

"i know its not a swiftel issue.. but i'd like to know how to fix it.."

Are you saying its a Netcomm issue?

[KRiSX]

this is just my guess.. because all i see is people complaining about this with a nb1300.. but i could always be wrong... i will try to find out from them more info... but others have tried and been unsuccessful... so thats why i am trying on here..

[simonb]

It really sounds like a port forwarding issue. Make sure that you set your client to only use a specified range of ports, and then forward those ports through the nb1300. Yes, 10 ports means you need to manually add 10 forward lines.

You may find this page (http://www.mirc.org/dccprob.html) useful.

The problem would arise with any router, however, some make it easier to forward port ranges, and some may even know about IRC (a-la ip_nat_irc and ip_conntrack_irc in linux).

Similarly, I doubt it would be a Swiftel problem - where the linked document above refers to some ISP-level things aren't applicable in this case.

[KRiSX]

thanks .. i'll give it a read and keep playing with my settings

[Flak]

Originally posted by KRiSX
thanks .. i'll give it a read and keep playing with my settings

Any luck? Same as you, I can resume on channels that allow connection on port 6669, but 6667 and 6668 are no good.

[KRiSX]

nah i've kinda givin up :(

[rugger]

It probably the ADSL modem playing dodgy games.

Set it to bridged mode and do a direct connection to the internet with it using pppoe for windows.

See if resume works then.

[Flak]

I tried enabling DMZ as an experiment. At least now I know ZoneAlarm Pro is doing its job.

[pistonie]

are u using a script?

I had the same problem..
i got a billion modem/router..
and when i DCC get, its fine, but when i dcc send, i couldnt connect
mainly cause im on a network, and the router gives each computer an IP address, which my IRC client (mIRC) uses instead of my ISP ip address..
so to fix it, try this:

alt + o (mirc options)
click on "connect" on the left hand side..
click on "local info"

in the IP box, enter your static swiftel IP addy (assuming ur usin swiftel)

now on the right, untick "on connect, always get IP and Host"

and make lookup method = normal

now, press ok..
and reconnect..
this time u DCC send, you will be able to send, and still if u cant, it might be ur script (assuming ur using one) so try typing:
"/remote off" without the "" in the status window..
and d/c and reconnect... and try again..
and now if it works, u know its ur script..

reply on how u went...

[archie]

its a known issue with netcomm nb1300 modem.

i have the same issue and the only 'fix' is dont use port 6667, 6666, 6668, 6669 seem the way to go.

[Neterciser]

I found the following post by Vague on the mIRC Message Boards interesting:

"I'll just make this comment once more, because there is one more possible solution, skip the technical bits they merely confuse you:

DCC sends have following negotiation sequence (give or take, I'm forgetting):

sender listens on port
sender -> reciever: DCC SEND filename ip port filesize
reciever TCP connects to port and the transfer starts

This reveals the problem: The sender needs to be able to accept incomming TCP connection by listening on a port, if he can't, because he is behind a firewall or he shares an IP with others (for example with a NAT), he can't DCC send.

Since mIRC 5.4(1?) there has been a different sequence supported by mIRC, passive DCC. It's specified to be used with firewalls but works in many other cases just as well (i.e. behind a NAT). The idea behind this is that the recievers listens and the sender connects, thus removing the problem altogether. This again from memory (the exact description is in mIRC's help):

sender -> reciever: DCC SEND filename ip 0 filesize
reciever listens on port
reciever -> sender: DCC SEND filename ip port filesize
sender TCP connects to port and the transfer starts

This is very much like how FTP solves the same problem (passive FTP) and this solutions works great, except for one tiny smudge. Khaled intended this protocol for sending behind a SOCKS firewall and thus tied mIRCs implementation to this fact by disallowing passive DCC to be used if no firewall is configured. The ip sent by the sender is intended to be the firewall ip but for the reciever it makes no difference if this is the senders ip (or any arbitary number actually) instead. This limitation in mIRC implementation is not a flaw in the protocol or it's usefulness but rather a strange design decision by the mighty K. I keep trying to get this arbitary limitation lifted in future mIRC's, it takes (concievably) next to no implementation effort and would enhance the utility for some users. As a proof-of-concept that this setup works anyone with send problems should download an try:

[link deleted by moderator. no disrespect intended, but we advise against users d/l every addon they see]

It allows DCC sends using this protocol by adding it's own DCC send code. Liberate passive DCC in mIRC, make my addon redundant."
(http://trout.snt.utwente.nl/ubbthreads/showflat.php?Cat=&Board=connectionissues&Number=17&page=0&view=collapsed&sb=5&o=14)

The missing link is http://www.guldheden.chalmers.se/~sandin/archive.html

The file found at that website is attached.

If anyone can work out how to use this script (there is no instructions I could find on the website), I for one would like to try it.

[Flak]

Looks like I have the opportunity to offload my nb1300 and its mIRC resume problems. Can anyone recommend a replacement model which supports DCC resumes for roughly the same price (<$200) with the same features.

[kkfan]

i have a nb1300 too, and i can't even resume on port 6669 servers =(

[forumadmin]

Have any of you raised this problem with Netcomm?

[Neterciser]

I have the same problems with my web-excel, so it's not particularly a manufacturer problem. As previous posts have pointed out, this resume/send problem is a NAT/firewall port-forwarding conflict so I would think you would need to find a non-router ADSL modem without those features. Perhaps something like the Stingray might work??

Further to my last post, I wrote to Vague requesting instructions on how to use his passive mirc script and his reply:

Hello!

Place the file (pasvdcc.mrc) in your mirc folder. In mirc, type
/load -rs pasvdcc.mrc
Confirm the dialog window and you're ready to go. The syntax is
/psend <nick> <filename>
or just
/psend <nick>

If you have trouble with this, make sure the remote is enabled and try
loading it from the remote editor (chose the editor, the remote tab, and
load from the file menu).

Good luck!

-vague


I'll post again once I've had a chance to see if it works.

[Flak]

Originally posted by forumadmin
Have any of you raised this problem with Netcomm?

Yep, twice within the last 6 weeks, no response as yet.

Offloaded my NB1300, got the new Billion 7100 Pro, and it resumes. Straight out of the box, no port forwarding despite the NAT. Me happy. Should save Swiftel some bandwidth as well.

[Stuart]

I use NB1300 and have not only been able to not resume, but to send files, period, on IRC.