Richard Lowe wrote:
[Cc'ing networking-discuss, I suspect followups should go to
dtrace-discuss, however]
Brendan Gregg - Sun Microsystems wrote:
G'Day Folks,
I've just created a website to flesh out ideas for a DTrace Network
Provider.
Let us know what you think.
http://www.opensolaris.org/os/community/dtrace/NetworkProvider/
I'm not currently writing this provider; this began as a discussion with
Adam about what a network provider could do, which we thought would be
appropriate to discuss on dtrace-discuss. So, this may not actually
happen;
although it would help if a lot of people really do want it. :-)
+1, I for one certainly want it :)
Agreed! :)
Some work needs to happen on args[2] - it is completely IPv4 specific.
There is no mention of IPv6 header fields such as flow.
For IPv4, it would be good if it were possible to look at IP header
options, or for IPv6, extension headers. Same again for TCP and its
options (timestamp, MSS, SACK, etc.)
e.g. What can be done with dtrace to get information about the AH
header as well as the TCP header in an IPv4 or IPv6 packet?
Or in TX, how would you access CIPSO information?
Couldn't we also do with some ICMP probes?
And can we mark ICMP packets in such a way with dtrace that we
can measure the time it takes from gld::receive to gld::send for
an ICMP ECHO to be received, processed and then send out again ?
A couple of questions.
What are the intents regarding ICMP, SCTP etc?
What are the semantics of these where ipf is involved? I assume that
a packet blocked by ipf will not fire the probes, for obvious reasons.
Would ipf gain probes for packets being dropped/being nat'd, etc?
Probes in/for ipf could possibly be a seperate follow-on project by itself.
Darren
_______________________________________________
networking-discuss mailing list
[email protected]
