dtrace discuss - Sep 2006 - [networking-discuss] Re: DTrace Network Provider

> 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?
Could someone please spell out exactly what this provider is trying
to do? SDT probes  can provide of the above info. So why do we need
a new provider for this? As Kacheong asked, what are the guidelines
for new providers, vs usage of existing probes.
> Probes in/for ipf could possibly be a seperate follow-on project by itself.
I thought the argument being made was to only support protocol/states
defined in RFCs (rfc793 was touted as the example). So would that
not exclude ipf?

--Sowmini

G''Day Folks,

On Thu, Sep 21, 2006 at 11:25:45AM -0700, Darren.Reed at Sun.COM
wrote:
> Sowmini.Varadhan at Sun.COM wrote:
> ...
> 
> >>Probes in/for ipf could possibly be a seperate follow-on project by
> >>itself.
> >>   
> >>
> >
> >I thought the argument being made was to only support protocol/states
> >defined in RFCs (rfc793 was touted as the example). So would that
> >not exclude ipf?
Noone said "only". The RFCs provide standard terminology, events and
values,
which are appropriate to use for a public and stable provider. If we can
think of additional events which are stable and useful (ie, not private
implementation details), then they can be added.
> I believe it would...but defining a project like that might not
> deliver what people would expect and want from it.
ipf events should be available; I''d suggest the probe names be based on
the
stable keywords used in ipf.conf, such as,

   net:ipf::block
   net:ipf::pass
   net:ipf::log

etc. I imagine Darren can think of the most complete and appropriate list
of such probes. :)

cheers,

Brendan

Brendan,

A more high level question I have here is why is there a blank
field in the dtrace probes?

Given the problem with trying to access both IPv4 and IPv6
header information, is there any merit it changing the model
to be:

net:ipv4:tcp:receieve
etc

Or does this introduce a problem in inserting the probes?

This would expand the dtrace probe name set like this:
net:ipv4::receive
net:ipv4::send
net:ipv6::receive
net:ipv6::send
...which may not be attractive or serve your goal well
because you can''t as easily get both IPv4 and IPv6
received packets in this fashion.

Can we have probe-aliases?

Such that there is a single probe in the code for net:ip:tcp:receive
but that it supplies a different mapping for the args if it is given
as net:ipv4:tcp:receieve or net:ipv6:tcp:receive (probe location
is the same, however), with dtrace doing some probe demux''ing?

Somehow this also feels better...to specify both the network
protocol and transport protocol in a single dtrace probe.

Darren