[EMAIL PROTECTED] wrote:
> 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.
Seconded!
for example, there is a class of problems that falls under the
following description (from Nicolas Williams)
> The thing that makes it easy to thread function calls/returns is that
> they all happen in the same thread of execution and in sequence. The
> same is not necessarily true of "packets." There's multicast, and
> SOCK_RAW, fragmentation, etc... Also, do you want to trace flows all
> the way from the link layer through applications (e.g., NFS, Apache)?
> That seems even more daunting.
>
> How do you thread receipt of fragmented packets into a nice call flow-
> style of report?
but I think the previous discussions have determined that this
is not currently in the scope of the current provider, and dtrace
scripts that need to solve the above must use associative arrays
or other existing means.
This is a reasonable scope-definition to make, but then the
network-savviness of an audience that seeks to do the following is unclear:
> ip:::send
> /args[2]->ip_ver == 4/
> {
> args[2] contains valid IPv4 members, straight from the IPv4 header
> }
>
> ip:::send
> /args[2]->ip_ver == 6/
> {
> args[2] contains valid IPv6 members, straight from the IPv6 header
> }
System Administrators are probably more accustomed to well-known
tools like ethereal/snoop/tcpdump that allows them to filter above
info out from the wire. Are we trying to find out if/why the packet
got all the way to ip's send routine, but didn't make it out to the wire?
IOW info like the following:
> 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.
i.e., we want to get ancillary information from "well-known"
points in the stack (where "well-known" is some commonly accepted
rfc/state-machine/whatever), then perhaps it makes more sense to first
enhance the existing mib provider to provide the pertinent
ancillary information (SNMP MIBs already have the charter of
portability, interoperability etc. that are needed for stability)?
--Sowmini
_______________________________________________
networking-discuss mailing list
[email protected]
