IFNET(9)

๐Ÿ’– IFNET(9) โ€” Kernel Developer's Manual ๐Ÿ’–

okay bestie, welcome to the ifnet man page! this is part 1 of 5, so grab your boba and let's get into it. we're talking kernel interfaces for manipulating network interfaces. it's giving big kernel energy. ๐Ÿ’…

โœจ NAME โœจ

ifnet, ifaddr, ifqueue, if_data โ€” kernel interfaces for manipulating network interfaces

no cap, that's the whole squad. they're the ones doing the network interface manipulation. periodt.

๐ŸŒธ SYNOPSIS ๐ŸŒธ

first, the includes. you gotta have these or you're literally lost:

#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>

then we got the functions, grouped by vibe.

๐Ÿฆ‹ Interface Manipulation Functions ๐Ÿฆ‹

these are the manipulators, bestie. they do the interface stuff:

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);

๐ŸŽ€ Interface Address Functions ๐ŸŽ€

address functions, for when you need to deal with addresses:

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);

๐Ÿ’… Interface Multicast Address Functions ๐Ÿ’…

multicast? we love a good multicast moment:

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);

๐Ÿซถ Output queue macros ๐Ÿซถ

just one macro here, but it's iconic:

IF_DEQUEUE(struct ifqueue *ifq, struct mbuf *m);

๐ŸŒˆ struct ifnet Member Functions ๐ŸŒˆ

these are the function pointers you can set in your struct ifnet. they're the main character energy of the interface:

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);

๐Ÿงš struct ifaddr member function ๐Ÿงš

one function for ifaddr:

void
(*ifa_rtrequest)(int cmd, struct rtentry *rt, struct rt_addrinfo *info);

๐Ÿ‘‘ Global Variables ๐Ÿ‘‘

these are the globals, they're kind of a big deal:

extern struct ifnethead ifnet;
extern int if_index;
extern int ifqmaxlen;

๐Ÿ’œ DATA STRUCTURES ๐Ÿ’œ

okay so now we get into the actual structures. the kernel's whole setup for handling network interfaces lives in these four structures: ifnet, if_data, ifaddr, and ifmultiaddr. you'll find them in <net/if.h> and <net/if_var.h>, and the functions are defined in /sys/net/if.c. the user-facing stuff is in <net/if.h> โ€” that's where the interface flags, the if_data structure, and the structures that define how interface-related messages look on the route(4) routing socket and in sysctl(3) are. the kernel-internal interfaces are in <net/if_var.h> โ€” that includes the ifnet, ifaddr, and ifmultiaddr structures and the functions that manipulate them. (a few user programs will need <net/if_var.h> because it's a prerequisite for other headers like <netinet/if_ether.h>. most references to those two files can be replaced by <net/ethernet.h>.)

