ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
if_addmulti, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
if_allmulti, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
if_alloc, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
if_attach, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
if_data, ifnet, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
if_delmulti, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
IF_DEQUEUE, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
if_detach, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
if_down, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
if_findmulti, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
if_free, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
if_free_type, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
if_up, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
ifa_free, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
ifa_ifwithaddr, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
ifa_ifwithdstaddr, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
ifa_ifwithnet, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
ifa_ref, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
ifaddr, ifnet, if_data, ifqueue(9) | kernel interfaces for manipulating network interfaces |
ifaddr_byindex, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
ifaof_ifpforaddr, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
ifioctl, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
ifpromisc, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
ifqueue, ifnet, if_data, ifaddr(9) | kernel interfaces for manipulating network interfaces |
ifunit, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
ifunit_ref, ifnet, if_data, ifaddr, ifqueue(9) | kernel interfaces for manipulating network interfaces |
IFNET(9) | MidnightBSD Kernel Developer's Manual | IFNET(9) |
ifnet
, ifaddr
,
ifqueue
, if_data
—
kernel interfaces for manipulating network
interfaces
#include
<sys/param.h>
#include <sys/time.h>
#include <sys/socket.h>
#include <net/if.h>
#include <net/if_var.h>
#include <net/if_types.h>
struct ifnet *
if_alloc
(u_char
type);
void
if_attach
(struct
ifnet *ifp);
void
if_detach
(struct
ifnet *ifp);
void
if_free
(struct
ifnet *ifp);
void
if_free_type
(struct
ifnet *ifp, u_char
type);
void
if_down
(struct
ifnet *ifp);
int
ifioctl
(struct
socket *so, u_long
cmd, caddr_t data,
struct thread *td);
int
ifpromisc
(struct
ifnet *ifp, int
pswitch);
int
if_allmulti
(struct
ifnet *ifp, int
amswitch);
struct ifnet *
ifunit
(const
char *name);
struct ifnet *
ifunit_ref
(const
char *name);
void
if_up
(struct
ifnet *ifp);
struct ifaddr *
ifaddr_byindex
(u_short
idx);
struct ifaddr *
ifa_ifwithaddr
(struct
sockaddr *addr);
struct ifaddr *
ifa_ifwithdstaddr
(struct
sockaddr *addr, int
fib);
struct ifaddr *
ifa_ifwithnet
(struct
sockaddr *addr, int
ignore_ptp, int
fib);
struct ifaddr *
ifaof_ifpforaddr
(struct
sockaddr *addr, struct
ifnet *ifp);
void
ifa_ref
(struct
ifaddr *ifa);
void
ifa_free
(struct
ifaddr *ifa);
int
if_addmulti
(struct
ifnet *ifp, struct
sockaddr *sa, struct
ifmultiaddr **ifmap);
int
if_delmulti
(struct
ifnet *ifp, struct
sockaddr *sa);
struct ifmultiaddr *
if_findmulti
(struct
ifnet *ifp, struct
sockaddr *sa);
IF_DEQUEUE
(struct
ifqueue *ifq, struct mbuf
*m);
void
(*if_input)
(struct
ifnet *ifp, struct mbuf
*m);
int
(*if_output)
(struct ifnet *ifp,
struct mbuf *m, const struct sockaddr
*dst, struct route *ro);
void
(*if_start)
(struct
ifnet *ifp);
int
(*if_transmit)
(struct
ifnet *ifp, struct mbuf
*m);
void
(*if_qflush)
(struct
ifnet *ifp);
int
(*if_ioctl)
(struct
ifnet *ifp, u_long
cmd, caddr_t
data);
void
(*if_init)
(void
*if_softc);
int
(*if_resolvemulti)
(struct ifnet
*ifp, struct sockaddr **retsa,
struct sockaddr *addr);
void
(*ifa_rtrequest)
(int cmd,
struct rtentry *rt, struct rt_addrinfo
*info);
extern struct ifnethead ifnet;
extern int if_index;
extern int ifqmaxlen;
The kernel mechanisms for handling network interfaces reside
primarily in the ifnet, if_data,
ifaddr, and ifmultiaddr
structures in <net/if.h>
and
<net/if_var.h>
and the
functions named above and defined in /sys/net/if.c.
Those interfaces which are intended to be used by user programs are defined
in <net/if.h>
; these include
the interface flags, the if_data structure, and the
structures defining the appearance of interface-related messages on the
route(4) routing socket
and in sysctl(3). The
header file <net/if_var.h>
defines the kernel-internal interfaces, including the
ifnet, ifaddr, and
ifmultiaddr structures and the functions which
manipulate them. (A few user programs will need
<net/if_var.h>
because it is
the prerequisite of some other header file like
<netinet/if_ether.h>
. Most
references to those two files in particular can be replaced by
<net/ethernet.h>
.)
The system keeps a linked list of interfaces
using the TAILQ
macros defined in
queue(3); this list is
headed by a struct ifnethead called
ifnet. The elements of this list are of type
struct ifnet, and most kernel routines which
manipulate interface as such accept or return pointers to these structures.
Each interface structure contains an if_data structure
used for statistics and information. Each interface also has a
TAILQ
of interface addresses, described by
ifaddr structures. An AF_LINK
address (see
link_addr(3))
describing the link layer implemented by the interface (if any) is accessed
by the
ifaddr_byindex
()
function or if_addr structure. (Some trivial
interfaces do not provide any link layer addresses; this structure, while
still present, serves only to identify the interface name and index.)
Finally, those interfaces supporting reception of multicast
datagrams have a TAILQ
of multicast group
memberships, described by ifmultiaddr structures.
These memberships are reference-counted.
Interfaces are also associated with an output queue, defined as a struct ifqueue; this structure is used to hold packets while the interface is in the process of sending another.
The fields of struct ifnet are as follows:
if_alloc
().)if_attach
().)if_attach
().)TAILQ_ENTRY
(ifnet))
queue(3) macro
glue.fxp0
” or
“lo0
”). (Initialized by driver
(usually via
if_initname
()).)if_initname
()).)IF_DUNIT_NONE
if a unit number is not associated
with the device. (Initialized by driver (usually via
if_initname
()).)if_alloc
().)TAILQ
containing the list of addresses assigned to
this interface.IFF_PROMISC
flag.if_ioctl
()
routine.)bpf_attach
().)if_alloc
().)if_ioctl
()
routine.)TAILQ
containing the list of multicast addresses
assigned to this interface.IFF_ALLMULTI
flag.if_alloc
().)if_ioctl
()
routine.)if_alloc
().)LIST_ENTRY
(ifnet))
queue(3) macro glue for
the list of clonable network interfaces.TAILQ_HEAD
(,
ifg_list)) The head of the
queue(3)
TAILQ
containing the list of groups per
interface.if_alloc
(), but unlike
if_type, it would not be changed by drivers.References to ifnet structures
are gained by calling the
if_ref
()
function and released by calling the
if_rele
()
function. They are used to allow kernel code walking global interface lists
to release the ifnet lock yet keep the
ifnet structure stable.
There are in addition a number of function pointers which the driver must initialize to complete its interface with the generic interface layer:
if_input
()if_input
() can be shared among multiple drivers
utilizing the same link-layer framing, e.g., Ethernet.if_output
()if_transmit
()ENOBUFS
if the devices
software and hardware queues are both full. This function must be
installed after if_attach
() to override the
default implementation. This function is exposed in order to allow drivers
to manage their own queues and to reduce the latency caused by a
frequently gratuitous enqueue / dequeue pair to ifq. The suggested
internal software queuing mechanism is buf_ring.if_qflush
()if_attach
()
to override the default implementation. This function is exposed in order
to allow drivers to manage their own queues and to reduce the latency
caused by a frequently gratuitous enqueue / dequeue pair to ifq. The
suggested internal software queuing mechanism is buf_ring.if_start
()if_output
() among all drivers.
if_start
() may only be called when the
IFF_DRV_OACTIVE
flag is not set. (Thus,
IFF_DRV_OACTIVE
does not literally mean that
output is active, but rather that the device's internal output queue is
full.) Please note that this function will soon be deprecated.if_ioctl
()<sys/sockio.h>
).
Preliminary processing is done by the generic routine
ifioctl
() to check for appropriate privileges,
locate the interface being manipulated, and perform certain generic
operations like twiddling flags and flushing queues. See the description
of ifioctl
() below for more information.if_init
()IFF_DRV_RUNNING
,
~IIF_DRV_OACTIVE
).if_resolvemulti
()Interface flags are used for a number of different purposes. Some flags simply indicate information about the type of interface and its capabilities; others are dynamically manipulated to reflect the current state of the interface. Flags of the former kind are marked ⟨S⟩ in this table; the latter are marked ⟨D⟩. Flags which begin with “IFF_DRV_” are stored in if_drv_flags; all other flags are stored in if_flags.
The macro IFF_CANTCHANGE
defines the bits
which cannot be set by a user program using the
SIOCSIFFLAGS
command to
ioctl(2); these are
indicated by an asterisk (‘*
’) in the
following listing.
IFF_UP
IFF_BROADCAST
IFF_DEBUG
IFF_LOOPBACK
IFF_POINTOPOINT
IFF_DRV_RUNNING
IFF_NOARP
IFF_PROMISC
IFF_PPROMISC
IFF_PROMISC
).IFF_ALLMULTI
IFF_DRV_OACTIVE
IFF_SIMPLEX
IFF_LINK0
IFF_LINK1
IFF_LINK2
IFF_MULTICAST
IFF_CANTCONFIG
IFT_USB
interfaces registered
at the interface list.IFF_MONITOR
IFF_STATICARP
IFF_DYING
IFF_RENAMING
Interface capabilities are specialized features an interface may or may not support. These capabilities are very hardware-specific and allow, when enabled, to offload specific network processing to the interface or to offer a particular feature for use by other kernel parts.
It should be stressed that a capability can be
completely uncontrolled (i.e., stay always enabled with no way to disable
it) or allow limited control over itself (e.g., depend on another
capability's state.) Such peculiarities are determined solely by the
hardware and driver of a particular interface. Only the driver possesses the
knowledge on whether and how the interface capabilities can be controlled.
Consequently, capabilities flags in if_capenable
should never be modified directly by kernel code other than the interface
driver. The command SIOCSIFCAP
to
ifioctl
()
is the dedicated means to attempt altering
if_capenable on an interface. Userland code shall use
ioctl(2).
The following capabilities are currently supported by the system:
IFCAP_RXCSUM
IFCAP_TXCSUM
IFCAP_HWCSUM
IFCAP_RXCSUM
|
IFCAP_TXCSUM
).IFCAP_NETCONS
IFCAP_VLAN_MTU
IFCAP_VLAN_HWTAGGING
IFCAP_JUMBO_MTU
IFCAP_POLLING
IFCAP_VLAN_HWCSUM
IFCAP_HWCSUM
).IFCAP_TSO4
IFCAP_TSO6
IFCAP_TSO
IFCAP_TSO4
|
IFCAP_TSO6
).IFCAP_TOE4
IFCAP_TOE6
IFCAP_TOE
IFCAP_TOE4
|
IFCAP_TOE6
).IFCAP_WOL_UCAST
IFCAP_WOL_MCAST
IFCAP_WOL_MAGIC
IFCAP_WOL
IFCAP_WOL_UCAST
|
IFCAP_WOL_MCAST
|
IFCAP_WOL_MAGIC
).IFCAP_TOE4
IFCAP_TOE6
IFCAP_TOE
IFCAP_TOE4
|
IFCAP_TOE6
).IFCAP_VLAN_HWFILTER
IFCAP_VLAN_HWTSO
IFCAP_TSO
).IFCAP_LINKSTATE
IFCAP_NETMAP
The ability of advanced network interfaces to offload certain computational tasks from the host CPU to the board is limited mostly to TCP/IP. Therefore a separate field associated with an interface (see ifnet.if_data.ifi_hwassist below) keeps a detailed description of its enabled capabilities specific to TCP/IP processing. The TCP/IP module consults the field to see which tasks can be done on an outgoing packet by the interface. The flags defined for that field are a superset of those for mbuf.m_pkthdr.csum_flags, namely:
An interface notifies the TCP/IP module about the tasks the former has performed on an incoming packet by setting the corresponding flags in the field mbuf.m_pkthdr.csum_flags of the mbuf chain containing the packet. See mbuf(9) for details.
The capability of a network interface to operate in
polling(4) mode involves
several flags in different global variables and per-interface fields. The
capability flag IFCAP_POLLING
set in interface's
if_capabilities indicates support for
polling(4) on the
particular interface. If set in if_capabilities, the
same flag can be marked or cleared in the interface's
if_capenable within
ifioctl
(),
thus initiating switch of the interface to
polling(4) mode or
interrupt mode, respectively. The actual mode change is managed by the
driver-specific if_ioctl
() routine. The
polling(4) handler
returns the number of packets processed.
The if_data structure contains statistics and identifying information used by management programs, and which is exported to user programs by way of the ifmib(4) branch of the sysctl(3) MIB. The following elements of the if_data structure are initialized by the interface and are not expected to change significantly over the course of normal operation:
<net/if_types.h>
and
described below in the Interface
Types section.The structure additionally contains generic statistics applicable to a variety of different interface types (except as noted, all members are of type u_long):
The header file
<net/if_types.h>
defines
symbolic constants for a number of different types of interfaces. The most
common are:
IFT_OTHER
IFT_ETHER
IFT_ISO88023
IFT_ISO88024
IFT_ISO88025
IFT_ISO88026
IFT_FDDI
IFT_PPP
IFT_LOOP
IFT_SLIP
IFT_PARA
IFT_ATM
IFT_USB
The following link states are currently defined:
LINK_STATE_UNKNOWN
LINK_STATE_DOWN
LINK_STATE_UP
Every interface is associated with a list (or, rather, a
TAILQ
) of addresses, rooted at the interface
structure's if_addrhead member. The first element in
this list is always an AF_LINK
address representing
the interface itself; multi-access network drivers should complete this
structure by filling in their link-layer addresses after calling
if_attach
().
Other members of the structure represent network-layer addresses which have
been configured by means of the SIOCAIFADDR
command
to ioctl(2), called on a
socket of the appropriate protocol family. The elements of this list consist
of ifaddr structures. Most protocols will declare
their own protocol-specific interface address structures, but all begin with
a struct ifaddr which provides the
most-commonly-needed functionality across all protocols. Interface addresses
are reference-counted.
The members of struct ifaddr are as follows:
TAILQ_ENTRY
(ifaddr))
queue(3) glue for list
of addresses on each interface.References to ifaddr structures
are gained by calling the
ifa_ref
()
function and released by calling the
ifa_free
()
function.
ifa_rtrequest
()
is a pointer to a function which receives callouts from the routing code
(rtrequest
())
to perform link-layer-specific actions upon requests to add, or delete
routes. The cmd argument indicates the request in
question: RTM_ADD
, or
RTM_DELETE
. The rt argument is
the route in question; the info argument contains the
specific destination being manipulated.
The functions provided by the generic interface code can be divided into two groups: those which manipulate interfaces, and those which manipulate interface addresses. In addition to these functions, there may also be link-layer support routines which are used by a number of drivers implementing a specific link layer over different hardware; see the documentation for that link layer for more details.
Every multicast-capable interface is associated with a list of multicast group memberships, which indicate at a low level which link-layer multicast addresses (if any) should be accepted, and at a high level, in which network-layer multicast groups a user process has expressed interest.
The elements of the structure are as follows:
LIST_ENTRY
(ifmultiaddr))
queue(3) macro
glue.if_alloc
()if_attach
()ifaddr_byindex
() function.) The
ifp must have been allocated by
if_alloc
().if_detach
()if_free
()if_free_type
()if_free
() except that the given
type is used to free if_l2com
instead of the type in if_type. This is intended for
use with drivers that change their interface type.if_down
()IFF_UP
is not set), flush its output queue, notify
protocols of the transition, and generate a message from the
route(4) routing
socket.if_up
()ifpromisc
()IFF_PROMISC
flag
appropriately and call if_ioctl
() to set up the
interface in the desired mode.if_allmulti
()ifpromisc
(), but for the all-multicasts
(IFF_ALLMULTI
) flag instead of the promiscuous
flag.ifunit
()ifunit_ref
()ifa_ref
())
ifnet pointer for the interface named
name. This is the preferred function over
ifunit
(). The caller is responsible for releasing
the reference with if_rele
() when it is finished
with the ifnet.ifioctl
()i
’.
Any unrecognized commands will be passed down to socket
so's protocol for further interpretation. The
following commands are handled by ifioctl
():
SIOCGIFCONF
SIOCSIFNAME
RTM_IFANNOUNCE
departure and arrival messages are sent so that routing code that
relies on the interface name will update its interface list. Caller
must have appropriate privilege. (No call-down to driver.)SIOCGIFCAP
SIOCGIFDATA
SIOCGIFFIB
SIOCGIFFLAGS
SIOCGIFMETRIC
SIOCGIFMTU
SIOCGIFPHYS
SIOCSIFCAP
if_ioctl
()
routine, the requested mask for enabled capabilities is checked
against the mask of capabilities supported by the interface,
if_capabilities. Requesting to enable an
unsupported capability is invalid. The rest is supposed to be done by
the driver, which includes updating if_capenable
and if_data.ifi_hwassist appropriately.
SIOCSIFFIB
SIOCSIFFLAGS
IFF_UP
flag is requested,
if_up
()
or
if_down
()
is called as appropriate. Flags listed in
IFF_CANTCHANGE
are masked off, and the field
if_flags in the interface structure is updated.
Finally, the driver if_ioctl
() routine is
called to perform any setup requested.
SIOCSIFMETRIC
SIOCSIFPHYS
SIOCSIFMTU
if_ioctl
()
routine is called to implement the change; it is responsible for any
additional sanity checking and for actually modifying the MTU in the
interface structure.
SIOCADDMULTI
SIOCDELMULTI
if_addmulti
()
or if_delmulti
() function is called to perform
the operation; qq.v.
SIOCAIFADDR
SIOCDIFADDR
Several functions exist to look up an interface address structure
given an address.
ifa_ifwithaddr
()
returns an interface address with either a local address or a broadcast
address precisely matching the parameter addr.
ifa_ifwithdstaddr
()
returns an interface address for a point-to-point interface whose remote
(“destination”) address is addr and a
fib is fib. If fib is
RT_ALL_FIBS
, then the first interface address
matching addr will be returned.
ifa_ifwithnet
()
returns the most specific interface address which matches the specified
address, addr, subject to its configured netmask, or a
point-to-point interface address whose remote address is
addr if one is found. If
ignore_ptp is true, skip point-to-point interface
addresses. The fib parameter is handled the same way
as by
ifa_ifwithdstaddr
().
ifaof_ifpforaddr
()
returns the most specific address configured on interface
ifp which matches address addr,
subject to its configured netmask. If the interface is point-to-point, only
an interface address whose remote address is precisely
addr will be returned.
ifaddr_byindex
()
returns the link-level address of the interface with the given index
idx.
All of these functions return a null pointer if no such address can be found.
The
if_addmulti
(),
if_delmulti
(), and
if_findmulti
() functions provide support for
requesting and relinquishing multicast group memberships, and for querying
an interface's membership list, respectively. The
if_addmulti
() function takes a pointer to an
interface, ifp, and a generic address,
sa. It also takes a pointer to a
struct ifmultiaddr * which is filled in on successful
return with the address of the group membership control block. The
if_addmulti
() function performs the following
four-step process:
if_resolvemulti
()
entry point to determine the link-layer address, if any, corresponding to
this membership request, and also to give the link layer an opportunity to
veto this membership request should it so desire.if_resolvemulti
() routine returned a
link-layer address corresponding to the group, repeat the previous step
for that address as well.if_ioctl
() routine (with a
cmd argument of
SIOCADDMULTI
) to request that it do so.The
if_delmulti
()
function, given an interface ifp and an address,
sa, reverses this process. Both functions return zero
on success, or a standard error number on failure.
The
if_findmulti
()
function examines the membership list of interface ifp
for an address matching sa, and returns a pointer to
that struct ifmultiaddr if one is found, else it
returns a null pointer.
ioctl(2), link_addr(3), queue(3), sysctl(3), bpf(4), ifmib(4), lo(4), netintro(4), polling(4), config(8), ppp(8), mbuf(9), rtentry(9)
Gary R. Wright and W. Richard Stevens, TCP/IP Illustrated, Vol. 2, Addison-Wesley, ISBN 0-201-63354-X.
This manual page was written by Garrett A. Wollman.
September 28, 2020 | midnightbsd-3.1 |