cisco_asa driver absent from the virp-onode (dev) binary; document the ASA enable-credential requirement

[UWillC]

Two small ASA papercuts found bringing up an ASA5505 (9.1(7)23):

1. Driver registration. virp-onode (the dev/main binary) registers 6 drivers and logs [Watchdog] No driver for: ASA (vendor=8) — skipping, even though the build included ASA=1. virp-onode-prod registers 9 (incl. cisco_asa) and connects the ASA. Is the dev-binary omission intentional? If not, registering cisco_asa in the dev binary (or a doc note "ASA requires virp-onode-prod") would avoid confusion.

2. Enable credential. On the ASA, the account logs in at ASA> (priv-1, enable=0). The driver needs enable mode. Adding "enable":"<pw>" to the ASA's devices.json entry fixed it → ASA#, enable=1, and a show version observation verified VALID. A note in the device-config docs (ASA / any non-priv-15 account needs an enable cred) and a clearer log line ("connected at enable=0, no enable credential configured") would point operators straight at it.

---

Environment: O-Node @ 604edca, make CISCO=1 FORTIGATE=1 PANOS=1 ASA=1 LINUX=1 (+prod); Ubuntu Server 26.04, gcc 15.2, Go 1.26; target = physical Cisco ASA5505, ASA 9.1(7)23.

[UWillC]

Clarification after reading the RFC + /docs — the scope here may be narrower than my original title.

The RFC vendor registry (§15.2 / §23.6) defines CISCO_IOS, FORTINET, JUNIPER, PALO_ALTO, LINUX, ARISTA, WINDOWS, MOCK — there is no cisco_asa vendor at the spec level. And in my lab a Cisco ASA 9.1 was successfully observed (VALID / GREEN) using a devices.json entry with "driver": "cisco" against the prod binary — i.e. the cisco driver handled the ASA.

So the open question is really: is a distinct cisco_asa driver intended at all, or should the cisco driver cover ASA? Either way, the concrete, reproducible observation is the dev-vs-prod driver-set parity — the dev binary ships fewer drivers than prod, so dev users hit "unknown vendor/driver" for devices the prod binary handles. A short note in the README on which build target ships which drivers would clear up the confusion. (Workaround in my lab: use virp-onode-prod.)

[UWillC]

Correction to my previous comment — I verified in my lab and had the ASA detail wrong.

• The ASA's devices.json entry is "vendor": "cisco_asa" (with an enable cred), and the prod daemon uses it to reach the ASA (lands at ASA# after enable; observation VALID/GREEN). So the ASA genuinely depends on the cisco_asa driver — which means the original issue stands: a dev binary lacking cisco_asa can't observe an ASA. Please disregard my earlier "is a separate cisco_asa driver even needed?" framing — that was my mistake.

• The "driver":"cisco" I cited came from the /api/devices response, which (separately) does not echo the configured vendor: it reports cisco for a device whose devices.json vendor is cisco_asa. Minor /api/devices display inconsistency, flagged in passing.

• Spec note (from reading draft-howard-virp-03): the vendor registry (§15.2 / §23.6) omits cisco_asa even though the implementation supports and needs it — worth either adding cisco_asa to the registry or documenting that ASA is covered under cisco.

Net: dev↔prod driver parity (the original #6) is the real, valid issue; sorry for the noise in the reframe.