Skip to content
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

Jump to bottom

Eggdrop doesn't finsish DNS resolving an incoming telnet connection #1174

Closed
DasBrain opened this issue Jun 13, 2021 · 6 comments · Fixed by #1319
Closed

Eggdrop doesn't finsish DNS resolving an incoming telnet connection #1174

DasBrain opened this issue Jun 13, 2021 · 6 comments · Fixed by #1319

Comments

@DasBrain
Copy link
Contributor

DasBrain commented Jun 13, 2021 •
edited

As user, you won't see any password prompt, but the telnet connection is established.
User input is ignored, no banner is shown.

When the connection is closed by the client (Ctrl++, Q), then a "Lost connection while resolving hostname" line will be logged.

Log from my bot with .console +d

<BrainBot> [06:15:15] net: connect! sock 4
<BrainBot> [06:15:26] net: eof!(read) socket 7
<BrainBot> [06:15:26] Lost connection while resolving hostname [1.2.3.4/52680]

(IP redacted.)

This happens spontaneously, no known way to reproduce.
It also sometimes fixes itself.

Eggdrop version: 1.9.0, dns module, no tdns.
@crazycatdevs crazycatdevs mentioned this issue Jun 17, 2021
Closed
@vanosg
Copy link
Member

vanosg commented Jun 17, 2021

Reference #1175

@ERR1R
Copy link

ERR1R commented Jul 5, 2021

i have the exact same issue.. after a while i get this:

Lost connection while resolving hostname [1.2.3.4/52680]

When i connect multiple times with putty, the connection comes back and everything works again.
When i run putty just once nothing happens (times out)

@Lord255
Copy link

Lord255 commented Nov 1, 2021

try set
set resolve-timeout 0

# Set here the amount of seconds before giving up on hostname/address lookup
# (you might want to increase this if you are on a slow network). The default is
# RES_TIMEOUT, which is generally 5, the allowed maximum is RES_MAXRETRANS (see
# <resolv.h>).
#set resolve-timeout 5
set resolve-timeout 0

@crazycatdevs
Copy link
Contributor

crazycatdevs commented Feb 13, 2022

Short comment: the proposed solution doesn't work for me.
My eggdrops (1.9.1) doesn't respond to a telnet when they run for a certain time (unable to say how much, less than 1 hour).

Only one doesn't reproduce the bug, but it's on a raspberry (raspbien / home eggdrop). All others (debian / 2 different shells) have the bug, no matter if they are on a botnet or not.

@vanosg
Copy link
Member

vanosg commented Jun 4, 2022

Has anyone seen this behavior in an eggdrop running tdns, or without the DNS module? If, no, I'm going to close this issue, we believe is fixed with the tdns capability.

@crazycatdevs
Copy link
Contributor

crazycatdevs commented Jun 4, 2022 •
edited

I forget to coment the loadmodule dns on my eggdrops 1.9.2.
I just did it, will answer you tomorrow (usually, 24h is largely enough to get the bug)

Edit: the bug alway exists with eggdrop 1.9.2 and Threaded DNS core enabled

thommey added a commit that referenced this issue Aug 22, 2022
@thommey
Fixes a DNS bug when DCC connections were disconnected while the DNS …
8cf2b0a 
…request was pending. Fixes #1174

In a host->IP scenario, devent_t contains a malloc'd copy of the hostname.
In the IP->host scenario however, devent_t contained an outside allocated pointer
to ip_addr (sockname_t).
In the Tcl case it was embedded in the tclinfo structure, but in the DCC case
it pointed to the idx information in dcc[i].
"Lost connection" wipes that idx info and invalidates it, invalidating
the information about the pending dns request. That would then get stuck with
invalid data.

As soon as the idx is re-used however, the address is overwritten by answer(),
and dns thinks it already sent a request for that IP, also it gets stuck.

The fix treats IP->host the same as host->IP and dynamically allocates the IP
as it does with the hostname.

Found by: DasBrain, ERR1R, CrazyCat
Patch by: thommey
This was referenced Aug 22, 2022
Closed
Merged
vanosg pushed a commit that referenced this issue Aug 24, 2022
@thommey
Fixes a DNS bug when DCC connections were disconnected while the DNS …
aa18175 
…request was pending. Fixes #1174 (#1319)

Found by: DasBrain, ERR1R, CrazyCat
Patch by: thommey
Fixes: #1174 #1175

In a host->IP scenario, devent_t contains a malloc'd copy of the hostname.
In the IP->host scenario however, devent_t contained an outside allocated pointer
to ip_addr (sockname_t).
In the Tcl case it was embedded in the tclinfo structure, but in the DCC case
it pointed to the idx information in dcc[i].
"Lost connection" wipes that idx info and invalidates it, invalidating
the information about the pending dns request. That would then get stuck with
invalid data.

As soon as the idx is re-used however, the address is overwritten by answer(),
and dns thinks it already sent a request for that IP, also it gets stuck.

The fix treats IP->host the same as host->IP and dynamically allocates the IP
as it does with the hostname.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
5 participants
@DasBrain @vanosg @Lord255 @ERR1R @crazycatdevs