e2e: an unknown LB announcer node turns the dataplane CNI-pod lookup into a match for unscheduled pods #3654

Summary

In hack/e2e-capture-dataplane.sh, the LB tcpdump leg looks up the announcer node's CNI pod as _an_cni=$(pod_on_node "$KUBEOVN_NS" app=kube-ovn-cni "${_annode:-}") (line 706 at 605030b) with no emptiness guard on _annode. pod_on_node builds --field-selector "spec.nodeName=$3", and with an empty third argument that selector is spec.nodeName=, which matches pods whose nodeName is EMPTY, that is, unscheduled/Pending pods. So an unknown announcer does not yield "no pod found"; it yields the first pending kube-ovn-cni pod in the namespace, if any, and the subsequent kubectl exec ... tcpdump targets a pod that is not on the announcer node and may not be running at all.

The sibling uses of _annode in the same function are all guarded ([ -n "$_annode" ] before capture_lb_node, ${_annode:-$_epnode} for the probe node); this one call slipped through unguarded.

Why it matters

The announcer is unknown exactly when MetalLB is misbehaving, which is when this capture leg matters. In that state the artifact either shows a tcpdump from an unrelated pending pod labelled as the announcer capture, or a confusing exec failure, both of which point the reader away from the actual problem.

Fix shape

Guard the lookup the same way its siblings are guarded: skip the announcer tcpdump leg with an explicit "announcer unknown" line when _annode is empty. One [ -n "$_annode" ] around the block, matching the pattern four lines above.