Question: what are steps that can be taken to figure out what an <UNKNOWN> could be?

[herbygillot]

First off, thank you for bandwhich.

I'm seeing an <UNKNOWN> in my process list and would like to know some ways that could be used to figure out what it could possibly be.

[imsnif]

Hey - So an <UNKNOWN> happens when bandwhich records traffic that has no matching process.
This can happen for several reasons (that I know of):

1. Some traffic arrived at your machine, intended for an already-closed process.
2. Some packets were sent to your machine with no intended process (unlikely to happen, but possible)
3. The owning process was very short-lived and we did not query the system's process list (/proc or lsof, depending on your platform) in time.
4. For some reason the process does not appear in the process list

I will say that sometimes bandwhich detects its own DNS queries as unknown traffic (because of reason 3). So that might be what you are seeing. You can try running it with the --no-resolve flag and seeing if it still happens.

[herbygillot]

Thank you, much appreciated. I'm still seeing UNKNOWNs even after --no-resolve (this is on MacOS), but what you've mentioned makes sense.

[imsnif]

Sure. Let me know if there's anything else I can help with. :)

[boggle]

Same experience. Would it make sense to have a command line argument for changing the polling frequency?

[boggle]

Is there any other way for doing this than polling using lsof? How do all the firewall products for os x do this kind-of thing?

[imsnif]

Same experience. Would it make sense to have a command line argument for changing the polling frequency?

Hmm - I'm not sure. When polling, this always has the potential of being a problem, even with a very high polling frequency. So I'm a little hesitant to add lots of complexity in the app to handle this case...

Is there any other way for doing this than polling using lsof? How do all the firewall products for os x do this kind-of thing?

I think the only category-of-a-way around this would be to register to some sort of event that would be fired whenever a process binds itself to a port or releases the port. That way we will never have the discrepancy between the time of polling and the time we logged the packet.

Admittedly, I've never looked too deeply into this, because I found that the UNKNOWNs are pretty rare all in all. From what I have seen and heard, this is very much an edge case.

That being said, if someone were to investigate this and find a way that would not harm performance, I'd be very interested in discussing an implementation of it.

[Joshfindit]

Would it be possible to list bandwhich's DNS resolution in the process list?

[imsnif]

Not trivially, I'm afraid. When I want to rule it out, I use the -n flag, and then it doesn't talk to the DNS server at all.

[Joshfindit]

What if it spawned a separate process that just handled bandwich’s network requests?

[grahamperrin]

lsof(8) and OpenZFS

Cross reference https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251510#c3

From https://lists.freebsd.org/pipermail/freebsd-current/2020-November/077701.html:

Please be wary of lsof. I'm not sure it works on OpenZFS. The port reaches into /usr/src for zfs headers in locations that don't exist anymore to access kernel memory in /dev/kmem using structs that are different in OpenZFS. It is likely not building the ZFS support code on 13-current, and it is not expected to work on 12 with openzfs from ports, either.

– freqlabs (Ryan Moeller)