func=get_avai_ip returns errorcode=-22 on QuTS hero h6.0.0 Beta — corroborates #46 with bisection data

[arnstarn]

func=get_avai_ip returns errorcode=-22 on QuTS hero h6.0.0 Beta — corroborates #46 with bisection data

Summary

I reproduced the publish-time failure pattern from #46 ("driver fails to publish a valid portal when QNAP has multiple IP-bearing interfaces") on QuTS hero h5.3.3.3424 GA, and separately discovered that QuTS hero h6.0.0 Beta ships a different cgi regression that fails much earlier (at backend init). Both end up with the same user-visible error — no interface is available; please check the feature 'networkInterfaces' is valid; maybe the interface don't have valid ip — but they have different root causes. I'm filing this as a separate report because the h6 cgi regression isn't covered in #46 and the bisection might help someone narrow either fix.

Environment

• CSI driver: v1.6.0 (Helm chart from this repo, kubeVersion bumped via my PR Helm: bump Chart.yaml kubeVersion to <= 1.35 #48 to deploy on k8s 1.34)
• Kubernetes: v1.34.3 (Talos Linux v1.11.6, siderolabs/iscsi-tools extension installed per README)
• Backend driver: qnap-nas
• NAS A (triggers the bug): TS-873AeU on QuTS hero h6.0.0.3397 build 20260206 (Beta) initially; later downgraded to h5.3.3.3424 build 20260305 (GA, Official) to bisect.
  • Network: bond0 (LACP across 2× 2.5GbE) with IP <lan>.71 directly + qvs0 (Virtual Switch wrapping bond1, LACP across 2× 10GbE) with IP <lan>.70. Two IP-bearing interfaces visible to func=get_avai_ip.
• NAS B (does not trigger): TS-X63 on QTS 5.2.9.3410 GA. Single IP-bearing interface (qvs0 on Virtual Switch over a single 10GbE physical NIC; the two onboard 1GbE adapters are physically disconnected). One row returned by func=get_avai_ip.
• Both NAS units configured against the same backend secret schema (storageDriverName: qnap-nas, https: true, port: 443, trustedCACertificate provided for self-signed wildcard cert).

Symptom

• Backend init succeeds: phase=Bound, status=Success for both backends.

• tridentctl/CRD-side LUN provisioning succeeds: PVC binds, LUN appears on the QNAP, target created with the correct IQN.

• ControllerPublishVolume fails for NAS A only:

  AttachVolume.Attach failed for volume "pvc-...":
  rpc error: code = Unknown desc = no interface is available;
  please check the feature 'networkInterfaces' is valid;
  maybe the interface don't have valid ip
  

• Identical configuration shape applied to NAS B publishes and mounts cleanly. The only meaningful difference is NAS A having multiple IP-bearing interfaces.

Reproduction

1. Set up two QNAP NAS backends, both running qnap-csi-driver v1.6.0:
   • NAS A: configure two interfaces with valid LAN IPs (e.g. one bond + one virtual switch on top of another bond).
   • NAS B: configure one IP-bearing interface (e.g. one virtual switch); other physical adapters disconnected/unconfigured.
2. TridentBackendConfig per NAS, identical aside from storageAddress and networkInterfaces (set to a name visible in qcli_iscsi -p for each).
3. Apply two StorageClass resources, one per backend, each selecting that backend's virtual pool.
4. Create a PersistentVolumeClaim against each StorageClass and bind a Pod to it.

Result: NAS B Pod reaches Running. NAS A Pod stays in ContainerCreating with the no interface is available error from attachdetach-controller. Identical config; the only delta is the number of IP-bearing interfaces on the NAS.

Bisection: separate h6.0.0 Beta cgi regression

While reproducing, I instrumented iscsi_portal_setting.cgi on NAS A (which symlinks to target_mw.cgi on hero) with a logging shim, then queried directly with curl:

On h6.0.0 Beta:

GET /cgi-bin/disk/iscsi_portal_setting.cgi?func=get_avai_ip&iqn=&sid=...
→ <errorcode>-22</errorcode><result>-1</result>

get_avai_ip is gone from target_mw.cgi's dispatch on h6 — the binary's only func= strings via strings(1) are extra_get, extra_lun_index, get_be_prod_type_str, get_domain_user_list*, get_lun, get_mount_poing_prefix, get_sys_richacl, get_target_group_list. No get_avai_ip.

The cgi-server (storage-api-server sidecar) calls this endpoint at Add Storage time, parses the empty response as no interfaces available, and downstream attach fails identically to #46. We hit this on h6 even with one of the two interfaces filtered out — the failure is at backend init, not just publish.

On h5.3.3 GA (after downgrade on the same hardware):

GET /cgi-bin/disk/iscsi_portal_setting.cgi?func=get_avai_ip&iqn=&sid=...
→ HTTP 200 with full <info><row>…</row></info> for each IP-bearing interface,
   <count>2</count>, <result>0</result>

So get_avai_ip works correctly on h5.3.3. The h6 cgi regression is gone, and we cleanly reproduce the multi-interface bug from #46: backends bind, LUN+target create, publish fails.

This bisection establishes:

• The "no interface is available" error has at least two distinct upstream causes: (a) h6.0 cgi regression, (b) issue QNAP CSI publishes invalid iSCSI portal metadata (p1: "", p2: <ip>) for new and existing volumes even with networkInterfaces configured #46's multi-interface mishandling.
• For h5.3.x and earlier hero firmware, only (b) applies.
• For h6 Beta, both (a) and (b) would trigger; (a) hides (b) because it fails earlier.

I have full request/response captures from both firmware versions if helpful — happy to attach.

Workarounds we attempted (none viable long-term)

1. Set networkInterfaces to the interface_name field (bond0, qvs0) — driver matches against display_name, so this returns adapter (...) not found at backend init.
2. Server-side cgi shim that intercepts func=get_avai_ip and filters one row — works for the URL path but breaks target_mw.cgi's session/auth handling on the next call (cgi binary returns errorcode=-22 when invoked through a wrapper on h5.3.x).
3. Remove the IP from one of the NAS A interfaces — fixes the symptom for our case but is brittle: any re-IP undoes it, and forces the user to keep one bond IP-less indefinitely.
4. Fork the driver and patch — driver is closed-source on this repo (artifacts only, no Go source), so this isn't an option without QNAP releasing the source.

What would help

1. Confirmation that the multi-interface issue (QNAP CSI publishes invalid iSCSI portal metadata (p1: "", p2: <ip>) for new and existing volumes even with networkInterfaces configured #46) is on the roadmap and a target version, since on real-world hero deployments with VMs (where Virtual Switches with their own IPs are standard) plus a separate management bond IP, this triggers reliably.
2. A note in the README's "Software Prerequisites" / known issues about the h6.0 Beta cgi behavior, since users may end up on h6 Beta without realizing the driver hasn't been updated for it.
3. (Stretch) The driver source. Even a partial open-source release of the controller would let community contributors land QNAP CSI publishes invalid iSCSI portal metadata (p1: "", p2: <ip>) for new and existing volumes even with networkInterfaces configured #46-class fixes faster.

Thanks for maintaining this driver and for the recent v1.6.0 release.

[arnstarn]

Friendly bump — wanted to flag this issue is still reproducible against v1.6.0 with QuTS hero h5.3.3.3424 (the GA we downgraded to after h6.0.0 Beta hit a separate func=get_avai_ip regression).

Given @Shanna-chen's confirmation on #46 that the networkInterfaces filter isn't being applied at portal publish time, I assume #49 is essentially the same root cause surfaced through the bisection. Happy to close as duplicate of #46 if you'd prefer to consolidate — just wanted to make sure the hero bisection data wasn't lost.

Any rough sense of which release will carry the fix? We're currently parking corp qnap-corp-iscsi StorageClass on multi-IP QNAPs and would love to unpark when there's a target version.