More information that is probably needed, but better more than not enough.
Linux box: IP 192.168.0.3 - Running Eggdrop
Windows box: IP 192.168.0.4
Gateway: internal IP 192.168.0.1 external IP dynamic
On Gateway: ports 2010 - 2020, 3333 and 3334 forwarded to Linux box
In Eggdrop: set reserved-portrange 2015:2020
set nat-ip external dynamic IP of the moment
set my-ip 192.168.0.3
- If left unset, or hostname is set, eggdrop will not start
listen 3333 all
In Windows IRC: DCC ports 2000 to 4000
/dcc chat:
From Windows box or Linux box
"Waiting for acknowledgement" message
telnet results
[17:57] -Wildfire (~sysop@blah.bellsouth.net)- DCC Chat (external IP)
[17:57] CTCP DCC: CHAT chat 1117540868 4558 from Wildfire (~sysop@blah.bellsouth.net)
[17:57] DCC connection: CHAT (Wildfire!~sysop@blah.asm.bellsouth.net)
[17:57] Lost dcc connection to Wildfire (~sysop@blah.asm.bellsouth.net/4558)
I assume connection lost as the bot cannot connect on port 4558, it can only use 2015 to 2020 and 3333.
/ctcp bot CHAT:
From Windows box or Linux box
"Acknowledging chat request...
Unable to Connect
DCC session closed"
From outside users, it attempts to chat on port 3333 (which is correct I think) but errors still.
telnet results
[17:59] CTCP CHAT: from Wildfire (~sysop@blah.asm.bellsouth.net)
So why does this fail? If Eggdrop is indeed listening on 3333, which is well within the range of useable DCC ports set in IRC, it should connect. I suspect whatever is wrong here is also what's causing DCC sends to fail. ANy ideas?
This is the new home of the egghelp.org community forum.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
All data has been migrated (including user logins/passwords) to a new phpBB version.
For more information, see this announcement post. Click the X in the top right-corner of this box to dismiss this message.
Portrange not working or...?
This is because you have a dumb gateway (no, it's not thick).
Standard gateways are not designed for advanced/loopback routing.
The problem is this:
1: The DCC request is sending the public IP and port.
2: Client tries connecting.
3: Client fails.
It fails because the router only deals with requests for the public IP, on the external interface, and not ont he interface for the LAN.
Some better gateways allow this, some even have the abbility to program (create a routing rule) it. The majority don't.
I suffer from this myself, and designing my mass-vhost site is a pain when you have to change the config all the time, to serv the site you are currenly on, when requested by IP.
Standard gateways are not designed for advanced/loopback routing.
The problem is this:
1: The DCC request is sending the public IP and port.
2: Client tries connecting.
3: Client fails.
It fails because the router only deals with requests for the public IP, on the external interface, and not ont he interface for the LAN.
Some better gateways allow this, some even have the abbility to program (create a routing rule) it. The majority don't.
I suffer from this myself, and designing my mass-vhost site is a pain when you have to change the config all the time, to serv the site you are currenly on, when requested by IP.
The router is actually a very old laptop running Debian so I should in theory be able to fix it now, or if not refer the maintainer of said laptop to your post and get it working