What causes "could not find hostinfo" in slackhq/nebula?

Re-run the relay listing after the relay handshake completes so the hostmap entry exists

could not find hostinfo

Error message

could not find hostinfo

What it means

In nebula's SSH debug/admin interface, sshPrintRelays iterates known relays and looks up each relay's hostinfo via hostMap.QueryVpnAddr. When no hostmap entry exists for a relay's VPN address, the relay entry is still listed but annotated with RelayFor{Error: "could not find hostinfo"} instead of its relayed IPs. This is a diagnostics-layer sentinel, not a fatal error: the relay is known but its hostinfo state is absent.

Source

Thrown at ssh.go:942

	type CmdOutput struct {
		Relays []*RelayOutput
	}

	co := CmdOutput{}

	enc := json.NewEncoder(w.GetWriter())

	if args.Pretty {
		enc.SetIndent("", "    ")
	}

	for k, v := range relays {
		ro := RelayOutput{NebulaAddr: v.vpnAddrs[0]}
		co.Relays = append(co.Relays, &ro)
		relayHI := ifce.hostMap.QueryVpnAddr(v.vpnAddrs[0])
		if relayHI == nil {
			ro.RelayForAddrs = append(ro.RelayForAddrs, RelayFor{Error: errors.New("could not find hostinfo")})
			continue
		}
		for _, vpnAddr := range relayHI.relayState.CopyRelayForIps() {
			rf := RelayFor{Error: nil}
			r, ok := relayHI.relayState.GetRelayForByAddr(vpnAddr)
			if ok {
				t := ""
				switch r.Type {
				case ForwardingType:
					t = "forwarding"
				case TerminalType:
					t = "terminal"
				default:
					t = "unknown"
				}

				s := ""
				switch r.State {

View on GitHub (pinned to dd8f660c0a)

Solutions

Re-run the relay listing after the relay handshake completes so the hostmap entry exists
Verify network connectivity to the relay peer and that its hostmap entry is not expired (check `nebula -mhostmaps`)
Restart nebula on the affected node to clear stale relay bookkeeping
Treat the error field as informational: filter relays whose RelayForAddrs contain this error rather than crashing

Example fix

// before
relayHI := ifce.hostMap.QueryVpnAddr(v.vpnAddrs[0])
if relayHI == nil {
    ro.RelayForAddrs = append(ro.RelayForAddrs, RelayFor{Error: errors.New("could not find hostinfo")})
    continue
}
// after (client-side guard)
relayHI := ifce.hostMap.QueryVpnAddr(v.vpnAddrs[0])
if relayHI == nil {
    l.WithField("vpnAddr", v.vpnAddrs[0]).Info("skipping relay with no hostinfo yet")
    continue
}

Defensive patterns

Strategy: validation

Validate before calling

relayHI := ifce.hostMap.QueryVpnAddr(relay.vpnAddrs[0])
if relayHI == nil {
    // skip or log; do not build RelayFor from nil hostinfo
    return nil
}

Type guard

func hasHostInfo(h *HostInfo) bool { return h != nil }

Try / catch

if relayHI == nil {
    ro.RelayForAddrs = append(ro.RelayForAddrs, RelayFor{Error: errors.New("could not find hostinfo")})
    continue
}

Prevention

Query the hostmap only after relays have completed handshakes
Monitor hostmap eviction vs relay registration timing
Treat relay listing output as advisory, not authoritative
Re-run the query if the node recently restarted

When it happens

Trigger: Running `nebula -musage`/ssh command that prints relays when hostMap.QueryVpnAddr(v.vpnAddrs[0]) returns nil — i.e., a relay is recorded in the relays map but its HostInfo was evicted, not yet learned, or the node restarted with stale relay state.

Common situations: Inspecting relay state on a lighthouse or relay node shortly after startup; a relay peer that went away and whose hostmap entry expired while relay bookkeeping remains; querying during handshake so the relay's hostinfo is not yet populated.

Related errors

AI-assisted analysis of slackhq/nebula@dd8f660c0a (2026-09-03). Data as JSON: /api/errors/34497ebdabceab33. Report an issue: GitHub.