gorkem-bwl
9ffcbd1242
The network tab warns when Capture can only see a container's own network namespace, but the condition required EVERY reported interface to be named lo, lo0 or docker0. A containerised Capture usually also reports the container's veth under a host-looking name (eth0, ens3, ...), so the common case failed that test and the notice never appeared - leaving those users with plausible-but-meaningless traffic and nothing explaining why. Widening it to "any container-only name present" would have been wrong in the other direction: a host-level Capture on a machine running Docker legitimately reports docker0 alongside its real NIC, and would then have been warned incorrectly. Interface names alone cannot separate the two cases. What does is that in the container case nothing carries real traffic, while a genuine host has a busy NIC. The notice now fires when a container-only interface is present AND every interface is idle, using a 1 KB/s threshold - real NICs sit orders of magnitude above it, a container's veth sits at or near zero. Checked against six scenarios: the reported case (lo + ens3 + docker0, all near zero) now warns; a host with a busy NIC plus an idle docker0 does not; a fully namespaced container still warns as before; and a quiet host with no container-only names stays silent. The notice text is updated to match, since it previously described only the all-container-names case and did not explain that a host-looking interface can be the container's own. Claude-Session: https://claude.ai/code/session_01AbYLvwpEaZFXktHVcqrFRd
This directory contains the client side (frontend) of Checkmate.