svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
ng_ether(4)
The netgraph node type allows Ethernet interfaces to interact
with the networking subsystem. Once the module is loaded into
the kernel, a node is automatically created for each Ethernet in‐
terface in the system. Each node will attempt to name itself
with the same name as the associated interface. Three hooks are
supported: and The hook name may be used as an alias for and is
provided for backward compatibility. In reality, the two names
represent the same hook. The hook is a connection to the raw
Ethernet device. When connected, all incoming packets are for‐
warded to this hook, instead of being passed to the kernel for
upper layer processing. Writing to this hook results in a raw
Ethernet frame being transmitted by the device. Normal outgoing
packets are not affected by being connected. The hook is a con‐
nection to the upper protocol layers. When connected, all outgo‐
ing packets are forwarded to this hook, instead of being trans‐
mitted by the device. Writing to this hook results in a raw Eth‐
ernet frame being received by the kernel just as if it had come
in over the wire. Normal incoming packets are not affected by
being connected. The hook is equivalent to except that only un‐
recognized packets (that would otherwise be discarded) are writ‐
ten to the hook, while other normal incoming traffic is unaf‐
fected. Unrecognized packets written to will be forwarded back
out to if connected. In all cases, frames are raw Ethernet
frames with the standard 14 byte Ethernet header (but no check‐
sum). When no hooks are connected, and are in effect connected
together, so that packets flow normally upwards and downwards.
This node type supports the following hooks: Connection to the
lower device link layer. Connection to the upper protocol lay‐
ers. Like but only receives unrecognized packets. This node
type supports the generic control messages, plus the following:
Returns the name of the associated interface as a string. Nor‐
mally this is the same as the name of the node. Returns the
global index of the associated interface as a 32 bit integer.
Returns the device's unique six byte Ethernet address. Sets the
device's unique six byte Ethernet address. This control message
is equivalent to using the system call. Enable or disable
promiscuous mode. This message includes a single 32 bit integer
flag that enables or disables promiscuous mode on the interface.
Any non-zero value enables promiscuous mode. Get the current
value of the node's promiscuous flag. The returned value is al‐
ways either one or zero. Note that this flag reflects the node's
own promiscuous setting and does not necessarily reflect the
promiscuous state of the actual interface, which can be affected
by other means (e.g., Sets the automatic source address override
flag. This message includes a single 32 bit integer flag that
causes all outgoing packets to have their source Ethernet address
field overwritten with the device's unique Ethernet address. If
this flag is set to zero, the source address in outgoing packets
is not modified. The default setting for this flag is disabled.
Get the current value of the node's source address override flag.
The returned value is always either one or zero. Join Ethernet
multicast group. This control message is equivalent to using the
system call. Leave Ethernet multicast group. This control mes‐
sage is equivalent to using the system call. Detach from under‐
lying Ethernet interface and shut down node. Upon receipt of the
control message, all hooks are disconnected, promiscuous mode is
disabled, but the node is not removed. Node can be shut down
only using control message. If the interface itself is detached
(e.g., because of PC Card removal), the node disappears as well.
This command dumps all unrecognized packets received by the in‐
terface to standard output decoded in hex and This command sends
the contents of out the interface These commands insert an node
between the and protocol layers, which can be used for tracing
packet flow, statistics, etc.: ngctl mkpeer fxp0: tee lower right
ngctl connect fxp0: lower upper left The automatic KLD module
loading mechanism that works for most other Netgraph node types
does not work for the node type, because nodes are not created on
demand; instead, they are created when Ethernet interfaces are
attached or when the KLD is first loaded. Therefore, if the KLD
is not statically compiled into the kernel, it is necessary to
load the KLD manually in order to bring the nodes into existence.