Hey everyone, I'm the original author of this library. This is actually my first software project ever-- I'm a full-time officer in the military who was just messing around. It's extremely flattering to see this shared so publicly, but I feel the need to pre-emptively apologize to readers. This is just a hobby project for now, but I would appreciate feedback.

Keep rolling with it; there's an opportunity for someone to start a memory-safe protocol analyzer written in a higher-level language than C with a decent TUI, and have it snowball into something big. Best of luck!

Thank you for your service and your project! Looks really well done. I have always wanted to make something using the Charm ecosystem.

A question to everyone:

Can anyone explain the networking part of this a bit? I see the `gopacket` package has been used. Is it only capable of "readonly" operations like this?

I'm trying to make a cross-platform system wide URL-based blocker and was wondering if this (gopacket) could achieve that. Any good resources for studying about the same?

I've seen projects do the same for Linux with proxies.

This is really well done! I found it on /r/golang and wanted to submit it to HN because it worked so well. Thanks for making such an awesome tool.

Well done. At first glance the UI looks well organized. Will give a test drive. Thanks for putting your work out there!

tshark[0][1] has been the go-to standard for CLI packet analysis for a long time. It'd be really nice if Gosniff provided some kind of documentation on how it differentiates itself from tshark.

[0] https://tshark.dev/ [1] https://blog.wireshark.org/2014/07/to-infinity-and-beyond-ca...

Tshark is CLI, this is TUI, that seems to be big differentiator. Though tshark seems more mature

reminds me of termshark at https://github.com/gcla/termshark also written in golang

+1 on termshark. It is pretty sweet. Much simpler to use compared to tshark/tcpdump imo since it avoids most of the cli flags complexity and uses familiar Wireshark filters

Neat project.

How does it compare to Wireshark' console cousin tshark?

Once nice thing about this is that it's memory-safe, which is something you really want for a packet capture tool.

Hrm. Interesting point. There have been a fair number of parser CVEs, but GoLang isn't immune to some of the (based on an admittedly cursory look) parser issues.

A protocol analyzer implemented in anything short of formally-verified code is going to be "vulnerable" to logic errors, such that it might print (or not print) the wrong things. But a protocol analyzer implemented in C standard a decent chance of coughing up RCE.

(Playing devil's advocate): What would the RCE accomplish?

"Parse this packet and get a reverse shell on analyst's workstation?"

To be clear: I am not in any way attempting to disparage the project. It is damned cool, and as a neophyte Go practitioner myself, I very much appreciate its existance and utility. Just working through all the edge cases :)

I assume one reason for these console versions is that people run them directly on the server. Maybe sometimes even as root.

Yes, that's what it would accomplish.

My thoughts as well. Tshark supports a ton of dissectors. How does this project compare? Being in go, can it reuse the Wireshark dissectors that are written in C?

I like how each packet is broken out into layers. Would be helpful for learning about new protocols on the wire.

This, for what it's worth, is a side-effect of using gopacket, which is a deceptively powerful library. You essentially have a big chunk of `tcpdump`'s encoding available to you any time you're working with packet buffers in Go, because of that library; for instance, to debug our BPF-based UDP stuff, there's an interface that shuttles packet snapshots over perf buffers and about 30 lines of Go code to read and decode those buffers. I was surprised at how much I got "for free" just by importing gopacket.

It's great, more people should do cool stuff with it.

Looks pretty good! Some suggestions: it should support tcpdump's command line arguments and start with them as defaults. It would be neat if packets from different interfaces can be shown in different windows.

Great project, have you seen what Etherape does? It would be interesting to include a text based scaling of what's talking to your computer.