On 05/25/2014 08:21 PM, Masatake YAMATO wrote:
Hi,
I'd like to get your comment about my idea and patches.
Consider you are watching the window of wireshark, and find
storage packet goes out. You may want to identify the process
and its fd where the packet comes.
If the packet is of tcp segment, it is easy to identify the process
and fd. How about raw socket or un-bind udp socket? If we can use
crash of systemtap, we can identify it. However, I think it is nice
if we can identify with packet capture tools.
My initial idea is putting the pid of sender process to socket buffer.
So packet capture tools can know the sender process of each packet.
However, this is meaningless because tcp protocol handler may split
data into multiple socket buffers or join socket buffers into one
socket buffers. Association between process and socket buffers can
be rearranged.
After rethinking I found I can use inode number of socket for my
purpose. See the attachment
0001-packet-add-socket-inode-number-to-packet-capture-dat.patch.
Combining lsof, we can identify the process and fd.
How do you think the background and idea?
Interesting.
Some time ago I had a _slightly_ related idea that can be found in [1]
with follow-up of [2]. It's basically a combination of cgroups with
netfilter, which opens up quite some possibilities. E.g. skbs from
applications put into particular cgroups, passing NF_INET_LOCAL_{IN,OUT}
and NF_INET_POST_ROUTING, could be mangled to set a skb mark, which
could then be filtered for by AF_PACKET via BPF. That would relate
to a workflow if you're looking for something specific, e.g. what
kind of traffic is radiated from applications.
If the header area of af_packet is large enough. I will submit this
patch directly to netdev list. However, it is very limited: only 8
bytes are available. To embed the inode number all 8 bytes are needed.
So I decide to ask the comment here.
So inode number itself would be of not much use for pcap files itself,
as the lifetime of a socket most likely already ended when you read
the file again for analysis or read it on a different system [or you
would need to store a sufficiently long string for the application
name in each pcap packet header], so rather while capturing on a live
system so that tools can directly show the application name on the
live traffic.
On the other hand, /proc/net/packet will show you all current users of
packet sockets, but in case of raw TX not the particular traffic to the
application itself. Filling the whole 8 byte somewhat sucks, right,
as the next one who comes along would need to create a new TPACKET
version only for further extending meta data, whereas the AF_PACKET
API carries already ugly legacy with previous TPACKET versions with
it. Perhaps to carry the sk_classid matching idea further, you could
perhaps use that instead (4 bytes), so that also raw TX sockets could
be directly identified to the cgroup an application belongs to and
normal applications would not need to be passed to netfilter for
setting its mark, but I understand that inode might be more generic
and consistent with what proc already exports.
0001-Print-inode-number.patch is for netsniff-ng side. This is not
tested. I also wonder what I should do in user land tool. First I
look at libpcap. It seems difficult to pass the extra data like inode
numer to the library clients iav libpcap API.
Yes, libpcap seems to be platform independent, so that means all other
OSes do not pass that along, therefore, chances are very slim to get
that included into some API I guess.
Any suggestions and comments are welcome.
Thanks in advance.
Masatake YAMATO
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/netfilter/xt_cgroup.c?id=82a37132f300ea53bdcd812917af5a6329ec80c3
[2]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/netfilter/xt_cgroup.c?id=a00e76349f3564bb8129fc0510dfd93248c3084d
--
You received this message because you are subscribed to the Google Groups
"netsniff-ng" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
