Add information to associate packets with processes

[prakharPant]

I have modified the wireshark code to include the process information for the packets that it captures.

I want to add this issue to suggest support for capturing process information through pcapng.

https://gitlab.com/wireshark/wireshark/-/merge_requests/17737

Currently I have modified the pcapng and pcapio code. In my merge request. (Linked above)

I still have a lot of work to do but if you could guide me on whether this is the right way to approach the issue then that would be very helpful.

I've created struct process info -

struct process_info { u32 pid; // Current process ID u32 ppid; // Parent process ID __u32 gpid; // Grandparent process ID char comm[TASK_COMM_LEN]; // Command name of the process char p_comm[TASK_COMM_LEN]; // Command name of the parent process char gp_comm[TASK_COMM_LEN]; // Command name of the grandparent process };

I am passing the struct from dumpcap in wireshark and have modified the pcapng_write_enhanced_packet_block to include the struct.

Further I add the option for the struct and pass it off along with the enhanced packet block.

Then parse the option in pcapng and store it against the modified wtap_rec struct that includes the process_info struct.

How should I go about getting this implemented?

Thanks

[guyharris]

By the way, if more than one process has a file descriptor/Windows HANDLE/whatever for a given socket, all of those processes should be associated with a packet that arrives on the socket - network packets aren't sent to processes, they're sent to endpoints.

[prakharPant]

Do you mean through fork(). So we should have a linked list till as long as we can find parent processes pids? Unrelated processes can't have the same fd, right?

Yeah I agree. The idea of associating all the processes, instead of just 3, with the packet sounds really good to me, maybe in the form of a linked list with a parent parameter that links to another process (if applicable) and so on.

[guyharris]

Do you mean through fork().

On UN*Xes, that's the main way by which more than one process can share a file descriptor such as a descriptor for a socket. On some UN*Xes, a file descriptor can also be passed to another process over a UNIX-domain socket, and there's a call in Windows that can be used to pass a HANDLE to another process.

So we should have a linked list till as long as we can find parent processes pids?

If a program or library is keeping track of which sockets belong to which processes, each socket would need some aggregate data structure holding a collection of processes, yes.

Unrelated processes can't have the same fd, right?

As noted above, yes, they can, both on some UN*Xes. On Windows, the same may be the case, with HANDLE rather than FD; at least on NT, I'm guessing that, below Winsock, there's a HANDLE for every socket, but that could be wrong.

(Also, OSes other than UN*Xes and Windows could produce pcapng files, or even just have rpcap servers to provide a sequence of packets, so changes to pcapng for this should at least try to allow using it with various non-UN*X, mainframe OSes, IBM i, OpenVMS, and various Internet of Things OSes, for example. That may just mean using a pcapng block of some sort to contain information about a process, with information about the process recorded as options, so that various bits of information can be recorded if, and only if, it can be obtained about the process for that OS.)

[kayoub5]

The processes could be unrelated, this is allowed using the SO_REUSEPORT socket option.

see https://stackoverflow.com/a/68837302/1438522

[prakharPant]

Yeah unrelated processes can share the same fd. My merge request is such that it only associates the processes that called the tcp/udp send/recv msg kernel function on linux.

i.e. it associates the packet to the process that sent the packet and it's parent and grandparent and not another one that may share the same file handle / socket.

However a process could spawn a child which could then detach from the process by changing it's process group and then send and receive packets on the original process' behalf, which would then not be recorded.

Although I think it may be rare. Still we should associate all processes to the packet that was sent through a socket.