Ethernet netgraph node type
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 interface in the system. Each node will attempt to name itself with
the same name as the associated interface.
Three hooks are supported: lower
. 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.
hook is a connection to the raw
Ethernet device. When connected, all incoming packets are forwarded 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
hook is a connection to the upper
protocol layers. When connected, all outgoing packets are forwarded to this
hook, instead of being transmitted by the device. Writing to this hook results
in a raw Ethernet frame being received by the kernel just as if it had come in
over the wire. Normal incoming packets are not affected by
hook is equivalent to
, except that only unrecognized packets
(that would otherwise be discarded) are written to the hook, while other
normal incoming traffic is unaffected. Unrecognized packets written to
will be forwarded back out to
In all cases, frames are raw Ethernet frames with the standard 14 byte Ethernet
header (but no checksum).
When no hooks are connected, upper
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 layers.
- Like lower, but only receives
This node type supports the generic control messages, plus the following:
- Returns the name of the associated interface as a
NUL-terminated ASCII string. Normally
this is the same as the name of the node.
- Returns the global index of the associated interface as a 32 bit
- 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
- 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 always 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
- 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
- Leave Ethernet multicast group. This control message is equivalent to
- Detach from underlying Ethernet interface and shut down node.
Upon receipt of the
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
” interface to standard output
decoded in hex and ASCII:
nghook -a fxp0: orphans
This command sends the contents of sample.pkt
out the interface “
cat sample.pkt | nghook fxp0:
These commands insert an
node between the lower
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
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
nodes into existence.