New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DCC file send / chat issues (IP variables) #413

Closed
maimizuno opened this Issue Jun 1, 2017 · 9 comments

Comments

Projects
None yet
2 participants
@maimizuno

Even respecting all of the config-file notes about setting nat-up / listen-addr / vhost4 & vhost6 / prefer-upv6. and my-ip, there's one scenario that isn't mentioned:

When a bot is behind a router (NAT) on a single IP (think: home network on a router), while DCC CHAT can be mitigated (somewhat) with the proper combination of variables, DCCSEND (file sending) does not obey this fully!

DCCSEND will obey $::net-ip only.

[s->] PRIVMSG Domino :�DCC SEND leather_wear.txt 128129XXXX 23710 2351

This LONGIP resolves to my WAN IP address (set in $::nat-ip). The only way to get the bot to send directly to me, successfully, is:

(1) set $::nat-ip to the bot's LAN address
-- DCC CHAT works only for me; fails for others not on my LAN
-- DCCME (scripted command) I have to punch holes in my firewall to allow it to work.
-- DCCSEND works only or me; fails for all others

(2) with $::nat-ip set to WAN address
-- DCC CHAT works for others not on my LAN (if I have holes punched through my firewall). Fails for me
-- DCCME works only if I have holes punched through my firewall, AND, configure reserved-portrange , AND, my chat client (mIRC) is set up to use specific (matching) port ranges
-- DCCSEND fails for me, works for all others

No combination works for all circumstances.

@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg Jul 8, 2017

Collaborator

Are you and the bot on the same LAN in this scenario?

Collaborator

vanosg commented Jul 8, 2017

Are you and the bot on the same LAN in this scenario?

@maimizuno

This comment has been minimized.

Show comment
Hide comment
@maimizuno

maimizuno Jul 9, 2017

We are on the same LAN, yes. Though, to be thorough, I moved the bot to another location [box]; and there we no changes to the results.

We are on the same LAN, yes. Though, to be thorough, I moved the bot to another location [box]; and there we no changes to the results.

@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg Jul 9, 2017

Collaborator

Another location on the same LAN?

Collaborator

vanosg commented Jul 9, 2017

Another location on the same LAN?

@maimizuno

This comment has been minimized.

Show comment
Hide comment
@maimizuno

maimizuno Jul 9, 2017

not same LAN; completely diff* box/IP.

not same LAN; completely diff* box/IP.

@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg Jul 9, 2017

Collaborator

I'm a little more confused over what the problem is now, then - there are some networking configuration tricks that need to happen if you're both on the same LAN, but if it outside your LAN, nat-ip should be set to the bot's WAN ip, port forwarding should configured to allow to the reserved portrange.

So, for clarity, this is how I see it should be working, on a bot not on your LAN, with nat-ip set to WAN, and the bot's router properly set to port forward the reserved portrange:

  • You should be able to ctcp chat the bot (Bot sends its nat-ip IP).
  • You should be able to dcc chat the bot, if you have set a port range for DCC in your client and set up your LAN router to port forward (you can test this by DCC chat'ing someone else who is not the bot, just to confirm it works in general and is not the bot's fault) (This is independent of any bot setting)
  • The Tcl command 'dccsend', when used on the bot, should initiate a send request to you, using the IP you set in nat-ip.
  • I don't know what DCCME is/does

And again, this will not be true if the bot resides on the same LAN as you, this is only for a bot behind a NAT on a different network. Is everything I listed above true for you on this scenario? Thanks

Collaborator

vanosg commented Jul 9, 2017

I'm a little more confused over what the problem is now, then - there are some networking configuration tricks that need to happen if you're both on the same LAN, but if it outside your LAN, nat-ip should be set to the bot's WAN ip, port forwarding should configured to allow to the reserved portrange.

So, for clarity, this is how I see it should be working, on a bot not on your LAN, with nat-ip set to WAN, and the bot's router properly set to port forward the reserved portrange:

  • You should be able to ctcp chat the bot (Bot sends its nat-ip IP).
  • You should be able to dcc chat the bot, if you have set a port range for DCC in your client and set up your LAN router to port forward (you can test this by DCC chat'ing someone else who is not the bot, just to confirm it works in general and is not the bot's fault) (This is independent of any bot setting)
  • The Tcl command 'dccsend', when used on the bot, should initiate a send request to you, using the IP you set in nat-ip.
  • I don't know what DCCME is/does

And again, this will not be true if the bot resides on the same LAN as you, this is only for a bot behind a NAT on a different network. Is everything I listed above true for you on this scenario? Thanks

@maimizuno

This comment has been minimized.

Show comment
Hide comment
@maimizuno

maimizuno Jul 9, 2017

Clarification: "DCCME" just makes the bot send a "dcc chat" request to the client, to initiate the DCC CHAT from the other side (ctcp dcc).

maimizuno commented Jul 9, 2017

Clarification: "DCCME" just makes the bot send a "dcc chat" request to the client, to initiate the DCC CHAT from the other side (ctcp dcc).

@maimizuno

This comment has been minimized.

Show comment
Hide comment
@maimizuno

maimizuno Jul 9, 2017

I will play with the configurations more; if I can provide more insight, I'll comment further.

I will play with the configurations more; if I can provide more insight, I'll comment further.

@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg Jan 19, 2018

Collaborator

Is there any further comment on this issue, or can I close it?

Collaborator

vanosg commented Jan 19, 2018

Is there any further comment on this issue, or can I close it?

@maimizuno

This comment has been minimized.

Show comment
Hide comment
@maimizuno

maimizuno Feb 5, 2018

I am unable to provide any further tesdting (due to personal circumstances). Close; I will re-comment if the issue is found again.

I am unable to provide any further tesdting (due to personal circumstances). Close; I will re-comment if the issue is found again.

@maimizuno maimizuno closed this Jul 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment