Documentation
¶
Overview ¶
Package netdiag runs a small, named sequence of layered connectivity checks (DNS, then TCP, then TLS, then HTTP) against one target, so the person who runs a deployment can see exactly which layer is broken instead of a single opaque "cannot reach it" failure.
ProbeHTTP checks a URL through all four layers, ProbeTCP stops at TCP for a service that does not speak HTTP (a mail relay, say). Each layer is a Step with its own outcome, and a layer that cannot run because an earlier one failed is reported as skipped. The package is generic and has no product logic: SeshatOS and SeshatCloud both use it, each deciding which targets to probe.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type ActOn ¶
type ActOn string
ActOn names who should act on a failed step - purely advisory, surfaced directly to whoever is running the diagnostic (typically enterprise IT).
type Result ¶
type Result struct {
Name string `json:"name"`
Target string `json:"target"`
Steps []Step `json:"steps"`
OK bool `json:"ok"`
}
Result is one target's full check sequence.
func ProbeHTTP ¶
ProbeHTTP runs DNS -> TCP -> TLS (only for an https target) -> HTTP GET against rawURL+path, timing each step. name labels the result for a caller checking several targets at once (e.g. an SSO provider's display name) - it has no bearing on the check itself.
The HTTP step's success criterion is deliberately "no transport error", never a specific status code: for a target this process doesn't own (a customer's IdP), even a 404/405 on a bare GET proves the network path works - the status code is kept in Detail for the reader's own judgment, not treated as a failure.
func ProbeTCP ¶
ProbeTCP runs only DNS -> TCP against host:port, for non-HTTP targets like an SMTP relay. No TLS step: SMTP's STARTTLS negotiates TLS *after* the plaintext connection is already open (typically port 587), so an immediate TLS handshake would misreport a perfectly healthy relay as broken - DNS+TCP already answers the question this tool exists for ("does a firewall block this port"), which is as far as a protocol-agnostic probe can honestly go without speaking SMTP itself.
Source Files