Regarding DCC (Eggdrop and it's port abilities)

[Gewan]

Hi!

I'm running Eggdrop on a box with no port limitations. However, I can't seem to make it work for users behind NAT firewalls (heavily port-restricted such) to connect directly. Am I missing out on some part of possible configuration, or is it simply not possible for eg. a port-restricted mIRC user to /DCC CHAT EGGDROP using passive mode? I've tried uncommenting the port range definition in the eggdrop.conf, but to no avail. Also, "my-ip" is set correctly, and there's no vhosts or funky stuff like that. A simple line directly to the Internet is all. Strange thing is, if this eg. port-restricted mIRC user is pushing a /CTCP EGGDROP CHAT, then Eggdrop will DCC CHAT back to the user, from what I can see using the "listen all" port. Is this the only way? Or can I enable port-restricted users to passively DCC CHAT into Eggdrop?

Ty in adv~

[Trixar_za]

You could try disabling the dcc sanity check - I know it causes problems with DCC connections sometimes.

DCC Chat doesn't work for me at the moment, so I use the telnet connection instead. It's pretty much the same as DCC, only you need to telnet into the bot.

[nml375]

For users behind Filtering routers or NAT's, sending DCC Chat request will most likely not work. The "/ctcp chat" feature is eggdrop's way of working around the issue.

To get technical, when a client issues a DCC Chat requests, it will start listening on a randomly selected port, and send the IP and port number to the remote party, and then wait for the other end to connect. If the client is behind a NAT or Filtering router, the router will most likely not pass the connection attempt through to the client.

A user could add appropriate port forwardings and/or pass-through rules to the router, provided they've got access and permissions to do that; and possibly configure their client to only use those ports. This is, however, beyond the control of your eggdrop.

[Gewan]

Thanks Trixar_za & nml375 for your quick responses. Much grateful!

You could try disabling the dcc sanity check - I know it causes problems with DCC connections sometimes.

Yet this is '0' by default, mine is anyways.

@nml375:
Already then. But what about eg. mIRC's "/dcc passive on" option? Is it non-compliant with the true nature of DCC, and thus why it's not working? I've tried this see, but it's not working =I

[nml375]

To be frank, I've never encountered this feature of mirc. I did a little googling, and from what I've seen, it's pretty similar to eggdrop's /ctcp chat;
It sends a requests, which instructs the remote party to make a new dcc chat request. Mirc's way seems to be sending a "CTCP DCC CHAT"-request (/dcc chat) with the port being set to 0.

I suppose something like this could enable support for this kind of "reverse dcc"; It's untested and written from memory, but should work..

Code: Select all

bind ctcp - "DCC" check_reversedcc
proc check_reversedcc {nick host handle target key text} {
  if {![isbotnick $target]} {
    return 0
  }
  lassign [split $text] proto arg ip port
  if {[string equal -nocase $proto "CHAT"] && $port == 0} {
    *ctcp:CHAT $nick $host $handle $target $key $text
    return 1
  }
  return 0
}