Forums Connection Issues Cant DCC send

Well, if you can help me ....
I've got a Sitecom wireless router, model WL-304. I use DHCP and standard Windows firewall. mIRC is deblocked in my firewall. http://portforward.com gives me the following instructions:
- setup ports 10051-10070 in mIRC
- use a static ip address
- login into the router and select advanced ... virtual server
- forward ports 1024-5000, but only instructions for ports 1024-1036 are given

This doesn't work for me. And I don't understand why I should forward 1024 etc while in mIRC ports 10051-10070 have to be setup. Although I use DHCP, the ip address of my PC is always the same.

So, what is wrong with the instructions? And, after forwarding, should I use the local ip address of my PC or the public address of my router in mIRC local info?

I don't see where the guide is on the site, but the guide is wrong if it tells you to use different ports in mIRC and in the router.

Whatever port range you setup in mIRC has to be the exact same port range you setup in your router.

For example, if you want to use 1024-1036 in mIRC, you need to forward 1024-1036 in the router. If you want 10051-10070, forward those. Basically it has to match up. This is likely why your setup wasn't working.

See: http://portforward.com/english/routers/port_forwarding/Sitecom/WL-304/mIRC_DCC_-_IRC_DCC.htm

Wow... that's the first time I've seen one of their tutorials that was messed up like that. Ignore the ports they show and select a range that is the same in both mIRC and the router. They should be forwarded as TCP or TCP/UDP (not just UDP). The static IP address is only an issue if you have multiple computers using the router and they aren't keeping the same IP (they swap IPs occasionally). For example, you might have 192.168.1.2 normally, but one day your computer is off and the other computer ends up getting that IP and when you turn yours on, you end up with 192.168.1.3. If that happens, the forwarded ports won't work for you because they are set to use 192.168.1.2. Because that can happen, it's useful to set your computer up as static so that it always has the same IP. If you don't have that issue, it's not really a big deal... though I do prefer having it set to static as it doesn't cause problems and is easy to do and prevents the possibility of a problem later on.

@argv0 and @Riamus2: Thank you very much for your help and your patience. I got it working now, I can send with passive set to off. I also understand why passive on is not the right solution, thanks to your explanations.
Thanks again!

well, I think I have a new twist on dcc connection troubles, after reading this thread and several other references. If I've somehow missed a crucial explanation, please re-direct me.

After following carefully the instructions for setting up port-forwarding in my DSL router, I restarted two separate copies of the client on two separate computers on my local network. Each computer was the target of a separate range of port-forwarding. Passive mode is disabled.

I verified that the IP addresses seen by each client reflect the true public network address, not the local network.

For reference: the public address is 71.135.xxx.yyy.

My testing was quite straightforward: try both /dcc chat and /dcc send from each computer to the other.

In all cases, when the DCC was initiated, the target computer showed the connect dialogue, but also displayed the origin of the request as being from an unknown address: 208.88.177.68.

Now that completely flummoxes me! I can follow the traceroute completely outside of my ISP's network, so I don't think there is some sort of proxy occurring: I just can't explain the source of this address!

Clearly, something in my configuration (router and/or mIRC) is incorrect, but I just don't see it!

I am also unable to connect with outgoing dcc requests to computers off my local network, and while I can usually successfully receive incoming send requests, sometimes I cannot connect for incoming chat requests, though I can't be certain that the problem is at my end. In those unsuccessful cases I've not been able to verify an incorrect IP address.

I'm totally open to suggestions as to how to proceed to troubleshoot my problems.

Any thoughts?

As far as /dcc chat or send to another client on your network, that may or may not be possible depending on your router. Some routers allow it, others do not.

Are you certain you have the right IP in the router for the port ranges (192.168.1.x)? And are you sure the port ranges match what is in mIRC?

absolutely certain that port forwarding matches the individual DCC port ranges for each computer

as far as the other matter, Linksys tech support was no help at all

This is inaccurate. /dcc chat from within your LAN works with the vast majority of routers- there are only a very small number of exceptions, and they're usually older models, that don't do proper NAT in some cases. /dcc send'ing yourself a file is actually a fairly reliable way to test if your DCC is configured correctly.

Are you connecting to IRC through a BNC or proxy?

well, on each separate computer, /hostaddr <mynick> , /echo my ip is $ip , and /localinfo -u all report exactly the same ip address as my router knows as the public address

