EdgeShark capture (right-click link → “EdgeShark and VNC”) fails on Podman with extcap EOF due to unresolved discovery hostname

[Dave-Mack]

Describe the bug

Using the Containerlab VS Code extension over Remote SSH on Oracle Linux 9, launching packet capture from topology link context menu:

• Right-click link
• Select EdgeShark and VNC

opens Wireshark/VNC tab, but capture fails with popup:

Error by extcap pipe: Msg=cannot decode targets from GhostWIre-on-Packetflx service: EOF

Environment

• VS Code + Remote SSH
• Extension: Containerlab VS Code extension
• Host OS: Oracle Linux 9
• Runtime: Podman
• Lab launched with containerlab/podman

What I observed

EdgeShark backend logs (edgeshark-edgeshark-1) show discovery lookup failure:

forwarding/reverse proxying to "http://gostwire.ghost-in-da-edge:5000/mobyshark"
http: proxy error: dial tcp: lookup gostwire.ghost-in-da-edge on 10.89.0.1:53: no such host
cannot update container meta data: Get "http://gostwire.ghost-in-da-edge:5000/mobyshark": dial tcp: lookup gostwire.ghost-in-da-edge ... no such host

In this Podman setup, gostwire resolves, but gostwire.ghost-in-da-edge does not.

Workaround

Redeploying edgeshark so packetflix uses:

--discovery-service=gostwire

instead of:

--discovery-service=gostwire.ghost-in-da-edge

fixes the issue and capture works.

Expected behavior

Right-click EdgeShark and VNC should work on Podman environments without manual edits.

Suggested improvement

• Add Podman-aware fallback/override for discovery host (use gostwire when FQDN fails), and/or
• expose discovery host as configurable extension setting, and/or
• improve extension error message to surface backend DNS failure rather than generic extcap EOF.

Additional context

This may stem from runtime DNS differences between Docker and Podman/compose-provider behavior. Extension users encounter it through extension workflow, so improved handling/docs here would help.