projectdiscovery/nuclei · error

no response received

Error message

no response received

What it means

Thrown by telnet.DetectNTLM when the read returns successfully but zero bytes (n == 0 with no error). This means the peer closed its sending side or delivered an empty segment — the connection is up at the TCP level but the server contributed nothing to the NTLM exchange, so there is no response to parse.

Source

Thrown at pkg/js/libs/telnet/telnet.go:264

	// Use the MS-TNAP packet crafting functions from our telnetmini library
	// Create MS-TNAP Login Packet (Option Command IS) as per Nmap script
	tnapLoginPacket := telnetmini.CreateTNAPLoginPacket()

	// Send the MS-TNAP login packet
	_, err = conn.Write(tnapLoginPacket)
	if err != nil {
		return nil, fmt.Errorf("failed to send MS-TNAP login packet: %w", err)
	}

	// Read response data
	buffer := make([]byte, 4096)
	n, err := conn.Read(buffer)
	if err != nil {
		return nil, fmt.Errorf("failed to read response: %w", err)
	}

	if n == 0 {
		return nil, fmt.Errorf("no response received")
	}

	// Parse NTLM response using our telnetmini library functions
	response := buffer[:n]

	// Use the parsing functions from our library instead of reimplementing
	// This should use the NTLM parsing functions we added to telnetmini
	ntlmInfo, err := telnetmini.ParseNTLMResponse(response)
	if err != nil {
		return nil, fmt.Errorf("failed to parse NTLM response: %w", err)
	}

	return ntlmInfo, nil
}

View on GitHub (pinned to 265b3a3dec)

Solutions

1. Verify the service is telnet and supports MS-TNAP/NTLM before probing
2. Treat 'no response' as negative evidence (no NTLM info) instead of an abort
3. Combine with a banner grab first to confirm the service identity

try { client.DetectNTLM(host, port) } catch (e) { if (String(e) === 'no response received') { /* server sent nothing: no NTLM info */ } else { throw e; } }

When it happens

Trigger: Server closes the connection immediately after receiving the MS-TNAP login packet; half-close behavior where the service shuts its write side; middlebox acknowledging TCP but suppressing payloads.

Common situations: Hardened telnet services dropping unrecognized option packets silently; devices that reset state on protocol violations without an RST visible to the reader; probes against services that are not telnet at all.

Related errors

• failed to send MS-TNAP login packet: %w
• failed to read response: %w
• failed to parse NTLM response: %w
• authentication failed
• prompt not found (read cap reached)

AI-assisted analysis of projectdiscovery/nuclei@265b3a3dec (2026-08-15). Data as JSON: /api/errors/4f0bcc0c446dc9a8. Report an issue: GitHub.