- get and set driver configuration parameters
ndd [-set] driver parameter [value]
ndd gets and sets selected configuration parameters in some kernel drivers. Currently, ndd only supports the drivers that implement the TCP/IP Internet protocol family. Each driver chooses which parameters to make visible using ndd. Since these parameters are usually tightly coupled to the implementation, they are likely to change from release to release. Some parameters may be read-only.
If the -set option is omitted, ndd queries the named driver, retrieves the value associated with the specified parameter, and prints it. If the -set option is given, ndd passes value, which must be specified, down to the named driver which assigns it to the named parameter.
By convention, drivers that support ndd also support a special read-only parameter named ``?'' which can be used to list the parameters supported by the driver.
Example 1 Getting Parameters Supported By The TCP Driver
To see which parameters are supported by the TCP driver, use the following command:
example% ndd /dev/tcp \?
The parameter name ``?'' may need to be escaped with a backslash to prevent its being interpreted as a shell meta character.
The following command sets the value of the parameter ip_forwarding in the dual stack IP driver to zero. This disables IPv4 packet forwarding.
example% ndd -set /dev/ip ip_forwarding 0
Similarly, in order to disable IPv6 packet forwarding, the value of parameter ip6_forwarding
example% ndd -set /dev/ip ip6_forwarding 0
To view the current IPv4 forwarding table, use the following command:
example% ndd /dev/ip ipv4_ire_status
To view the current IPv6 forwarding table, use the following command:
example% ndd /dev/ip ipv6_ire_status
See attributes(5) for descriptions of the following attributes:
The parameters supported by each driver may change from release to release. Like programs that read /dev/kmem, user programs or shell scripts that execute ndd should be prepared for parameter names to change.
The ioctl() command that ndd uses to communicate with drivers is likely to change in a future release. User programs should avoid making dependencies on it.
The meanings of many ndd parameters make sense only if you understand how the driver is implemented.