Comment by sophacles

3 days ago

It's a pretty cool looking product. It's not wireshark, it's not close to wireshark just because it can capture some tcp pcaps, and there are more protocols relevant to container networking than a handful of TCP app-level protocols.

When I came in I was hoping to see a product that actually was for container networking, not just app data flows. Again - this is a neat tool, and probably incredibly useful for people developing way up the stack like that, but a lot of us live below the bottom of a "full-stack developer's" stack. Some features I would expect in a "wireshark for Docker containers":

* Ability to inspect DNS traffic

* Ability to trace packets the enter the conainter network stack (e.g. the packet(s) generated when the server calls send() ) into the virtual interface for the namespace and through the host machine. Ideally with multiple observation points and correlation of packets in the overlay/underlay contexts (decrypting from local keys whenever possible).

* Ability to see where a packet dies between the app and exit NIC on the host. Including things like "packets delivered to this container even though the dest IP/subnet isn't in this container"

* Similar to the previous point: ability to track packets through all the NAT steps containers introduce.

* See arp traffic on virtual interfaces.

* Ability to observe the TLS handshake and gather all the parameters of the connection.

* Packet dissection and protocol session tracing for all the tunnels.

* Bonus points if you can capture weird teleports caused by ebpf programs in the network path.

I expect this because that's how I use wireshark_+ bpftrace in container environments for the most part. I've also used it to debug while implementing protocols, but that's a less common use case of packet dissection and tracing in wireshark.

What you've built is cool, and I can see it expanding in a lot of directions very, very, usefully. I just really dislike something calling itself a wireshark while not really helping with networking (and in fact - the networking has to work reasonably well for this tool to be effective).

That's totally fair, I can see why Wireshark wouldn't be the most accurate description to someone working on those kinds of problems. And fwiw, I wish my problems (before Subtrace) were cool enough to need to whip out Wireshark for packet-level inspection :)