Hey @llchan, thanks for the suggestion. I must admit I'm a little weary of adding stuff like this. I feel these sorts of features are something that could be implemented "on top" of bandwhich. Either requiring it as a library or using raw_mode.

If you're looking for something to work on, I'd be happy to suggest some issues that need work, or maybe come up with something together?

Totally understand. Feel free to stick a help-wanted label on this and leave it for the community to add. I was mostly filing an issue for visibility before tinkering.

I'll look into the raw mode or library mode, but given that you've already set up the TUI bits I'd prefer to add it in there rather than starting a new project. Just thinking out loud here, but maybe if you want to set different maintenance expectations for the bandwhich core library and the bandwhich TUI/CLI app, you could consider splitting it into two packages, with a more community-supported workflow for the app layer?

@imsnif It would be good to see process id (PID) in the table.

And for some processes it shows <UNKNOWN> for the process name

Alright - I'd be open to adding the PID to the process table as a separate column.
Note that we'd have to take care to have it react to size changes like the rest of the table does. It would probably be the first thing to go before the "Connections" column.

I'm putting a "Help Wanted" on this, but if one of you wants to implement it, let me know and I'll remove it.

@imsnif @llchan I'm going to investigate this issue. It could be a good job.

And for some processes it shows <UNKNOWN> for the process name

Is this likely to be fixed as part of this issue or would you like a separate issue for this?
I wasn't clear if this was something to do with "DNS queries hidden" or not.

Hey @hulleyrob - I think in cases where we see <UNKNOWN> we won't see a PID either. <UNKNOWN> means bandwhich could not figure out which process certain traffic belongs to for various reasons.