clearly the 208.x.y.z address is wrong, but I've no idea where it originates... and how does it apparently replace what should be the correct address?

no, not using a proxy, nor a bouncer

Maybe this is a stupid idea, but ... I did a DNS on that 208.x.x.x ip and I wouldn't like to visit the site behind it ..... Is there a chance that your PC is infected?

I run anti-virus on each computer and server, so I'm pretty sure that I'm virus-free...

and that is some sort of geolocation service, though I didn't delve very deeply into it

gets weirder: http://208.88.177.68 goes directly to an apache server test page at the Centos project

whois shows the address registered to FriendFinderNetworksInc, a social networking site

nslookup shows x-68.streamray.com as the owner, so not sure anymore

...and by the way, I'm not a client of Friend Finder, nor whatever Steamray is (today I've seen both porno and geolocation), and I do not run an apache web server...

later tonight I'll capture all irc/DCC traffic with a sniffer and see if I can figure out where the 208.x.y.z address is introduced... that might not tell me how or why, but at least I'll know where

I'm pretty sure you're infected.

FriendFinderNetworks, Inc. is owned by Penthouse (yes, that penthouse), and is the company that runs the AdultFriendFinder dating sites. I don't think your IRC server is associated with them, and I'm guessing you aren't either.

absolutely not infected...

this is where it starts to get weird, because I read and thought I'd understood the operation of the DCC protocol....

running Ethereal on the source and destination computers on my local network, as well as Windows Network Monitor on the server that provides a DNS resolver showed the following:

for a DCC CHAT request
1. originating CLIENT sends a NOTICE to the IRC SERVER with a brief message giving the destination NICKNAME, "DCC CHAT" and the destination CLIENT IP address in dotted decimal form enclosed in parentheses, for example
"NOTICE test-nick DCC CHAT (71.135.113.42)"

2. that is followed immediately (next TCP packet) with a PRIVMSG to the IRC SERVER with a brief message giving the destination NICKNAME, "DCC CHAT chat" followed by the decimal value of the destination CLIENT IP address, and the PORT number to use, for example
"PRIVMSG test-nick DCC CHAT chat 1200058666 54018"

3. the IRC SERVER then passes these two packets to the destination CLIENT for processing -- the destination CLIENT PORT number used is NOT in the DCC PORT range.

4. the destination CLIENT displays the expected dialog box about an incoming chat request, but when the Accept button is pressed, nothing happens, including NO messages on the wire, eventually the attempt times out at the requesting end.

Okay, any thoughts on what to look for next?

To be certain, I loaded fresh copies of mIRC and reinstalled, double-checking to avoid inadvertently making any changes to the DCC defaults, other than the port range to match my router.

This is still a puzzlement, wrapped in an enigma....

a bit more experimentation has yielded the following:

1. both DCC CHAT and DCC SEND usually (*BUT NOT ALWAYS!*) semd the target client the true IP address of the requestor. When the requestor's true IP address is not sent, the IP address provided seems to always be the IP address of the SERVER.

***CAN ANYONE EXPLAIN WHY SOMETIMES THE SERVER ADDRESS IS SUBSTITUTED FOR THE REQUESTING CLIENT ADDRESS???

2. even when the DCC requests contain the true IP address of the requestor, the DCC accept dialogue box shows what I believe is the results of a /userhost lookup on the requesting nickname -- which in the case of my ISP the response is an encoded version of the IP address which always fails when doing a DNS lookup, resulting in no reply to the requestor.

***DOES ANYONE HAVE A SUGGESTION FOR CIRCUMVENTING THIS ANOMALY???

If you're having issues with DNS preventing sending, then change your DNS servers. You don't have to use your ISP's. Try Google's free DNS servers-

8.8.8.8
8.8.4.4

since when is google authoritative for my ISP?

the issue is that mIRC appears to use the result of a /userhost against the DCC requestor's nickname... I've had sniffers watching both clients and the uplink to the server... the /userhost is sent from the target client to the server, who answers directly (without contacting the client), presumably from cached state information -- I started sniffing after the clients had logged-in to the server so missed the identity exchanges...

as everything I can see or display from the individual clients leads me to believe that it's the IRC server that is getting the obscured address in a url that won't resolve... so just exactly how is using google supposed to help? to prove that, I shut off dhcp and manually set the ns addresses (verified with ipconfig) and got the same results...

I think I'll try using an entirely different IRC server to see if there is different behavior, and if so, ask some questions of the admins...