AdminUI OPC UA browser follows unreachable advertised URLs behind port NAT #806

Open
opened 2026-11-10 15:37:07 -05:00 by dohertj2 · 0 comments
Owner

Baseline functionality finding from #782 CI3, not an SDK2 regression. The AdminUI OPC UA browser selects a policy/mode match from GetEndpoints and uses its advertised URL unchanged. When the configured reachable endpoint uses a different NAT/published port, the server can advertise its private Docker hostname/internal port; the browser then fails DNS. The runtime driver already rewrites the configured host/port and passed the same fixture.

Observed SDK2: own PLC2.14.10 at127.0.0.1:32772→internal50000, all5 browser cases failed with SocketException nodename nor servname provided, or not known; driver5 passed. Correcting the fixture to matching32772→32772 gives browser5/5 and driver5/5 without product changes.

Independent ORIGINAL API parity: actual SDK1.5.378.182 Browser binaries at consumer master52d1373e, separate owned PLC127.0.0.1:32773→internal50000, also0passed/5failed/0skipped, testexit1/guard0. Public GetEndpoints discovery succeeded and returned7 URLs opc.tcp://otopcua-sdk1-browser-nat-parity:50000/. SDK family/assembly hashes and TRX retained; only that fixture was removed. Thus the different-port advertisement limitation predates SDK2.

Follow-up: preserve operator-configured host and port while retaining advertised path for matching transports, using the existing driver/Shared normalization contract; add real NAT positive/negative/security/namespace tests and keep strict certificate policy unchanged. Do not mask this by silently accepting certificates or changing transport. No browser product fix is included in the mechanical SDK migration. Evidence: /tmp/opcua-browser-sdk1-nat-parity/report.md and SDK2 CI3/focused-correction receipts (to be versioned).

Baseline functionality finding from #782 CI3, not an SDK2 regression. The AdminUI OPC UA browser selects a policy/mode match from GetEndpoints and uses its advertised URL unchanged. When the configured reachable endpoint uses a different NAT/published port, the server can advertise its private Docker hostname/internal port; the browser then fails DNS. The runtime driver already rewrites the configured host/port and passed the same fixture. Observed SDK2: own PLC2.14.10 at127.0.0.1:32772→internal50000, all5 browser cases failed with SocketException `nodename nor servname provided, or not known`; driver5 passed. Correcting the fixture to matching32772→32772 gives browser5/5 and driver5/5 without product changes. Independent ORIGINAL API parity: actual SDK1.5.378.182 Browser binaries at consumer master52d1373e, separate owned PLC127.0.0.1:32773→internal50000, also0passed/5failed/0skipped, testexit1/guard0. Public GetEndpoints discovery succeeded and returned7 URLs `opc.tcp://otopcua-sdk1-browser-nat-parity:50000/`. SDK family/assembly hashes and TRX retained; only that fixture was removed. Thus the different-port advertisement limitation predates SDK2. Follow-up: preserve operator-configured host and port while retaining advertised path for matching transports, using the existing driver/Shared normalization contract; add real NAT positive/negative/security/namespace tests and keep strict certificate policy unchanged. Do not mask this by silently accepting certificates or changing transport. No browser product fix is included in the mechanical SDK migration. Evidence: /tmp/opcua-browser-sdk1-nat-parity/report.md and SDK2 CI3/focused-correction receipts (to be versioned).
dohertj2 added the type:bugpriority:p2 labels 2026-11-10 15:37:07 -05:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dohertj2/lmxopcua#806