Contents
-
My ISP gave me a Thomson 585v7 ADSL2+ modem and router (also known as a Speedtouch 585v7 or possibly an Alcatel 585v7). This was fairly easy to get working for everything except DCC file transfers over Internet Relay Chat (IRC) (e.g. using the mIRC client).
Getting DCC to work over any NAT router can be a pain if you don't know what you are doing but the 585v7 was doing something downright bizarre to IRC/DCC traffic. The solution was difficult to find so I've put the information here in the hope that it will help others. The good news is that it's really simple once you know what to do.
(My experience was with a Thomson 585v7 with firmware version 7.4.20.3 (also known as 7.4.K.3), given to me by UK ISP Be in December 2008. Perhaps later firmware versions will correct the problem.)
-
(Skip this section if you already know all about NAT port forwarding for DCC.)
Before we get into the specific problem with the 585v7, let's briefly cover the basics of DCC over NAT routers.
If you want to know more about NAT routers and port forwarding for various games and applications then you should read one of the sites dedicated to the topic. Port Forward is a good place to start.
Each computer on your home network has an internal IP address which other computers and devices (like the 585v7 itself) can use to talk to it. Unless you have a special type of Internet connection, those internal IP addresses will not work outside of your home network. A computer in someone else's house cannot send a message to your computer using that address.
Your modem or router is usually the only thing in your house that has an external IP address. (It will also have an internal IP address, but that isn't important to this discussion.)
(Until the whole Internet moves to IPv6 addressing -- which is a bit like when phone companies add an extra digit to all of their telephone numbers -- the number of possible external IP addresses will remain quite limited and reserving an external IP address range will remain fairly expensive. Those are the primary reasons why your ISP will only give you one external IP address to share among your machines, although there are other reasons as well.)
When one of your home computers talks to another computer on the Internet it uses your router as a go-between. To the computer on the Internet it looks like all requests are coming from your router, using its external IP address. The computer you are connecting to has no idea about your computer or is internal IP address.
All of that is handled transparently by the router, and that's pretty much what NAT (Network Address Translation) is all about. When you connect to a web server you're really telling your router to connect to it for you and pass back the data that it receives. The router knows it was your computer which made the request so it knows which computer, on your home network, to send the data back to.
That's great for outgoing connections but what about incoming connections? The only thing a computer on the Internet can do to contact one of your computers is send a message to your external IP. That message will arrive at your router and will not contain any information about which of your home machines it is really for. By default the incoming connection will simply be rejected. This is where port forwarding comes in.
What are ports? If you think of your computer as an office building and the programs running on your computer as employees then ports are like telephone extension numbers. If you call the switchboard and ask for an employee's extension then they will connect you to the phone on that person's desk. Similarly, if you connect to another computer on port 80 then you will be talking to whichever program (if any) is associated with port 80. (Port 80 is usually used by web servers but that detail isn't important.)
Port forwarding is something that NAT routers can do to allow incoming connections to talk to programs on your computers. You can tell your router, if an incoming connection arrives on port 80 then forward it to my desktop PC, but if a connection comes on port 81 then forward it to my laptop.
Now, when your IRC client wants to send a file using DCC to another person's IRC client, the person receiving the file has to make a connection back to your machine to get the data. At the start of the request your IRC client will tell the other one, "I have a file called Moo.zip, it's 800 bytes in size, please connect to <IP address> on <port>." For that to work the IP address passed to the other machine must be your external IP address because that's the only one that means anything to the other machine. And, for it to work, the port number will need to be one whch your router knows it should forward to your machine, otherwise that return connection will be thrown away. Good clients like mIRC automatically work out what your external IP address is so that part is not a problem. (The automatic lookup can go wrong but only with very unusual networks.) As for the port forwarding, that's something you usually have to configure yourself on the router.
The Port Forward website has easy-to-follow guides to setting up port forwarding for hundreds of differnet applications. It has different guides for different types and brands of routers so you should start on the front page and find he guide which is right for you. If you are reading this page then you're probably looking for the guide for port forwarding mIRC DCC on the Thomson/Alcatel 585.
Note that you can make DCC sends work for multiple computers on your network by configuring the router and mIRC to use a different port range for each computer.
Important: Before you set up port forwarding for DCC, try sending a file to someone to see if it works by default. The 585v7 has some clever stuff built into it which tries to do all of this work for you without you having to do anything at all. It's actually that clever stuff going wrong which is the reason I am writing this page, but you may find that it works for you!
-
As per the important note directly above, it's possible that IRC DCC will work for you without you having to change anything at all. I have never tried the 585v7 with a default configuration and mIRC set to use its default DCC port range. When I got the 585v7 my mIRC installations were already set to use custom port ranges and I was used to having to forward those ranges to each machine, as described above. If everything works for you then great and you can stop reading! If not, though, you may experience something quite strange:
With ports correctly forwarded to each machine and matching mIRC configurations I found that DCC sends usually failed because the other computer could not establish the return connection. Strangely, though, if did several send attempts at once then some of them worked. Even more strangely, attempts which appeared to have failed would instantly start working when I made additional attempts (which themselves usually failed). What on earth was going on?
First I confirmed that the ports really were forwarded to my machine (using NetCat to listen on the ports while using telnet to connect to them from a remote computer and see if what was typed at the remote end appeared at the local end). That worked 100% of the time.
The forwarding works. Is mIRC listening on the right ports? I ran Wireshark to see what mIRC was actually telling the remote computer to connect to. If you filter Wireshark's output to just the IRC traffic and then tell it to parse the network packets as IRC data then it will show you the conversation between yourself, the IRC server and the person you are trying to DCC send to. I saw mIRC telling the other person to connect back to my external IP on one of the ports in the range I had forwarded. That looked good. I then used TCPView to confirm that mIRC.exe was listening on that port. It was indeed...
But... hang on a minute... Wireshark showed that the other computer was attemping a connection back to mine on a different port within the forwarded range. What the...?
The friend I was trying to send to then ran something like Wireshark at his end to see what his computer was being asked to do. Bizarrely, his computer was receiving the message which mine had sent saying connect to port X except that at his end it said port Y. Impossible! Except...
The 585v7 understands and re-writes IRC traffic! It was trying to do something quite clever but completely messing it up. The router saw that I was sending a IRC DCC send request to another computer and was trying to transparently forward the required ports but going horribly wrong in the process. Maybe this works great if you have mIRC set to use the default port range and have not manually forwarded ports to your machine. With mIRC set to use a custom port range, and those ports forwarded, the router seemed to be modifying the DCC send request so that it used a random other port within the forwarded range. That explained why sometimes things did work when multiple files were sent at once, or soon after each other. When it worked it was because it was randomly changing the port number to that of one of the other transfers.
-
If that automatic IRC re-writing actually worked then it would be a great feature. It saves you from having to manually forward port ranges yourself and it's also more secure because it only forwards ports to your machine when they are actually being used. Unfortunately it doesn't work. The good news is that you can turn it off. The bad news is that you have to use the router's low-level telnet interface as the setting is not exposed via the friendly web interface.
Important note: You can completely screw-up your router's configuration by doing the wrong thing in its telnet interface. You are strongly advised to back-up your router configuration (using the web UI) before doing anything, and don't start typing random commands to see what happens. Don't use any of the Flush commands in particular!
You will need a Telnet client. (If you're on Windows then I recommend PuTTY.) You need to make a Telnet connection to the router using its internal IP address, probably 192.168.1.254.
If the telnet connection works then the router should ask you for a username and password. Use the same one that you use to access the router's web configuration. By default the username is Administrator and the password is blank (just hit return). If you have router with the O2 firmware then you might need to find the Super-User login to get to the Telnet interface (Google should help you there).
If you're in then you should see something like this:
Type connection bindlist and hit return. You should get back a list like this:
Application Proto Portrange Flags
IP6TO4 6to4 0
PPTP tcp 1723
ESP esp 0
IKE udp 500
SIP udp 5060 SIP_ALG:E RTP_predict_for_term_SIP_ALG:E
CU/SeeMe udp 7648
RAUDIO(PNA) tcp 7070
RTSP tcp 554
ILS tcp 389
ILS tcp 1002
IRC tcp 6660-6669
H323 tcp 1720
FTP tcp 21
JABBER tcp 5222
JABBER tcp 15222
GAME(UDP) udp 27010-27011
LOOSE(UDP) udp 67
LOOSE(UDP) udp 69
I've highlighted the line near the middle where you can see the router has bound the IRC "application" to ports 6660 to 6669. That means that the router's special IRC behaviour will happen on those ports which are the ones typically used by IRC servers.
To stop that nonsense, type connection unbind application=IRC port=6660-6669 and hit return. (If you ever need to undo this for some reason I think you just follow the same steps but use bind instead of unbind. I have not actually tried this, though.)
Run connection bindlist to confirm the IRC line is no longer there. You should see something like this:
If everything looks good run saveall to save the new configuration and then run exit to close the telnet window.
One more thing to do: Restart all of your IRC clients. Any existing connections will retain the old, unwanted behaviour. (You may have to restart the router completely but I don't think I had to. Not sure...)
Shameless plug for my favourite piece of software
Check out my guide to Directory Opus, a file manager for Windows.