the system keeps a linked list of interfaces using the TAILQ macros from queue(3). the head of this list is a struct ifnethead called ifnet. the elements are struct ifnet, and most kernel routines that manipulate interfaces 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)) that describes the link layer implemented by the interface (if any) is accessed by the ifaddr_byindex() function or the if_addr structure. (some trivial interfaces don't provide any link layer addresses; this structure, while still present, serves only to identify the interface name and index.)

finally, those interfaces that support 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 ifnet Structure ๐Ÿฆ‹

the fields of struct ifnet are literally all these, bestie:

  • if_softc (void *) โ€” A pointer to the driver's private state block. (Initialized by driver.)
  • if_l2com (void *) โ€” A pointer to the common data for the interface's layer 2 protocol. (Initialized by if_alloc().)
  • if_vnet (struct vnet *) โ€” A pointer to the virtual network stack instance. (Initialized by if_attach().)
  • if_home_vnet (struct vnet *) โ€” A pointer to the parent virtual network stack, where this struct ifnet originates from. (Initialized by if_attach().)
  • if_link (TAILQ_ENTRY(ifnet)) โ€” queue(3) macro glue.
  • if_xname (char *) โ€” The name of the interface, (e.g., "fxp0" or "lo0"). (Initialized by driver (usually via if_initname()).)
  • if_dname (const char *) โ€” The name of the driver. (Initialized by driver (usually via if_initname()).)
  • if_dunit (int) โ€” A unique number assigned to each interface managed by a particular driver. Drivers may choose to set this to IF_DUNIT_NONE if a unit number is not associated with the device. (Initialized by driver (usually via if_initname()).)
  • if_refcount (u_int) โ€” The reference count. (Initialized by if_alloc().)
  • if_addrhead (struct ifaddrhead) โ€” The head of the queue(3) TAILQ containing the list of addresses assigned to this interface.
  • if_pcount (int) โ€” A count of promiscuous listeners on this interface, used to reference-count the IFF_PROMISC flag.
  • if_carp (struct carp_if *) โ€” A pointer to the CARP interface structure, carp(4). (Initialized by the driver-specific if_ioctl() routine.)
  • if_bpf (struct bpf_if *) โ€” Opaque per-interface data for the packet filter, bpf(4). (Initialized by bpf_attach().)
  • if_index (u_short) โ€” A unique number assigned to each interface in sequence as it is attached. This number can be used in a struct sockaddr_dl to refer to a particular interface by index (see link_addr(3)). (Initialized by if_alloc().)
  • if_vlantrunk (struct ifvlantrunk *) โ€” A pointer to 802.1Q trunk structure, vlan(4). (Initialized by the driver-specific if_ioctl() routine.)
  • if_flags (int) โ€” Flags describing operational parameters of this interface (see below). (Manipulated by generic code.)
  • if_drv_flags (int) โ€” Flags describing operational status of this interface (see below). (Manipulated by driver.)
  • if_capabilities (int) โ€” Flags describing the capabilities the interface supports (see below).
  • if_capenable (int) โ€” Flags describing the enabled capabilities of the interface (see below).
  • if_linkmib (void *) โ€” A pointer to an interface-specific MIB structure exported by ifmib(4). (Initialized by driver.)
  • if_linkmiblen (size_t) โ€” The size of said structure. (Initialized by driver.)
  • if_data (struct if_data) โ€” More statistics and information; see โ€œThe if_data structureโ€, below. (Initialized by driver, manipulated by both driver and generic code.)
  • if_multiaddrs (struct ifmultihead) โ€” The head of the queue(3) TAILQ containing the list of multicast addresses assigned to this interface.
  • if_amcount (int) โ€” A number of multicast requests on this interface, used to reference-count the IFF_ALLMULTI flag.
  • if_addr (struct ifaddr *) โ€” A pointer to the link-level interface address. (Initialized by if_alloc().)
  • if_snd (struct ifaltq) โ€” The output queue. (Manipulated by driver.)
  • if_broadcastaddr (const u_int8_t *) โ€” A link-level broadcast bytestring for protocols with variable address length.
  • if_bridge (void *) โ€” A pointer to the bridge interface structure, if_bridge(4). (Initialized by the driver-specific if_ioctl() routine.)
  • if_label (struct label *) โ€” A pointer to the MAC Framework label structure, mac(4). (Initialized by if_alloc().)
  • if_afdata (void *) โ€” An address family dependent data region.
  • if_afdata_initialized (int) โ€” Used to track the current state of address family initialization.
  • if_afdata_lock (struct rwlock) โ€” An rwlock(9) lock used to protect if_afdata internals.
  • if_linktask (struct task) โ€” A taskqueue(9) task scheduled for link state change events of the interface.
  • if_addr_lock (struct rwlock) โ€” An rwlock(9) lock used to protect interface-related address lists.
  • if_clones (LIST_ENTRY(ifnet)) โ€” queue(3) macro glue for the list of clonable network interfaces.
  • if_groups (TAILQ_HEAD(, ifg_list)) โ€” bestie this is literally the head of the queue(3) TAILQ that holds the list of groups per interface. group chat, but for interfaces ๐Ÿ’…
  • if_pf_kif (void *) โ€” a pointer to the structure that pf(4) uses for interface abstraction.
  • if_lagg (void *) โ€” a pointer to the lagg(4) interface structure.
  • if_alloctype (u_char) โ€” the type of the interface as it was at the time of its allocation. It's there to cache the type that got passed to if_alloc(), and โ€” plot twist โ€” unlike if_type, drivers don't get to change it. periodt.

References to ifnet structures are gained by calling the if_ref() function and released by calling the if_rele() function. They exist so kernel code that's out here walking global interface lists can release the ifnet lock yet keep the ifnet structure stable. iconic behaviour honestly.

There are also a bunch of function pointers that a driver must initialize to complete its interface with the generic interface layer. no skipping these, they're mandatory fr fr:

  • if_input() โ€” Pass a packet to an appropriate upper layer, as determined from the link-layer header of the packet. This routine is to be called from an interrupt handler, or used to emulate reception of a packet on this interface. A single function implementing if_input() can be shared among multiple drivers utilizing the same link-layer framing, e.g., Ethernet. sharing is caring โœจ
  • if_output() โ€” Output a packet on interface ifp, or queue it on the output queue if the interface is already active.
  • if_transmit() โ€” Transmit a packet on an interface, or queue it if the interface is in use. This function will return ENOBUFS if the device's software and hardware queues are both full. This function must be installed after if_attach() to override the default implementation. It's exposed so drivers can manage their own queues and reduce the latency caused by a frequently gratuitous enqueue / dequeue pair to ifq. The suggested internal software queuing mechanism is buf_ring.
  • if_qflush() โ€” Free mbufs in internally managed queues when the interface is marked down. This function must be installed after if_attach() to override the default implementation. It's exposed so drivers can manage their own queues and reduce the latency caused by a frequently gratuitous enqueue / dequeue pair to ifq. The suggested internal software queuing mechanism is buf_ring. (yes bestie, same energy as if_transmit(), the manpage said it twice, so I'm telling you twice ๐Ÿ’–)
  • if_start() โ€” Start queued output on an interface. This function is exposed to provide for some interface classes to share an if_output() among all drivers. if_start() may only be called when the IFF_DRV_OACTIVE flag is not set. (So lowkey IFF_DRV_OACTIVE does not literally mean output is active โ€” it means the device's internal output queue is full.) ๐Ÿ‘‘ Please note that this function will soon be deprecated.
  • if_ioctl() โ€” Process interface-related ioctl(2) requests (defined in <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() โ€” Initialize and bring up the hardware, e.g., reset the chip and enable the receiver unit. Should mark the interface running, but not active (IFF_DRV_RUNNING, ~IIF_DRV_OACTIVE).
  • if_resolvemulti() โ€” Check the requested multicast group membership, addr, for validity, and if necessary compute a link-layer group which corresponds to that address, which is returned in *retsa. Returns zero on success, or an error code on failure.

๐Ÿšฉ Interface Flags ๐Ÿšฉ

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. so like, don't try it ๐Ÿ’€

  • IFF_UP โŸจDโŸฉ โ€” The interface has been configured up by the user-level code.
  • IFF_BROADCAST โŸจS*โŸฉ โ€” The interface supports broadcast.
  • IFF_DEBUG โŸจDโŸฉ โ€” Used to enable/disable driver debugging code.
  • IFF_LOOPBACK โŸจSโŸฉ โ€” The interface is a loopback device.
  • IFF_POINTOPOINT โŸจS*โŸฉ โ€” The interface is point-to-point; the โ€œbroadcastโ€ address is actually the address of the other end.
  • IFF_DRV_RUNNING โŸจD*โŸฉ โ€” The interface has been configured and dynamic resources were successfully allocated. Probably only useful internal to the interface.
  • IFF_NOARP โŸจDโŸฉ โ€” Disable network address resolution on this interface.
  • IFF_PROMISC โŸจD*โŸฉ โ€” This interface is in promiscuous mode.
  • IFF_PPROMISC โŸจDโŸฉ โ€” This interface is in the permanently promiscuous mode (implies IFF_PROMISC).
  • IFF_ALLMULTI โŸจD*โŸฉ โ€” This interface is in all-multicasts mode (used by multicast routers).
  • IFF_DRV_OACTIVE โŸจD*โŸฉ โ€” The interface's hardware output queue (if any) is full; output packets are to be queued.
  • IFF_SIMPLEX โŸจS*โŸฉ โ€” The interface cannot hear its own transmissions. relatable honestly ๐Ÿ˜ญ
  • IFF_LINK0
  • IFF_LINK1
  • IFF_LINK2 โŸจDโŸฉ โ€” Control flags for the link layer. (Currently abused to select among multiple physical layers on some devices.)
  • IFF_MULTICAST โŸจS*โŸฉ โ€” This interface supports multicast.
  • IFF_CANTCONFIG โŸจS*โŸฉ โ€” The interface is not configurable in a meaningful way. Primarily useful for IFT_USB interfaces registered at the interface list.
  • IFF_MONITOR โŸจDโŸฉ โ€” This interface blocks transmission of packets and discards incoming packets after BPF processing. Used to monitor network traffic but not interact with the network in question. main character energy: watching everything, saying nothing ๐Ÿ‘€
  • IFF_STATICARP โŸจDโŸฉ โ€” Used to enable/disable ARP requests on this interface.
  • IFF_DYING โŸจD*โŸฉ โ€” Set when the ifnet structure of this interface is being released and still has if_refcount references. it's giving... expiry date ๐Ÿ’€
  • IFF_RENAMING โŸจDโŸฉ โ€” Set when this interface is being renamed.

โœจ Interface Capabilities Flags โœจ

Interface capabilities are specialized features an interface may or may not support. These capabilities are very hardware-specific, and allow โ€” when enabled โ€” offloading specific network processing to the interface, or offering 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).

bestie. do NOT just go poking at if_capenable yourself. that's not your lane, that's the driver's lane. use SIOCSIFCAP. ๐Ÿซถ

The following capabilities are currently supported by the system:

  • IFCAP_RXCSUM โ€” This interface can do checksum validation on receiving data. Some interfaces do not have sufficient buffer storage to store frames above a certain MTU-size completely. The driver for the interface might disable hardware checksum validation if the MTU is set above the hardcoded limit.
  • IFCAP_TXCSUM โ€” This interface can do checksum calculation on transmitting data.
  • IFCAP_HWCSUM โ€” A shorthand for (IFCAP_RXCSUM | IFCAP_TXCSUM).
  • IFCAP_NETCONS โ€” This interface can be a network console.
  • IFCAP_VLAN_MTU โ€” The vlan(4) driver can operate over this interface in software tagging mode without having to decrease MTU on vlan(4) interfaces below 1500 bytes. This implies the ability of this interface to cope with frames somewhat longer than permitted by the Ethernet specification.
  • IFCAP_VLAN_HWTAGGING โ€” This interface can do VLAN tagging on output and demultiplex frames by their VLAN tag on input.
  • IFCAP_JUMBO_MTU โ€” This Ethernet interface can transmit and receive frames up to 9000 bytes long. big frames, big slay ๐Ÿ”ฅ
  • IFCAP_POLLING โ€” This interface supports polling(4). See below for details.
  • IFCAP_VLAN_HWCSUM โ€” This interface can do checksum calculation on both transmitting and receiving data on vlan(4) interfaces (implies IFCAP_HWCSUM).
  • IFCAP_TSO4 โ€” This Ethernet interface supports TCP4 Segmentation offloading.
  • IFCAP_TSO6 โ€” This Ethernet interface supports TCP6 Segmentation offloading.
  • IFCAP_TSO โ€” A shorthand for (IFCAP_TSO4 | IFCAP_TSO6).
  • IFCAP_TOE4 โ€” This Ethernet interface supports TCP offloading.
  • IFCAP_TOE6 โ€” This Ethernet interface supports TCP6 offloading.
  • IFCAP_TOE โ€” A shorthand for (IFCAP_TOE4 | IFCAP_TOE6).
  • IFCAP_WOL_UCAST โ€” bestie, this Ethernet interface can wake up on any Unicast packet. iconic behavior fr. ๐Ÿ’คโœจ
  • IFCAP_WOL_MCAST โ€” same energy but for any Multicast packet. she hears everything.
  • IFCAP_WOL_MAGIC โ€” wakes up on any Magic packet, like the ones wake(8) sends. it's giving summoned by spell. ๐Ÿช„
  • IFCAP_WOL โ€” a lil shorthand for (IFCAP_WOL_UCAST | IFCAP_WOL_MCAST | IFCAP_WOL_MAGIC). one flag to rule them all.
  • IFCAP_TOE4 โ€” this Ethernet interface supports TCP4 Offload Engine. CPU said "not my job."
  • IFCAP_TOE6 โ€” same but TCP6 Offload Engine. equal opportunity offloading. ๐Ÿซถ
  • IFCAP_TOE โ€” shorthand for (IFCAP_TOE4 | IFCAP_TOE6). slay.
  • IFCAP_VLAN_HWFILTER โ€” supports frame filtering in hardware on vlan(4) interfaces. hardware doing the heavy lifting, we love to see it.
  • IFCAP_VLAN_HWTSO โ€” supports TCP Segmentation offloading on vlan(4) interfaces (and yes, it implies IFCAP_TSO). lowkey doing two jobs at once.
  • IFCAP_LINKSTATE โ€” this Ethernet interface supports dynamic link state changes. she can change, okay?? growth. ๐ŸŒฑ
  • IFCAP_NETMAP โ€” supports netmap(4). fancy.

The ability of advanced network interfaces to offload certain computational tasks from the host CPU to the board is limited mostly to TCP/IP. So, like, a separate field associated with an interface (peep ifnet.if_data.ifi_hwassist down below ๐Ÿ‘‡) keeps a detailed description of its enabled capabilities specific to TCP/IP processing. The TCP/IP module consults that 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:

  • CSUM_IP โ€” the interface will compute IP checksums.
  • CSUM_TCP โ€” the interface will compute TCP checksums.
  • CSUM_UDP โ€” the interface will compute UDP checksums.

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. iykyk. ๐Ÿ“จ

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. (not the number of vibes, the actual packets. ๐Ÿ’…)

๐ŸŒธ The if_data Structure ๐ŸŒธ

Okay so 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:

  • ifi_type (u_char) โ€” the type of the interface, as defined in <net/if_types.h> and described below in the โ€œInterface Typesโ€ section.
  • ifi_physical (u_char) โ€” intended to represent a selection of physical layers on devices which support more than one; never implemented. girl was announced and then ghosted. ๐Ÿ˜ญ
  • ifi_addrlen (u_char) โ€” length of a link-layer address on this device, or zero if there are none. Used to initialized the address length field in sockaddr_dl structures referring to this interface.
  • ifi_hdrlen (u_char) โ€” maximum length of any link-layer header which might be prepended by the driver to a packet before transmission. The generic code computes the maximum over all interfaces and uses that value to influence the placement of data in mbufs to attempt to ensure that there is always sufficient space to prepend a link-layer header without allocating an additional mbuf.
  • ifi_datalen (u_char) โ€” length of the if_data structure. Allows some stabilization of the routing socket ABI in the face of increases in the length of struct ifdata.
  • ifi_mtu (u_long) โ€” the maximum transmission unit of the medium, exclusive of any link-layer overhead.
  • ifi_metric (u_long) โ€” a dimensionless metric interpreted by a user-mode routing process.
  • ifi_baudrate (u_long) โ€” the line rate of the interface, in bits per second. fast girl. ๐Ÿƒโ€โ™€๏ธ
  • ifi_hwassist (u_long) โ€” a detailed interpretation of the capabilities to offload computational tasks for outgoing packets. The interface driver must keep this field in accord with the current value of if_capenable.
  • ifi_epoch (time_t) โ€” the system uptime when interface was attached or the statistics below were reset. This is intended to be used to set the SNMP variable ifCounterDiscontinuityTime. It may also be used to determine if two successive queries for an interface of the same index have returned results for the same interface.

The structure additionally contains generic statistics applicable to a variety of different interface types (except as noted, all members are of type u_long):

  • ifi_link_state (u_char) โ€” the current link state of Ethernet interfaces. See the โ€œInterface Link Statesโ€ section for possible values.
  • ifi_ipackets โ€” number of packets received.
  • ifi_ierrors โ€” number of receive errors detected (e.g., FCS errors, DMA overruns, etc.). More detailed breakdowns can often be had by way of a link-specific MIB.
  • ifi_opackets โ€” number of packets transmitted.
  • ifi_oerrors โ€” number of output errors detected (e.g., late collisions, DMA overruns, etc.). More detailed breakdowns can often be had by way of a link-specific MIB.
  • ifi_collisions โ€” total number of collisions detected on output for CSMA interfaces. (This member is sometimes [ab]used by other types of interfaces for other output error counts.) the square brackets are doing so much work here ๐Ÿ’€
  • ifi_ibytes โ€” total traffic received, in bytes.
  • ifi_obytes โ€” total traffic transmitted, in bytes.
  • ifi_imcasts โ€” number of packets received which were sent by link-layer multicast.
  • ifi_omcasts โ€” number of packets sent by link-layer multicast.
  • ifi_iqdrops โ€” number of packets dropped on input. Rarely implemented.
  • ifi_oqdrops โ€” number of packets dropped on output.
  • ifi_noproto โ€” number of packets received for unknown network-layer protocol.
  • ifi_lastchange (struct timeval) โ€” the time of the last administrative change to the interface (as required for SNMP).

๐ŸŒˆ Interface Types ๐ŸŒˆ

The header file <net/if_types.h> defines symbolic constants for a number of different types of interfaces. The most common are:

  • IFT_OTHER โ€” none of the following
  • IFT_ETHER โ€” Ethernet
  • IFT_ISO88023 โ€” ISO 8802-3 CSMA/CD
  • IFT_ISO88024 โ€” ISO 8802-4 Token Bus
  • IFT_ISO88025 โ€” ISO 8802-5 Token Ring
  • IFT_ISO88026 โ€” ISO 8802-6 DQDB MAN
  • IFT_FDDI โ€” FDDI
  • IFT_PPP โ€” Internet Point-to-Point Protocol (ppp(8))
  • IFT_LOOP โ€” The loopback (lo(4)) interface
  • IFT_SLIP โ€” Serial Line IP
  • IFT_PARA โ€” Parallel-port IP (โ€œPLIPโ€)
  • IFT_ATM โ€” Asynchronous Transfer Mode
  • IFT_USB โ€” USB Interface

The following link states are currently defined:

  • LINK_STATE_UNKNOWN โ€” the link is in an invalid or unknown state. mystery era. ๐Ÿ”ฎ
  • LINK_STATE_DOWN โ€” the link is down. ๐Ÿ˜”
  • LINK_STATE_UP โ€” the link is up. WE'RE SO BACK. ๐Ÿ”ฅ

๐Ÿ’– The ifaddr Structure ๐Ÿ’–

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. (she's counting her references, as she should ๐Ÿ’…)

The members of struct ifaddr are as follows:

  • ifa_addr (struct sockaddr *) โ€” the local address of the interface.
  • ifa_dstaddr (struct sockaddr *) โ€” the remote address of point-to-point interfaces, and the broadcast address of broadcast interfaces. (ifa_broadaddr is a macro for ifa_dstaddr.) one field, two personalities.
  • ifa_netmask (struct sockaddr *) โ€” the network mask for multi-access interfaces, and the confusion generator for point-to-point interfaces. ๐Ÿ˜ตโ€๐Ÿ’ซ
  • ifa_ifp (struct ifnet *) โ€” a link back to the interface structure.
  • ifa_link (TAILQ_ENTRY(ifaddr)) โ€” queue(3) glue for list of addresses on each interface.
  • ifa_rtrequest โ€” see below.
  • ifa_flags (u_short) โ€” some of the flags which would be used for a route representing this address in the route table.
  • ifa_refcnt (short) โ€” bestie, itโ€™s literally the reference count. ๐Ÿ’…

References to ifaddr structures are gained by calling the ifa_ref() function and released by calling the ifa_free() function. No cap. ๐Ÿฆ‹

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. Periodt. โœจ


โœจ FUNCTIONS โœจ

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. iykyk ๐Ÿ’–


๐ŸŽ€ The ifmultiaddr Structure ๐ŸŽ€

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:

  • ifma_link (LIST_ENTRY(ifmultiaddr)) โ€” queue(3) macro glue. ๐Ÿซถ
  • ifma_addr (struct sockaddr *) โ€” A pointer to the address which this record represents. The memberships for various address families are stored in arbitrary order. โœจ
  • ifma_lladdr (struct sockaddr *) โ€” A pointer to the link-layer multicast address, if any, to which the network-layer multicast address in ifma_addr is mapped, else a null pointer. If this element is non-nil, this membership also holds an invisible reference to another membership for that link-layer address. ๐Ÿ’œ
  • ifma_refcount (u_int) โ€” A reference count of requests for this particular membership. ๐Ÿ”ฅ

๐Ÿ› ๏ธ Interface Manipulation Functions ๐Ÿ› ๏ธ

  • if_alloc() โ€” Allocate and initialize struct ifnet. Initialization includes the allocation of an interface index and may include the allocation of a type specific structure in if_l2com. ๐Ÿ’…
  • if_attach() โ€” Link the specified interface ifp into the list of network interfaces. Also initialize the list of addresses on that interface, and create a link-layer ifaddr structure to be the first element in that list. (A pointer to this address structure is saved in the ifnet structure and is accessed by the ifaddr_byindex() function.) The ifp must have been allocated by if_alloc(). ๐Ÿฆ‹
  • if_detach() โ€” Shut down and unlink the specified ifp from the interface list. โœจ
  • if_free() โ€” Free the given ifp back to the system. The interface must have been previously detached if it was ever attached. ๐Ÿ’–
  • if_free_type() โ€” Identical to 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() โ€” Mark the interface ifp as down (i.e., 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() โ€” Mark the interface ifp as up, notify protocols of the transition, and generate a message from the route(4) routing socket. โฌ†๏ธ
  • ifpromisc() โ€” Add or remove a promiscuous reference to ifp. If pswitch is true, add a reference; if it is false, remove a reference. On reference count transitions from zero to one and one to zero, set the IFF_PROMISC flag appropriately and call if_ioctl() to set up the interface in the desired mode. ๐Ÿ‘€
  • if_allmulti() โ€” As ifpromisc(), but for the all-multicasts (IFF_ALLMULTI) flag instead of the promiscuous flag. ๐ŸŒˆ
  • ifunit() โ€” Return an ifnet pointer for the interface named name. ๐Ÿ’ซ
  • ifunit_ref() โ€” Return a reference-counted (via 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() โ€” Process the ioctl request cmd, issued on socket so by thread td, with data parameter data. This is the main routine for handling all interface configuration requests from user mode. It is ordinarily only called from the socket-layer ioctl(2) handler, and only for commands with class โ€˜iโ€™. Any unrecognized commands will be passed down to socket so's protocol for further interpretation. The following commands are handled by ifioctl(): ๐Ÿ‘‘
    • SIOCGIFCONF โ€” Get interface configuration. (No call-down to driver.) ๐Ÿ“‹
    • SIOCSIFNAME โ€” Set the interface name. 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, SIOCGIFFIB, SIOCGIFFLAGS, SIOCGIFMETRIC, SIOCGIFMTU, SIOCGIFPHYS โ€” Get interface capabilities, FIB, flags, metric, MTU, medium selection. (No call-down to driver.) ๐Ÿ”
    • SIOCSIFCAP โ€” Enable or disable interface capabilities. Caller must have appropriate privilege. Before a call to the driver-specific 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 โ€” Sets interface FIB. Caller must have appropriate privilege. FIB values start at 0 and values greater or equals than net.fibs are considered invalid. ๐Ÿ’…
    • SIOCSIFFLAGS โ€” Change interface flags. Caller must have appropriate privilege. If a change to the 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 โ€” Change interface metric or medium. Caller must have appropriate privilege. โš–๏ธ
    • SIOCSIFMTU โ€” Change interface MTU. Caller must have appropriate privilege. MTU values less than 72 or greater than 65535 are considered invalid. The driver 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 โ€” Add or delete permanent multicast group memberships on the interface. Caller must have appropriate privilege. The if_addmulti() or if_delmulti() function is called to perform the operation; qq.v. ๐Ÿ“ฌ
    • SIOCAIFADDR, SIOCDIFADDR โ€” The socket's protocol control routine is called to implement the requested action. ๐Ÿงš
if_down(), ifioctl(), ifpromisc(), and if_up() must be called at splnet() or higher. โš ๏ธ

๐Ÿ—บ๏ธ Interface Address Functions ๐Ÿ—บ๏ธ

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. ๐Ÿ’€


๐Ÿ“ฌ Interface Multicast Address Functions ๐Ÿ“ฌ

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: ๐Ÿฆ‹

  1. Hit up the interface's if_resolvemulti() entry point to figure out the link-layer address (if there even is one, bestie ๐Ÿ’…) that matches this membership request โ€” and also to let the link layer veto the whole thing if it's feeling some type of way about it. It's giving "we asked, you can say no."
  2. Now go check the interface's group membership list for a membership that already exists for this group. Didn't find one? Slay, allocate a fresh new one. Found one? Cool, just increment its reference count. No drama.
  3. If if_resolvemulti() handed back a link-layer address that corresponds to the group, then run that exact same previous step for that address too. Same energy, different address, periodt.
  4. If the interface's multicast address filter needs to be changed because a new membership just got added, then call the interface's if_ioctl() routine (with a cmd argument of SIOCADDMULTI) to politely request that it go ahead and do that. โœจ

The if_delmulti() function, when you hand it an interface ifp and an address sa, just runs that whole process backwards. Undoing, iconic behaviour honestly. Both functions return zero on success, or a standard error number on failure. ๐Ÿซถ

The if_findmulti() function digs through the membership list of interface ifp looking for an address that matches sa, and returns a pointer to that struct ifmultiaddr if it finds one. If not? It returns a null pointer. Sorry bestie, no results. ๐Ÿ˜ญ

๐ŸŒˆ SEE ALSO ๐ŸŒˆ

Gary R. Wright and W. Richard Stevens, TCP/IP Illustrated, Vol. 2, Addison-Wesley, ISBN 0-201-63354-X.

๐Ÿ‘‘ AUTHORS ๐Ÿ‘‘

This manual page was written by Garrett A. Wollman. Absolute legend, no cap. ๐Ÿ’œ


And that's a wrap on the whole page, bestie! This one shipped with Debian's manpage set, dated November 14, 2018 โ€” go off, historic documentation. Study it, love it, and may your interfaces always resolve their multis correctly. ๐Ÿฆ‹โœจ

๐Ÿ“ฆ where this page comes from