fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
<n_1-c_k>
...it shows xmit_ numbers but recv_ is always zero. Is there any hope of modifying the script to correct? Or best to try a newer version of systemtap?
sanoj has quit [Ping timeout: 260 seconds]
wielaard is now known as mjw
scox has quit [Ping timeout: 264 seconds]
mjw has quit [Quit: Leaving]
mjw has joined #systemtap
mjw has quit [Client Quit]
mjw has joined #systemtap
wcohen has quit [Ping timeout: 255 seconds]
orivej has joined #systemtap
<fche>
n_1-c_k, hi
<fche>
the netdev.receive probe point needed porting to kernels >3.14
<fche>
it's just a one-liner patch to one file; you can probably apply it to your own copy of prebuilt systemtap and go
<fche>
(this patch is in the fresh stap 3.3 release)
<n_1-c_k>
fche: that worked for me - thanks!
<fche>
great
<n_1-c_k>
I'll venture to ask a followup question... I'm looking at the results of running that 'nettop' script while I get pages from a web server running there...
<n_1-c_k>
The traffic uploaded from the server to send me the pages is shown as 'lighttpd', which is nice. But for the traffic going into the server...
<n_1-c_k>
...it's shown as belonging to 'swapper/0', which is a bit unexpected. Is there some way of having it show something about the receiving process, i.e. the web server?
<fche>
I believe at the time the packet is received, there's no way to know which process it is destined to
<n_1-c_k>
fche: ah...
orivej has quit [Ping timeout: 264 seconds]
<n_1-c_k>
My knowledge of networking is modest but I wonder whether identifying the receiving port and matching that to a socket and then to the process owning the socket would reveal the receiver? But perhaps that's getting outside the realm of what systemtap can be expected to do?
<fche>
it's possible but requires coordination of information that's not immediately available
<fche>
so stap could do that - track bind/connect ops on a per-process basis
<fche>
and match up incoming tcp/udp packets (at the device driver or firewall level) with them
<n_1-c_k>
fche: oh! Then I hope someone cleverer than me will accomplish that :)
<n_1-c_k>
I think that 'nethogs' must be doing something along those lines but it's interactive-only, it can't save to a log file (I think). I looked at its source code but struggle to make any sense of it.
<fche>
aha
<fche>
heh, it does it by scanning /proc/*/fd/* to find out what all the processes' filedescriptors are
<n_1-c_k>
Yes, and that finds their sockets I think? Then it matches those to connections... somehow.. and uses libpcap for traffic.. somehow. I think.
<fche>
very processing-heavy, but works
<n_1-c_k>
fche, thanks for your help and comments.
<fche>
np
wcohen has joined #systemtap
scox has joined #systemtap
brolley has joined #systemtap
gromero has joined #systemtap
orivej has joined #systemtap
sanoj has joined #systemtap
pwithnall has quit [Quit: pwithnall]
slowfranklin has quit [Quit: slowfranklin]
sanoj has quit [Ping timeout: 240 seconds]
slowfranklin has joined #systemtap
n_1-c_k has quit [Read error: Connection reset by peer]