Brendan,
Brendan Gregg - Sun Microsystems wrote:
G'Day Darren,
You do know that Australians reserve that greeting for use
only with foreigners, don't you ? ;)
On Mon, Sep 25, 2006 at 04:00:02PM -0700, [EMAIL PROTECTED] wrote:
Brendan Gregg - Sun Microsystems wrote:
[...]
What I'd like to see dtrace be able to do is follow a packet through
the kernel, not a thread of execution. fbt is for following execution.
sdt is up to how it is used, but most often, it is just random hooks
in the code.
The difference between using fbt and being able to follow a packet
is when a packet is put on a queue, the fbt path is terminated,
even though the packet still has places to go and I/O ports to see.
If the networking dtrace provider doesn't deliver the capability
to trace a packet through the kernel then it is not delivering a
key feature that is needed by many people.
Noone is saying that the provider will never do this. If you are saying
that this feature is important to you, then sure - I understand.
And if many people means many engineers (which in turn helps them
achieve cool things), then I understand that too.
Can you comment on what the provider is being designed to do,
if it won't allow for following a packet through the kernel?
If I look at the design presented on the web page, it tells us
what probes will be implemented and some ways in which they can
be used. What appears to be missing is a statement of "this is
what we're trying to achieve", from a more loftly level.
Are you just trying to provide stable names for interesting
places to observe information inside IP or something else?
Whatever the goal, it might be would worth mentioning it.
...
To have a single DTrace script check for all types of scans and give
a report will still have some value. A customer finds unexplained
network utilization, and can run a quick script to check what it is -
rather than install a NIDS if one isn't available.
If they're trying to diagnose unexplained network utilization then
they should not be using dtrace - it isn't the right tool for this
job. Put a network sniffer on there or use tcpdump or ethereal or
similar.
How will dtrace tell me that someone has installed a backdoor'd
version of some PHP module that runs an IRC bot connecting to
some chat server on the 'net?
If dtrace were the right tool to use, how would you use it to
find the answer to that question or to even discover this issue
was present?
Some other probes that might be useful:
- RTT calculations from TCP timestamp measurements
- TCP window size changes
These could be scripted from tcp::send and tcp::receive alone; but
seperate probes may make sense.
That's not what I'm getting at. TCP makes internal calculations
about what the averge RTT to its peer is. Using ::send and
::receieve will lead to independant calculations being made that
do not necessarily reflect what TCP thinks.
While the window size can be observed from ::receive, it isn't
the size I want to know about, it's when it changes so I can
hopefully see what the old value is and what the new one is.
- when a packet is dropped because it is "bad" (checksum, etc)
Yep - we need a tcp::drop-checksum or some such.
Or maybe:
ip:::drop, tcp:::drop, etc, and make an arg the type of drop?
- look through "netstat -s" output as there is quite a large
number of stats there that are worthy of being identified
with a probe.
Sure. So long as we really do want to probe it, and that the kstat
value isn't sufficient. Thinking of sample scripts that use them should
help here.
It's not the kstat value that's important, it's being able to see
what the packet looked like that when the kernel decided to ldrop it.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
