The udp provider provides probes for tracing the UDP protocol.
This provider integrated into Solaris Nevada build 142.
The udp probes are described in the table below.
|send||Probe that fires whenever UDP sends a datagram.|
|receive||Probe that fires whenever UDP receives a datagram.|
The send and receive probes trace datagrams on physical interfaces and also packets on loopback interfaces that are processed by udp.
The argument types for the udp probes are listed in the table below. The arguments are described in the following section.
|send||pktinfo_t *||csinfo_t *||ipinfo_t *||udpsinfo_t *||udpinfo_t *|
|receive||pktinfo_t *||csinfo_t *||ipinfo_t *||udpsinfo_t *||udpinfo_t *|
The pktinfo_t structure is where packet ID info can be made available for deeper analysis if packet IDs become supported by the kernel in the future.
The pkt_addr member is currently always NULL.
The csinfo_t structure is where connection state info is made available. It contains a unique (system-wide) connection ID, and the process ID and zone ID associated with the connection.
|cs_addr||Address of translated ip_xmit_attr_t *.|
|cs_cid||Connection id. A unique per-connection identifier which identifies the connection during its lifetime.|
|cs_pid||Process ID associated with the connection.|
|cs_zoneid||Zone ID associated with the connection.|
The ipinfo_t structure contains common IP info for both IPv4 and IPv6.
These values are read at the time the probe fired in UDP, and so ip_plength is the expected IP payload length - however the IP layer may add headers (such as AH and ESP) which will increase the actual payload length. To examine this, also trace packets using the ip provider.
|ip_ver||IP version number. Currently either 4 or 6.|
|ip_plength||Payload length in bytes. This is the length of the packet at the time of tracing, excluding the IP header.|
|ip_saddr||Source IP address, as a string. For IPv4 this is a dotted decimal quad, IPv6 follows RFC-1884 convention 2 with lower case hexadecimal digits.|
|ip_daddr||Destination IP address, as a string. For IPv4 this is a dotted decimal quad, IPv6 follows RFC-1884 convention 2 with lower case hexadecimal digits.|
The udpsinfo_t structure contains udp state info.
|udps_addr||Address of translated udp_t *.|
|udps_lport||local port associated with the UDP connection.|
|udps_fport||remote port associated with the UDP connection.|
|udps_laddr||local address associated with the UDP connection, as a string|
|udps_fport||remote address associated with the UDP connection, as a string|
The udpinfo_t structure is a DTrace translated version of the UDP header.
|udp_sport||UDP source port.|
|udp_dport||UDP destination port.|
|udp_length||Payload length in bytes.|
|udp_checksum||Checksum of UDP header and payload.|
|udp_hdr||Pointer to raw UDP header at time of tracing.|
See RFC-768 for a detailed explanation of the standard UDP header fields and flags.
Some simple examples of udp provider usage follow.
This DTrace one-liner counts UDP received packets by host address:
The output above shows that 7 UDP packets were recieved from 127.0.0.1, 14 UDP packets from the IPv6 host fe80::214:4fff:fe8d:59aa, etc.
This DTrace one-liner counts UDP received packets by the local UDP port:
The output above shows that 1 packet was received for port 33294, 1 packet was received for port 33822, etc.
This DTrace one-liner prints distribution plots of IP payload size by destination, for UDP sends:
The udp provider uses DTrace's stability mechanism to describe its stabilities, as shown in the following table. For more information about the stability mechanism, see Chapter 39, Stability.
|Element||Name stability||Data stability||Dependency class|