![[Contents]](icons/contents.gif){kind=icon}
![[Index]](icons/index.gif){kind=icon}
![[Prev]](icons/prev.gif){kind=icon}
![[Next]](icons/next.gif){kind=icon}
The WindView networking events fall into two classes. The core network class (WV_NET_CORE_CLASS) contains events which are directly related to data transfer between hosts. The auxiliary network class (WV_NET_AUX_CLASS) contains events for all other network operations, such as updating the routing table and handling socket operations. Like the existing classes, these two categories determine which events a target reports. In addition to the class setting, events may be enabled or disabled individually, or in groups based on the priority level.
The priority of networking events range from WV_NET_EMERGENCY (1) to WV_NET_VERBOSE (8). An instrumented target reports all events of equal or higher priority within the selected classes (unless specifically disabled) as well as any individual events of lower priority which are specifically enabled. Finally, some events support filtering based on the values of the source or destination addresses and port numbers.
The default setting includes all events for all priority levels within the selected classes without using any available port or address filters.
See the online VxWorks API Reference entry for wvNetLib for more information about priority levels, classes, filters and the available routines for configuring the collection of networking events.
Table 3-1 lists all the WindView networking events in alphabetical order, ignoring underscore characters and hyphens. The listing includes the event class, priority level, individual offset within that level, available filters, if any, and a reference to the full description of the event.
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
The networking events dictionary sections describe the networking events collected by WindView. There is one section for each priority level (EMERGENCY, ALERT, and so on). For each event, the following information is shown:
Table 3-2 lists the networking event priority levels that can be logged.
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
Panic events correspond to internal calls to the panic( ) routine, which displays an identifying error message on the console. Possible causes include memory allocation failures or attempts to free unallocated memory. Most conditions which trigger these events are only theoretical possibilities and are very unlikely to occur.
Table 3-3 lists the event names, class, IDs,and descriptions of each Panic level event
Table 3-4 lists additional information that is collected with certain panic events, in addition to the unique internal identifier.
Memory Allocation FailuresThese events signal critical memory allocation failures which may permanently disrupt the network processing. An increase in the size of the memory pools is probably necessary for correct operation. Transient allocation failures which will not interfere with later processing are listed below under a lower priority.
Table 3-5 lists the details and a brief description of each event in this category.
Memory Allocation Failures - additional parametersTable 3-6 describes the additional information included with certain memory allocation failure events, in addition to the unique internal identifier.
icmp_error-start: memory allocation failureThis event indicates that the network system is generating an ICMP source quench message. That message occurs when an attempt to forward an IP packet fails because of insufficient memory. This event also occurs at a lower priority level for other ICMP messages.It is part of the core net event class. No additional filters are available.
Most emergency events occur unconditionally whenever the event class is selected and the EMERGENCY priority level is active. Table 3-7 lists the filters available for some emergency events.
These events indicate recoverable error conditions which require some type of user action to correct. An explanatory log message is also sent to the console for each event. These events generally signify corrupted entries in the radix tree which stores the routing table. None of the events support additional filtering beyond the (required) class and priority selection.
This priority level contains events which indicate uncorrectable transient errors. Some of these events can be avoided by altering the system configuration, but most cannot be prevented by any user action. The operations in process when the error occurs will fail, and any network data is usually discarded, but these events have no permanent effect on the network processing. A checksum failure on incoming data is a typical event for this priority level.
ifpromisc-ifdown: failure to change promiscuous mode settingThis event occurs when attempting to enable or disable promiscuous mode for a particular device. This setting, which is disabled by default, allows a device to receive all link-layer frames regardless of the destination address. The IFF_PROMISC flag which reflects the current setting cannot be altered with an ioctl( ) call like other flags. The setting can only be changed with this routine.
This event indicates that the device is disabled (for example. the IFF_UP flag is not set). The ifpromisc( ) routine returns ENETDOWN and the current setting is unchanged.
This event is part of the auxiliary net event class.No additional filters are available.
arpioctl-noentry: unable to find matching IP addressThis event occurs when the network stack is processing a request from the generic I/O control interface. The ioctl.h include file defines the available operations. The request parameter included in this event contains the resulting four byte value. The first two arguments to the _IOxx macros in the include file provide the values for the final two bytes, which indicate the particular request. The third byte indicates whether it applies to sockets (`s': 0x73), routes (`r': 0x72), or interfaces (`i': 0x69). The fourth byte (second argument) is a unique offset within each category.
The arpioctl( ) routine handles the interface-specific SIOCSARP, SIOCGARP, and SIOCDARP operations (request values with the format 0xaa2469dd) which provide applications with direct access to the ARP table. This event indicates that the specified IP address is unknown. The ARP entry for the given hardware address is not affected and the ioctl( ) call returns ENETUNREACH (for SIOCSARP) or EADDRNOTAVAIL (for SIOCDARP). This event is part of the auxiliary net event class. No additional filters are available.
ether_output-ifdown: sending Ethernet frame over disabled interfaceThis event indicates that the network stack is unable to generate an Ethernet frame for transmission by a network interface. The ether_output( ) routine processes IP packets for delivery to BSD drivers by prepending an Ethernet header to the corresponding M_BLK chain.
This event occurs when attempting to send output over an interface which is currently unavailable (either the IFF_UP or IFF_RUNNING flag are not set). The error number is set to ENETDOWN. This event is part of the core net event class. No additional filters are available.
ether_output-nomem: insufficient space for sending over interfaceThis event indicates that the network stack is unable to generate an Ethernet frame for transmission by a network interface. The ether_output( ) routine processes IP packets for delivery to BSD drivers by prepending an Ethernet header to the corresponding M_BLK chain.
This event occurs when no memory is available for sending an Ethernet frame. It can occur because of a memory allocation error if no memory is available for the frame header, but the most likely cause is an overflow of the interface-specific send queue. In either case, the frame is discarded and the error number is set to ENOBUFS. This event is part of the core net event class. No additional filters are available.
ether_output-noroute: unreachable destination for IP/Ethernet dataThis event indicates that the network stack is unable to generate an Ethernet frame for transmission by a network interface. The ether_output( ) routine processes IP packets for delivery to BSD drivers by prepending an Ethernet header to the corresponding M_BLK chain. It obtains the destination hardware address from the ARP cache which is accessed through the route entry for the destination IP address.
This event occurs when no routing entry is available for the destination. The frame is discarded and the error number is set to EHOSTUNREACH. This event is part of the core net event class. Additional filtering based on the IP address is available with type of 1 (destination) and direction of 1 (output).
ether_output-rtreject: destination temporarily disabledThis event indicates that the network stack is unable to generate an Ethernet frame for transmission by a network interface. The ether_output( ) routine processes IP packets for delivery to BSD drivers by prepending an Ethernet header to the corresponding M_BLK chain. It obtains the destination hardware address from the ARP cache which is accessed through the route entry for the destination IP address.
This event indicates that the destination has not been responding to ARP requests. After unsuccessfully sending the number of requests specified by the arp_maxtries variable (5 by default), transmissions to the destination are disabled for arpt_down seconds (20 by default). Because that restriction is in effect, the frame is discarded and the error number is set to EHOSTDOWN or EHOSTUNREACH. This event is part of the core net event class. No additional filters are available.
igmp_input-shortmsg: truncated message receivedThis event indicates that the network system received an IGMP packet which either does not contain the minimum 8 bytes needed for a complete message or is unexpectedly truncated before the reported message size. The data is discarded after incrementing the appropriate counter in the IGMP statistics.This event is part of the core net event class. No additional filters are available.
igmp_input-badsum: corrupted message received
icmp_error-start: IP processing failureThis event indicates that the network system is generating an ICMP error due to problems processing an IP packet. This event also occurs at a higher priority level when the network system generates an ICMP source quench message. It is part of the core net event class. No additional filters are available.
icmp_input-shortmsg: truncated message receivedThis event indicates that the network stack is unable to process a received ICMP message. The icmp_input( ) routine handles data contained in IP packets with a protocol value of 1, generating replies for all supported request messages (types 8, 13, and 17). After completing any necessary processing, the input routine calls rip_input( ) to relay all other messages to the appropriate sockets of type SOCK_RAW in the PF_INET domain, if any.
This event occurs if the network system receives an ICMP packet which either does not contain the minimum 8 bytes needed for a complete message or is unexpectedly truncated. The data is discarded after incrementing the appropriate counter in the ICMP statistics.This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 0 (input).
icmp_input-badsum: corrupted message receivedThis event indicates that the network stack is unable to process a received ICMP message. The icmp_input( ) routine handles data contained in IP packets with a protocol value of 1, generating replies for all supported request messages (types 8, 13, and 17). After completing any necessary processing, the input routine calls rip_input( ) to relay all other messages to the appropriate sockets of type SOCK_RAW in the PF_INET domain, if any.
This event occurs if the network system receives an ICMP message which does not pass the checksum validation test. The data is discarded after incrementing the appropriate counter in the ICMP statistics.This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 0 (input).
icmp_input-badlen: invalid error message receivedThis event indicates that the network stack is unable to process a received ICMP message. The icmp_input( ) routine handles data contained in IP packets with a protocol value of 1, generating replies for all supported request messages (types 8, 13, and 17). This event indicates that the network system received an ICMP error message which is either too short or inconsistent with the values included in the encapsulated IP header. The data is discarded after incrementing the appropriate counter in the ICMP statistics.This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 0 (input).
ipintr-shortmsg: invalid packet received - insufficient headerThis event indicates that the network system received an IP packet which does not include the minimum 20 bytes needed for a complete header. The data is discarded after incrementing the appropriate counter in the IP statistics.This event is part of the core net event class. No additional filters are available.
ipintr-badvers: invalid packet received - unknown version numberThis event indicates that the network system received an IP packet with an unsupported version number. The current network stack only supports IP version 4 packets. The data is discarded after incrementing the appropriate counter in the IP statistics.This event is part of the core net event class. No additional filters are available.
ipintr-badhlen: invalid packet received - incorrect or truncated IP headerThis event indicates that the network system received an IP packet which includes a reported header length less than the minimum 20 bytes or whose header is unexpectedly truncated. The data is discarded after incrementing the appropriate counter in the IP statistics.This event is part of the core net event class. No additional filters are available.
ipintr-badsum: invalid packet received - corrupted data
ipintr-badlen: invalid packet received - incorrect total lengthThis event indicates that the network system received an IP message with a reported total length less than the reported length of the IP header. The data is discarded after incrementing the appropriate counter in the IP statistics.This event is part of the core net event class. No additional filters are available.
ipintr-badmblk: inconsistent network buffersThis event indicates that the network stack received an IP message with a reported total length greater than the amount of data actually present in the network buffers. The data is discarded after incrementing the appropriate counter in the IP statistics. This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 0 (input).
ip_dooptions-badopt: invalid packet received - bad options in header
ip_forward-badaddr: unable to forward packetThis event indicates that the network stack received an IP packet which required forwarding to an invalid next-hop address. Packets cannot be forwarded to multicast (class D) or experimental (class E) addresses, or to any address with network numbers 127 (loopback) or 0. This event also occurs with attempts to forward a broadcast packet to any destination. For hosts acting as routers, forwarding is attempted for all incoming packets with unrecognized destination addresses. It may also occur because of a source routing option in the IP header. This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 1(output).
ip_output-badaddr: unreachable destination addressThis event occurs when the network stack is processing an outgoing IP packet. The ip_output( ) routine handles both packet forwarding (if enabled) and locally generated packets. It performs any necessary route lookups and fragmentation, then passes the resulting M_BLK chain to the interface-specific transmit routine.
This event indicates that the network stack is processing an IP packet for delivery to an unreachable destination. It typically occurs when no valid route to the destination exists, but can also happen if routing was disabled with the MSG_DONTROUTE send flag or the SO_DONTROUTE socket option and the destination is not directly reachable. This event is part of the core net event class. Additional filtering based on the IP address is available with type value of 1(destination) and direction of 1(output).
ip_output-badaddrtype: unsupported destination addressThis event occurs when the network stack is processing an outgoing IP packet. The ip_output( ) routine handles both packet forwarding (if enabled) and locally generated packets. It performs any necessary route lookups and fragmentation, then passes the resulting M_BLK chain to the interface-specific transmit routine.
This event indicates that the network stack is processing an IP packet with a destination address that cannot be handled by the selected endpoint. It usually occurs when attempting to use a multicast or broadcast address if the interface does not provide that capability. Attempts to send to a broadcast address will also fail if that option is not supported for the particular socket. The second case occurs for TCP sockets, or for UDP sockets if the SO_BROADCAST option is not set. Raw sockets always allow IP broadcasts. This event is part of the core net event class. Additional filtering based on the IP address is available with type value of 1(destination) and direction of 1(output). The broadcast events also provide filtering with an IP address of type 0 (source).
ip_output-badsize: unsupported message sizeThis event occurs when the network stack is processing an outgoing IP packet. The ip_output( ) routine handles both packet forwarding (if enabled) and locally generated packets. It performs any necessary route lookups and fragmentation, then passes the resulting M_BLK chain to the interface-specific transmit routine.
This event indicates that the network stack is processing an outgoing IP packet which exceeds the MTU size of the selected interface but can not be fragmented. This event often indicates that the DF bit is set in the IP header, but also occurs when attempting to send a large broadcast message. Those broadcasts are not permitted by default because the required fragmentation decreases the chance for successful delivery. This behavior can only be changed for the entire protocol by setting the IP_DO_LARGE_BCAST flag. It can't be modified for individual sockets or interfaces. This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 1(output).
ip_output-shortmsg: invalid fragment sizeThis event occurs when the network stack is processing an outgoing IP packet. The ip_output( ) routine handles both packet forwarding (if enabled) and locally generated packets. It performs any necessary route lookups and fragmentation, then passes the resulting M_BLK chain to the interface-specific transmit routine.
This event indicates that the network stack is processing an IP packet which requires fragmentation, but the MTU size for the interface selected to transmit the packets will produce fragments of less than eight bytes in length (excluding the packet header). Fragments of that size would prevent correct reassembly, so the message transmission fails. This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 1(output).
rtalloc1-miss: no such route entryThis event indicates that an expected route entry does not exist. It usually occurs following a failed route lookup by the IP layer, but can also happen if the attempt to create a cloned route (a feature used by ARP) fails. This event is part of the auxiliary net event class. No additional filters are available.
rtredirect-error: invalid route change requestThis event indicates that the network stack received an invalid ICMP redirect message. It occurs in one of three situations: either the message was not sent by the current router to the destination, the new router is not directly reachable, or the new route would replace the direct route to a local interface (i.e. the RTF_GATEWAY flag is not set for the existing route). The redirect message is ignored and the routing table is left unchanged. This event is part of the auxiliary net event class. No additional filters are available.
rtrequest-error: invalid routing table requestThis event indicates an error attempting to change the contents of the routing table. All of the API calls which add or delete routes ultimately use the rtrequest( ) routine. Route deletion fails if no entry exists for the given destination. Route creation fails if the destination is unreachable or a route to the destination already exists, or if insufficient memory is available to add the route entry.
Following this event, the rtrequest( ) routine returns an error to the calling routine. The routing table is left unchanged. This event is part of the auxiliary net event class. No additional filters are available.
route_output-error: invalid route message sent
tcp_input-badsum: corrupted segment received
tcp_input-badhlen: invalid segment received - incorrect header sizeThis event indicates that the network system received a TCP segment which includes a reported header length that is less than the minimum 20 bytes or greated than the size of the entire segment. The data is discarded after incrementing the appropriate counter in the TCP statistics.
This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_ctloutput-nopcb: invalid socketThis event occurs when the network stack is processing a control operation requested using a socket of type SOCK_STREAM in the PF_INET domain. The tcp_ctloutput( ) routine provides a switchboard for handling any options available for the TCP or IP protocols through the setsockopt( ) and getsockopt( ) routines.
This event indicates an attempt to set or retrieve a socket option using a socket which is not associated with a protocol control block. Each TCP socket is assigned that structure when created and it is kept until the connection is closed. The setsockopt( ) or getsockopt( ) call returns ERROR with an error number setting of ECONNRESET if the control block is missing. This event is part of the auxiliary net event class. No additional filters are available.
tcp_attach-nopcbmem: unable to register TCP socketThis event occurs during socket creation. It indicates a failure to attach the TCP protocol to a socket because of insufficient memory to allocate a new protocol control structure. This event can occur when creating a socket locally with the socket( ) call or when creating a socket in response to a connection request from a remote peer. Following this event, the (incomplete) socket is destroyed. This event is part of the auxiliary net event class. No additional filters are available.
sosend-error: unable to transmit application dataThis event indicates that the network stack is unable to fulfill a send request for a socket. It could be caused by invalid parameters to the API routine, or by the socket state, or by an internal error at the protocol level. This event is part of the core net event class. No additional filters are available.
soreceive-error: unable to receive application dataThis event indicates that the network stack is unable to complete a socket receive request. It could be caused by invalid parameters to the API routine, or by the socket state, or by an internal error at the protocol level. This event is part of the core net event class. No additional filters are available.
This priority level contains events which indicate correctable transient errors. Most of these events occur in response to invalid user commands, such as an attempt to bind a socket endpoint to an invalid address. The operations are not completed, but the ability of the network processing to send and receive data for other applications is not necessarily affected.
ifioctl-badifname: failed control operation - unknown interfaceThis event occurs when the network stack is processing a request from the generic I/O control interface. The ioctl.h include file defines the available operations. The request parameter included in this event contains the resulting four byte value. The first two arguments to the _IOxx macros in the include file provide the values for the final two bytes, which indicate the particular request. The third byte indicates whether it applies to sockets (`s': 0x73), routes (`r': 0x72), or interfaces (`i': 0x69). The fourth byte (second argument) is a unique offset within each category.
The ifioctl( ) routine handles some interface-specific operations (request values with the format 0xaabb69dd) and performs preliminary processing for the remainder. . This event indicates that the network stack is unable to assign (or retrieve) an interface setting because the specified interface name does not match any configured device. This event is part of the auxiliary net event class. No additional filters are available.
ifioctl-noproto: failed control operation - unknown protocolThis event occurs when the network stack is processing a request from the generic I/O control interface. The ioctl.h include file defines the available operations. The request parameter included in this event contains the resulting four byte value. The first two arguments to the _IOxx macros in the include file provide the values for the final two bytes, which indicate the particular request. The third byte indicates whether it applies to sockets (`s': 0x73), routes (`r': 0x72), or interfaces (`i': 0x69). The fourth byte (second argument) is a unique offset within each category.
The ifioctl( ) request handles some interface-specific operations (request values with the format 0xaabb69dd) and performs preliminary processing for the remainder. This event indicates that the network stack is unable to complete an Internet control operation because the socket used is not associated with any protocol. This event is part of the auxiliary net event class. No additional filters are available.
arpioctl-badreq: failed ARP control operation - unknown protocolThis event occurs when the network stack is processing a request from the generic I/O control interface. The ioctl.h include file defines the available operations.
The arpioctl( ) routine handles the interface-specific SIOCSARP, SIOCGARP and SIOCDARP operations which provide applications with direct access to the ARP table. This event indicates that the address family of either the protocol or hardware addresses is not supported. All ARP operations require an address family of AF_INET for the protocol address and AF_UNSPEC for the hardware address. This event is part of the auxiliary net event class. No additional filters are available.
ether_output-afnotsupp: send failed - unknown protocolThis event indicates that the interface between the IP layer and a link layer device received data intended for a destination address in an unsupported protocol family. The outgoing data is discarded. The only valid address families are AF_INET for IP addresses and AF_UNSPEC (which is only used internally) for raw Ethernet frames. The most likely cause for this error is an incorrect entry in the routing table. This event is part of the core net event class. No additional filters are available.
in_control-noifdata: failed control operation - unknown addressThis event occurs when the network stack is processing a request from the generic I/O control interface. The ioctl.h include file defines the available operations. The request parameter included in this event contains the resulting four byte value. The first two arguments to the _IOxx macros in the include file provide the values for the final two bytes, which indicate the particular request. The third byte indicates whether it applies to sockets (`s': 0x73), routes (`r': 0x72), or interfaces (`i': 0x69). The fourth byte (second argument) is a unique offset within each category.
The in_control( ) routine handles most interface-specific operations (request values with the format 0xaabb69dd). This event indicates the network stack is unable to complete the request because the expected address information is missing. It occurs if no address is assigned to the given interface or when attempting to delete an IP address that is not currently assigned to the interface. The corresponding ioctl( ) call returns ERROR with an error number setting of EADDRNOTAVAIL. This event is part of the auxiliary net event class. No additional filters are available.
in_control-badflags: failed control operation - incorrect interface typeThis event occurs when the network stack is processing a request from the generic I/O control interface. The ioctl.h include file defines the available operations. The request parameter included in this event contains the resulting four byte value. The first two arguments to the _IOxx macros in the include file provide the values for the final two bytes, which indicate the particular request. The third byte indicates whether it applies to sockets (`s': 0x73), routes (`r': 0x72), or interfaces (`i': 0x69). The fourth byte (second argument) is a unique offset within each category.
The in_control( ) routine handles most interface-specific operations (request values with the format 0xaa2069dd). This event indicates the network stack is unable to complete the request because the address is not valid for the interface. Broadcast addresses are only available for interfaces with the IFF_BROADCAST flag set and destination addresses are only available if the IFF_POINTOPOINT flag is set. The corresponding ioctl( ) call returns ERROR with an error number setting of EINVAL. This event is part of the auxiliary net event class. No additional filters are available.
in_pcbbind-noaddr: unable to name socket - no interfaces availableThis event indicates that the network stack is unable to assign a local address and port number to a socket endpoint because no IP addresses have been assigned to the available interfaces.
The socket name is usually assigned by an explicit call to the bind( ) routine, but may be added automatically when necessary. Implicit binds occur during the listen( ) routine for unbound TCP sockets, during the sendto( ) routine for unconnected UDP sockets, and during the connect( ) routine for unbound sockets of either type. This event is part of the auxiliary net event class. No additional filters are available.
in_pcbbind-badsock: unable to name socket - already boundThis event indicates that the network stack is unable to assign a local address and port number to a socket endpoint because those values are already present. A socket can only be bound once. The current information is unchanged.
The socket name is usually assigned by an explicit call to the bind( ) routine, but may be added automatically when necessary. Implicit binds occur during the listen( ) routine for unbound TCP sockets, during the sendto( ) routine for unconnected UDP sockets, and during the connect( ) routine for unbound sockets of either type. This event is part of the auxiliary net event class. No additional filters are available.
in_pcbbind-badaddrlen: unable to name socket - invalid address lengthThis event indicates that the network stack is unable to assign a local address and port number to a socket endpoint because the buffer containing the given values is not the correct size. That information must be provided in a 16 byte sockaddr_in data structure.
The socket name is usually assigned by an explicit call to the bind( ) routine, but may be added automatically when necessary. Implicit binds occur during the listen( ) routine for unbound TCP sockets, during the sendto( ) routine for unconnected UDP sockets, and during the connect( ) routine for unbound sockets of either type. This event is part of the auxiliary net event class. No additional filters are available.
in_pcbbind-badaddr: unable to name socket - invalid addressThis event indicates that the network stack is unable to assign a local address and port number to a socket endpoint because the given address value is not directly reachable by any of the available interfaces. Unless it is 0 (for wildcard matches) or a multicast address, it must match the IP address or broadcast address (if any) of a local interface.
The socket name is usually assigned by an explicit call to the bind( ) routine, but may be added automatically when necessary. Implicit binds occur during the listen( ) routine for unbound TCP sockets, during the sendto( ) routine for unconnected UDP sockets, and during the connect( ) routine for unbound sockets of either type. This event is part of the auxiliary net event class. No additional filters are available.
in_pcbbind-badport: unable to name socket - duplicate portThis event indicates that the network stack is unable to assign a local address and port number to a socket endpoint because the given port value is in exclusive use by another socket with a matching local address. Multiple sockets can always use the same port number if the SO_REUSEPORT option is set for all matching sockets. The SO_REUSEADDR option has the same meaning as SO_REUSEPORT for multicast addresses. It also allows a pair of sockets which both use that option to share the same local port if one of them is bound to the wildcard address, but has no effect in any other case.
The socket name is usually assigned by an explicit call to the bind( ) routine, but may be added automatically when necessary. Implicit binds occur during the listen( ) routine for unbound TCP sockets, during the sendto( ) routine for unconnected UDP sockets, and during the connect( ) routine for unbound sockets of either type. This event is part of the auxiliary net event class. No additional filters are available.
in_pcbladdr-badaddr: unable to connect - unreachable destination addressThis event indicates that the network stack is unable to verify the given remote address. That validation generally occurs when attempting to assign a local address and port number to a socket endpoint using the remote endpoint values during an implicit bind.The local address is assigned based on that information during the connect( ) routine for unbound TCP and UDP sockets and during the sendto( ) routine for unconnected UDP sockets. The same routine also validates the remote address when a connection request arrives on a TCP socket in the LISTEN state, but the local address is already chosen in that case.
If the remote address is valid, this event indicates that a required local address was unavailable because no IP addresses have been assigned to any local interface. This event is part of the auxiliary net event class. No additional filters are available.
in_pcbladdr-badif: unable to connect - unavailable multicast interfaceThis event indicates that the network stack is unable to use the specified outgoing interface. The destination is a multicast address but the outgoing interface for all multicast packets (set with the IP_MULTICAST_IF socket option) is no longer available. This event occurs after assigning a local address and port number to a socket endpoint using valid remote endpoint values during an implicit bind.The local address is assigned based on that information during the connect( ) routine for unbound TCP and UDP sockets and during the sendto( ) routine for unconnected UDP sockets. This event is part of the auxiliary net event class. No additional filters are available.
in_pcbconnect-badaddr: unable to connect - duplicate address pairThis event indicates that the network stack is unable to use the socket for connections because the current local and remote endpoints match the values for an existing connection. Multiple connections between a particular local address and port number and remote address and port number are not permitted.
Connections are usually established explicitly for TCP and UDP sockets by the connect( ) call, but temporary connections are also created by the sendto( ) call for unconnected UDP sockets. This event is part of the auxiliary net event class. No additional filters are available.
ip_mrouter_cmd-notinit: incomplete multicast routing initializationThis event indicates that the network stack is unable to process a control operation related to multicast routing support. The setsockopt( ) routine provides access to these commands through raw sockets with a level argument of IPPROTO_IP. It is typically called by an implementation of the DVMRP routing protocol. The ip_mrouter_cmd( ) routine is the default handler for all related options, which have values beginning at 100 (DVMRP_INIT).
This event occurs because the hook routine which forwards multicast packets is not available. The corresponding setsockopt( ) call returns ERROR with an error number setting of EACCES. The DVMRP_INIT operation installs the ip_mforward( ) routine for that purpose. Custom handling is available by assigning an alternate function to the _mCastRouteFwdHook global variable.
This event is part of the auxiliary net event class. No additional filters are available.
ip_mrouter_cmd-badcmd: unknown multicast router optionThis event indicates that the network stack is unable to process a control operation related to multicast routing support. The setsockopt( ) routine provides access to these commands through raw sockets with a <level> argument of IPPROTO_IP. It is typically called by an implementation of the DVMRP routing protocol. The ip_mrouter_cmd( ) routine is the default handler for all related options, which have values beginning at 100 (DVMRP_INIT).
This event occurs because the command code is not recognized. The corresponding setsockopt( ) call returns ERROR with an error number setting of EOPNOTSUPP. Custom handling is available by assigning an alternate function to the _mCastRouteCmdHook global variable.
This event is part of the auxiliary net event class. No additional filters are available.
add_vif-badindex: invalid interface for multicast routing - table size exceededThis event indicates that the network stack is unable to complete the DVMRP_ADD_VIF command which registers an interface for multicast routing. The setsockopt( ) routine provides access to that command through raw sockets with a <level> argument of IPPROTO_IP. It is typically called by an implementation of the DVMRP routing protocol. The <optval> argument for this option provides a data structure which includes a unique index for each interface. This event occurs when that index value exceeds the maximum interface table size. The corresponding setsockopt( ) call returns ERROR with an error number setting of EINVAL. This event is part of the auxiliary net event class. No additional filters are available.
add_vif-badentry: invalid interface for multicast routing - table entry in useThis event indicates that the network stack is unable to complete the DVMRP_ADD_VIF command which registers an interface for multicast routing. The setsockopt( ) routine provides access to that command through raw sockets with a level argument of IPPROTO_IP. It is typically called by an implementation of the DVMRP routing protocol. The optval argument for this option provides a data structure which includes a unique index for each interface. This event occurs when that index value accesses a table entry which is already assigned to a local interface. The corresponding setsockopt( ) call returns ERROR with an error number setting of EADDRINUSE. This event is part of the auxiliary net event class. No additional filters are available.
add_vif-badaddr: invalid interface for multicast routing - no such addressThis event indicates that the network stack is unable to complete the DVMRP_ADD_VIF command which registers an interface for multicast routing. The setsockopt( ) routine provides access to that command through raw sockets with a level argument of IPPROTO_IP. It is typically called by an implementation of the DVMRP routing protocol. The optval argument for this option provides a data structure which includes a local IP address for the interface. This event occurs when that address is not assigned to any device. The corresponding setsockopt( ) call returns ERROR with an error number setting of EADDRNOTAVAIL. This event is part of the auxiliary net event class. No additional filters are available.
add_vif-badif: invalid interface for multicast routing - not multicastThis event indicates that the network stack is unable to complete the DVMRP_ADD_VIF command which registers an interface for multicast routing. The setsockopt( ) routine provides access to that command through raw sockets with a level argument of IPPROTO_IP. It is typically called by an implementation of the DVMRP routing protocol. The optval argument for this option provides a data structure which includes a flag (VIFF_TUNNEL: 0x1) allowing support for that protocol over non-multicast routers. This event occurs when that flag is not set and the local interface does not support multicast. The corresponding setsockopt( ) call returns ERROR with an error number setting of EOPNOTSUPP. This event is part of the auxiliary net event class. No additional filters are available.
del_vif-badindex: unknown multicast routing interface - table size exceededThis event indicates that the network stack is unable to complete the DVMRP_DEL_VIF command which removes an interface from the multicast routing protocol. The setsockopt( ) routine provides access to that command through raw sockets with a level argument of IPPROTO_IP. It is typically called by an implementation of the DVMRP routing protocol. The optval argument for this option provides a data structure which includes a unique index for each interface. This event occurs when that index value exceeds the maximum index currently in use. The corresponding setsockopt( ) call returns ERROR with an error number setting of EINVAL. This event is part of the auxiliary net event class. No additional filters are available.
del_vif-badentry: invalid interface for multicast routing - table entry unusedThis event indicates that the network stack is unable to complete the DVMRP_DEL_VIF command which removes an interface from the multicast routing protocol. The setsockopt( ) routine provides access to that command through raw sockets with a level argument of IPPROTO_IP. It is typically called by an implementation of the DVMRP routing protocol. The optval argument for this option provides a data structure which includes a unique index for each interface. This event occurs when that index value accesses a table entry which is not assigned to any local interface. The corresponding setsockopt( ) call returns ERROR with an error number setting of EADDRNOTAVAIL. This event is part of the auxiliary net event class. No additional filters are available.
ip_ctloutput-badcmd: unknown IP optionThis event occurs when the network stack is processing a control operation related to the IP protocol. The setsockopt( ) and getsockopt( ) routines provide access to these settings using UDP, TCP, or raw sockets with a level argument of IPPROTO_IP.
The ip_ctloutput( ) routine is the default handler for all options with that level. Valid options have values from 1 (IP_OPTIONS) to 13 (IP_DROP_MEMBERSHIP), except for 2 (IP_HDRINCL), which is handled separately. This event indicates that the option value is not supported. The corresponding setsockopt( ) or getsockopt( ) call returns ERROR with an error number setting of ENOPROTOOPT. This event is part of the auxiliary net event class. No additional filters are available.
ip_output-result: sending IP data over local interfaceThis event occurs when the network stack is processing an outgoing IP packet. The ip_output( ) routine handles both packet forwarding (if enabled) and locally generated packets. It performs any necessary route lookups and fragmentation, then passes the resulting M_BLK chain to the interface-specific transmit routine.
This event indicates that the network stack has completed the processing of an outgoing IP packet. This event occurs following the transfer of the packet to the driver (if the processing was successful) or if multicast routing failed. It is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 1(output).
rip_ctloutput-badlevel: unsupported protocol for raw socket optionsThis event occurs when the network stack is processing a control operation requested using a socket of type SOCK_RAW in the PF_INET domain. The rip_ctloutput( ) routine provides a switchboard for three classes of options available through the setsockopt( ) and getsockopt( ) routines with a <level> argument of IPPROTO_IP.
This event indicates that the protocol level is not supported. The corresponding call returns ERROR with an error number setting of EINVAL. This event is part of the auxiliary net event class. No additional filters are available.
rip_ctloutput-badmem: missing flag setting for raw socket optionThis event occurs when the network stack is processing a control operation requested using a socket of type SOCK_RAW in the PF_INET domain. The rip_ctloutput( ) routine provides a switchboard for three classes of options available through the setsockopt( ) and getsockopt( ) routines with a <level> argument of IPPROTO_IP.
The IP_HDRINCL option is unique to raw sockets and is handled directly. It indicates whether data sent using the socket includes an IP header. This event occurs if the option value for that setting does not contain the expected integer. The corresponding call returns ERROR with an error number setting of EINVAL. This event is part of the auxiliary net event class. No additional filters are available.
rip_input-nosock: discarding IP packet - unsupported typeThis event indicates that the network stack is unable to process a received IP packet. The rip_input( ) routine relays IP packets to the appropriate sockets of type SOCK_RAW in the PF_INET domain based on the protocol type and source and destination addresses in the IP header. It selects from incoming messages with unknown IP protocol types or ICMP message types, as well as known ICMP messages which are not reflected and all IGMP messages. The attach( ), bind( ) and connect( ) routines will limit a raw socket to specific values for the protocol and address fields. Otherwise, a raw socket will receive all available packets.
This event occurs because no raw socket is available to handle the received IP packet. The data is discarded after incrementing the appropriate counter in the IP statistics. This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 0 (input).
rip_usrreq-fail: error handling raw socket operationThis event indicates that an error occurred during a socket operation for an endpoint with type SOCK_RAW in the PF_INET domain. The rip_usrreq( ) routine handles all generic socket library routines for these raw sockets except for the setsockopt and getsockopt commands. The corresponding socket call usually sets the error number value to the result of the specific operation and returns ERROR. In some cases (such as a partial send operation which returns EWOULDBLOCK) the socket operation ignores the error result and returns the amount of data transferred. This event is part of the core net event class. No additional filters are available.
raw_usrreq-fail: error handling routing socket operationThis event indicates that an error occurred during a socket operation for an endpoint with type SOCK_RAW in the PF_ROUTE domain. The raw_usrreq( ) routine performs common functions to support the generic socket library routines for routing sockets. Those sockets do not support the setsockopt and getsockopt commands, or the ioctl interface (which issues a PRU_CONTROL request). The corresponding socket call sets the error number value to the result of the specific operation and returns ERROR. This event is part of the core net event class. No additional filters are available.
rtioctl-badreq: failed route control operation - unknown requestThis event occurs when the network stack is processing a request from the generic I/O control interface. The ioctl.h include file defines the available operations. The request parameter included in this event contains the resulting four byte value. The first two arguments to the _IOxx macros in the include file provide the values for the final two bytes, which indicate the particular request. The third byte indicates whether it applies to sockets (`s': 0x73), routes (`r': 0x72), or interfaces (`i': 0x69). The fourth byte (second argument) is a unique offset within each category.
The initial two bytes of the request parameter are only used internally. The first byte indicates whether data is read (_IOR: 0x40), written (_IOW: 0x80), or both (_IOWR: 0xc0). The second byte contains the size of the required data buffer, based on the variable type listed in the third argument of the _IOxx macro.
The rtioctl( ) routine handles the routing control operations (request values with the format 0x803472dd). This event indicates the network stack is unable to complete the request because the operation is not recognized. The only supported routing control operations are SIOCADDRT and SIOCDELRT. This event is part of the auxiliary net event class. No additional filters are available.
tcp_usrreq-badmem: unsupported control information in TCP operationThis event indicates that an error occurred during a socket operation for an endpoint with type SOCK_STREAM in the PF_INET domain. The tcp_usrreq( ) routine handles all generic socket library routines for these sockets except for the setsockopt and getsockopt commands. Although the corresponding prototype can accept an M_BLK containing control information, it is not valid for a TCP socket. The sendmsg command is the only possible source for that unsupported information. That socket call will return ERROR with an error number setting of EINVAL. This event is part of the auxiliary net event class. No additional filters are available.
tcp_usrreq-nopcb: invalid socketThis event indicates an attempt to perform a socket operation for an endpoint with type SOCK_STREAM in the PF_INET domain which is not associated with a protocol control structure. The tcp_usrreq( ) routine handles all generic socket library routines for these sockets except for the setsockopt and getsockopt commands. Each TCP socket is assigned a protocol control block when created which is kept until the connection is closed. Except for the PRU_ATTACH operation performed when the socket is created, the command is ignored if this structure is missing.The corresponding socket call will return ERROR with an error number setting of EINVAL. This event is part of the auxiliary net event class. No additional filters are available.
tcp_usrreq-fail: error handling routing socket operationThis event indicates that an error occurred during a socket operation for an endpoint with type SOCK_STREAM in the PF_INET domain. The tcp_usrreq( ) routine handles all generic socket library routines for TCP sockets except for the setsockopt and getsockopt commands. The corresponding socket call usually sets the error number value to the result of the specific operation and returns ERROR. In some cases (such as a partial send operation which returns EWOULDBLOCK) the socket operation ignores the error result and returns the amount of data transferred. This event is part of the auxiliary net event class. No additional filters are available.
udp_output-error: unable to transmit data at UDP layerThis event indicates a data transmission error for an endpoint with type SOCK_DGRAM in the PF_INET domain. Normally, the socket is temporarily connected to the destination address, if specified. This event occurs if the socket is unexpectedly connected already. It also occurs if the network stack is unable to obtain 28 bytes of storage for the (minimum) UDP and IP headers. The corresponding socket routine will return ERROR with an error number setting of ENOBUFS or EISCONN. This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1 (source or destination) and direction of 1 (output).
udp_usrreq-nopcb: invalid socketThis event indicates an attempt to perform a socket operation for an endpoint with type SOCK_DGRAM in the PF_INET domain which is not associated with a protocol control structure. The udp_usrreq( ) routine handles all generic socket library routines for these sockets except for the setsockopt and getsockopt commands. Each UDP socket is assigned a protocol control block when created which is kept until the socket is closed. Except for the PRU_ATTACH operation performed when the socket is created, the command is ignored if this structure is missing.The corresponding socket call will return ERROR with an error number setting of EINVAL. This event is part of the auxiliary net event class. No additional filters are available.
socreate-nosocktype: unknown socket specifiedThis event indicates an error attempting to create a socket. All socket types are listed in a switchboard which accesses the necessary protocol-specific operations. The type parameter (and protocol parameter if non-zero) to the socket( ) routine provide the keys used to search the switchboard specified by the domain parameter.
This event occurs if the specified domain does not support the socket described by the type and protocol arguments. The socket( ) call will return ERROR with an error number setting of EPROTONOSUPPORT. In the PF_INET domain, the only valid type values are SOCK_STREAM (1), SOCK_DGRAM (2), and SOCK_RAW (3). The optional protocol values for stream and datagram sockets are IPPROTO_TCP (6) and IPPROTO_UDP (17). Raw sockets support protocol values of IPPROTO_ICMP (1), IPPROTO_IGMP(2) and IPPROTO_RAW (255). This event is part of the auxiliary net event class. No additional filters are available.
soconnect-denied: socket connection not allowedThis event indicates an error attempting to establish a connection to a remote socket. It occurs when the socket has already been marked to accept connections by the listen( ) routine, so it cannot initiate them. The corresponding connect( ) call will return ERROR with an error number setting of EOPNOTSUPP. This event is part of the auxiliary net event class. No additional filters are available.
sodisconnect-result: socket disconnection statusThis event provides the result when attempting to close a connection to a remote socket. It generally occurs when closing the socket, but could occur during the processing of a connect( ) call if a connection already exists. A result of 0 indicates that the connection was closed successfully and processing will continue. A non-zero result indicates an error closing the connection. In that case, a close( ) call will return the error value, but a connect( ) call will return ERROR with an error number setting of EISCONN. This event is part of the auxiliary net event class. No additional filters are available.
This priority level contains events which indicate unusual situations that could cause later errors. Many of these events occur in response to invalid or unexpected input from a remote host. The ability of the network processing to send and receive data for other addresses is generally not affected.
arp_rtrequest-badgate: incorrect hardware address for ARP entryThis event indicates an error attempting to change the contents of the routing table. Every address assigned to an interface is associated with a route to the corresponding network. It is also associated with an optional routine to support storing link-level entries in the routing table. The arp_rtrequest( ) routine maintains that information for all Ethernet devices attached to the IP network protocol. The route entries which it creates contain the protocol address in the destination field and the hardware address in the gateway field.
This event indicates that the gateway field does not contain a valid hardware address. Although no error is returned, the link-level information is not created, which might prevent correct network communication.
This event is part of the auxiliary net event class. No additional filters are available.
in_arpinput-etherbcast: incorrect hardware address in ARP replyThis event indicates an invalid ARP response. That protocol provides link-level hardware addresses associated with network protocol addresses. The in_arpinput( ) routine handles all ARP messages for translating between IP and Ethernet addresses. This event indicates that the Ethernet broadcast address was supplied instead of the expected unique value. No data will be sent to the corresponding IP address until a valid response is received. This event is part of the auxiliary net event class. No additional filters are available.
in_arpinput-dupaddr: incorrect protocol address in ARP replyThis event indicates an invalid ARP response. That protocol provides link-level hardware addresses associated with network protocol addresses. The in_arpinput( ) routine handles all ARP messages for translating between IP and Ethernet addresses. This event indicates that the supplied IP address matches a value in use by the receiving host. IP addresses must be unique. Attempts at network communication to or from that address will behave unpredictably until the duplication is eliminated. This event is part of the auxiliary net event class. No additional filters are available.
in_arpinput-newetheraddr: changed hardware address in ARP replyThis event indicates an unusual ARP response. That protocol provides link-level hardware addresses associated with network protocol addresses. The in_arpinput( ) routine handles all ARP messages for translating between IP and Ethernet addresses. This event indicates that the supplied hardware address differs from the expected value stored in an existing ARP entry. It can occur during normal usage if the sending host dynamically replaced the link-level hardware device, but might also indicate an error. If the responding host has not changed the link-level device, attempted communication to or from that IP address will behave unpredictably while the incorrect response occurs. This event is part of the auxiliary net event class. No additional filters are available.
igmp_input-badaddr: incorrect address in IGMP messageThis event indicates that the network system received an invalid IGMP packet. All valid IGMP messages are sent to an IP multicast address. IGMP queries must be sent to the all-hosts multicast address (224.0.0.1). IGMP report messages may be sent to any multicast address, which is also included within the IGMP message. This event indicates that one of the address fields was incorrect. Either the destination IP address is not a multicast address or (for membership reports) that address does not match the group address in the IGMP message. In either case, the data is discarded after incrementing the appropriate counter in the IGMP statistics.
This event is part of the core net event class. Additional filtering based on the IP address is available with a type value of 1(destination) and direction of 0 (input).
in_losing-start: excessive retransmissions - selecting new routeThis event indicates that the transport protocol did not receive an expected acknowledgement. TCP will retransmit a segment 12 times without response before it gives up and drops the connection. Starting with the fourth expiration of the retransmission timer, the in_losing( ) routine discards any cached route so that the next output attempt will search for a new route which might reach the destination. This event indicates the start of that process. The cached route is removed from the routing table if it was created dynamically by an ICMP redirect so that the default gateway (if any) can be tried again. Otherwise, the routing table is unchanged.
This event is part of the core net event class. No additional filters are available.
ipReAssemble-fragdrop: discarding IP fragmentThis event indicates that IP is ignoring a newly received packet fragment. It usually indicates that the received fragment is completely overlapped by a fragment which arrived earlier, but can also indicate insufficient memory to create the required reassembly queue. A separate queue is created for each set of fragments, which are uniquely identified by the combination of source address, destination address, identification field and protocol field.
Dropping fragments can result in a significant performance penalty at the transport layer. If reassembly is not possible, the entire UDP datagram or TCP segment must be retransmitted.
This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 0 (input).
rip_input-fullbuf: discarding IP packet - insufficient spaceThis event indicates that the network stack is unable to process a received IP packet. The rip_input( ) routine relays IP packets to the appropriate sockets of type SOCK_RAW in the PF_INET domain based on the protocol type and source and destination addresses. It selects from any incoming messages with unknown protocol types or ICMP message types, as well as known ICMP messages which are not reflected and all IGMP messages. A raw socket can be limited to specific protocol and address values, but will receive all available packets by default.This event occurs when the attempt to copy the packet into the receive buffer of a matching socket fails. Either the socket's receive buffer is too full to hold the packet or the system cannot allocate the necessary M_BLK. The packet is discarded silently. This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 0 (input).
raw_input-fullbuf: discarding routing message - insufficient spaceThis event indicates that the network stack is unable to process a routing message. The raw_input( ) routine relays these messages to the appropriate sockets of type SOCK_RAW in the PF_ROUTE domain. The messages can be restricted to routes for a specific address family (such as AF_INET for IP destinations) by including the family value in the protocol argument when creating the socket. Otherwise, the routing socket receives all messages.
This event occurs when the attempt to copy the routing message into the receive buffer of a matching socket fails. Either the socket's receive buffer is too full to hold the packet or the system cannot allocate the necessary M_BLK. The packet is discarded silently. This event is part of the core net event class. No additional filters are available.
tcp_input-nopcb: discarding TCP segment - unavailable socketThis event indicates that the network stack is unable to process a received TCP segment. The tcp_input( ) routine relays incoming data to the appropriate socket of type SOCK_STREAM in the PF_INET domain. The destination socket is associated with a protocol control block containing matching local and remote addresses and port numbers. That socket name information is assigned explicitly by the bind( ) and connect( ) routines or added automatically. The connect( ) and listen( ) routines both assign the (remote) address information for the peer socket name and will also assign a local name for unbound TCP sockets. This event occurs because no matching socket is available. The received data is discarded. If no socket exists or a socket is closing, the receiving host sends a TCP reset in response. No reply is sent if a valid socket exists in a CLOSED state, which indicates that the connect( ) or listen( ) routines have not yet been called. This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-badsync: resetting TCP connection - invalid synchronize requestThis event indicates that the network stack is unable to process a received TCP segment. The tcp_input( ) routine relays incoming data to the appropriate socket of type SOCK_STREAM in the PF_INET domain. The destination socket is associated with a protocol control block containing matching local and remote addresses and port numbers. That socket name information is assigned explicitly by the bind( ) and connect( ) routines or added automatically. The connect( ) and listen( ) routines both assign the (remote) address information for the peer socket name and will also assign a local name for unbound TCP sockets.
This event occurs when an incoming segment unexpectedly sets the SYN flag in the TCP header. That synchronize request may only be sent once when establishing a connection. Subsequent occurrences indicate an error. Any received data is discarded and the receiving host sends a TCP reset in response (if possible). Any current or future send or receive calls using the matching socket will return ERROR with error number settings of EPIPE and ECONNRESET respectively. This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-rexmt: TCP segment lost - adjusting TCP performanceThis event indicates that the network stack is performing a congestion control algorithm. This feature attempts to adjust the protocol settings to optimize throughput on congested networks. A series of duplicate acknowledgement messages (which contain no data) triggers the adjustments. The global variable tcprexmtthresh determines the precise behavior. When that threshold is reached, the fast retransmit portion of the congestion avoidance algorithm executes. The lost segment is retransmitted (even though the related timer has not expired) and the congestion window and slow start threshold are reset. Subsequent duplicate ACK messages, if any, trigger the fast recovery processing, which increases the congestion window while sending the next segments in the sequence. That window will be restored to the initial value once data is successfully received. This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 1 (output).
udp_input-shorthdr: invalid datagram received - insufficient headerThis event indicates that the network stack is unable to process a received UDP datagram. The udp_input( ) routine relays incoming data to the appropriate sockets of type SOCK_DGRAM in the PF_INET domain. This event occurs because the M_BLK chain containing the data does not include the minimum 28 bytes needed for the UDP and IP headers. The data is discarded after incrementing the appropriate counter in the UDP statistics.This event is part of the core net event class. No additional filters are available.
udp_input-shortpkt: invalid datagram received - insufficient dataThis event indicates that the network stack is unable to process a received UDP datagram. The udp_input( ) routine relays incoming data to the appropriate sockets of type SOCK_DGRAM in the PF_INET domain. The event occurs because the reported datagram size is longer than the total packet length included in the IP header. The data is discarded after incrementing the appropriate counter in the UDP statistics.This event is part of the core net event class. No additional filters are available.
udp_input-badsum: invalid datagram received - corrupted dataThis event indicates that the network stack is unable to process a received UDP datagram. The udp_input( ) routine relays incoming data to the appropriate sockets of type SOCK_DGRAM in the PF_INET domain. The event occurs because the datagram does not pass the checksum validation test. The data is discarded after incrementing the appropriate counter in the UDP statistics.This event is part of the core net event class. No additional filters are available.
udp_input-fullbuf: discarding UDP datagram - insufficient spaceThis event indicates that the network stack is unable to process a received UDP datagram. The udp_input( ) routine relays incoming data to the appropriate sockets of type SOCK_DGRAM in the PF_INET domain. The destination socket is associated with a protocol control block containing matching local and remote addresses and port numbers. That socket name information can be assigned explicitly by the bind( ) and connect( ) routines, but is often set automatically.
This event occurs when the attempt to copy the UDP payload into the receive buffer of a matching socket fails. Either the socket's receive buffer is too full to hold the data or the system cannot allocate the necessary M_BLK. After incrementing the appropriate counter in the UDP statistics, the data is discarded if no other matching sockets exist. If the destination is a broadcast or multicast IP address, the input processing also increments the appropriate counter and then attempts to deliver the data to the next candidate. This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
udp_input-nopcb: discarding UDP datagram - unavailable socketThis event indicates that the network stack is unable to process a received UDP datagram. The udp_input( ) routine relays incoming data to the appropriate sockets of type SOCK_DGRAM in the PF_INET domain. The destination socket is associated with a protocol control block containing matching local and remote addresses and port numbers. That socket name information can be assigned explicitly by the bind( ) and connect( ) routines, but is often set automatically.
This event occurs because no matching socket is available. The received data is discarded after incrementing the appropriate counter in the UDP statistics. This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
udp_input-noport: discarding UDP datagram - port unreachableThis event indicates that the network stack is unable to process a received UDP datagram. The udp_input( ) routine relays incoming data to the appropriate sockets of type SOCK_DGRAM in the PF_INET domain. The destination socket is associated with a protocol control block containing matching local and remote addresses and port numbers. That socket name information can be assigned explicitly by the bind( ) and connect( ) routines, but is often set automatically.
This event occurs if no matching socket is available for datagrams sent to unicast IP addresses. The receiving host attempts to send an ICMP port unreachable message after incrementing the appropriate counter in the UDP statistics. The received data is discarded. This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
in_arpinput-start: valid ARP packet received
in_arpinput-delayedsend: valid ARP packet received - sending cached dataThis event indicates that the network stack has completed processing an ARP message. The only messages currently supported contain Ethernet hardware addresses and IP network addresses. This event occurs when the hardware address supplied by the ARP message completes the resolution process. A pending IP packet which was held until that address was available is now transferred to the link-level (Ethernet) output function. This event is part of the core net event class. No additional filters are available.
in_arpinput-replysend: valid ARP request received - sending replyThis event indicates that the network stack has received and processed an ARP request message. The only messages currently supported contain Ethernet hardware addresses and IP network addresses. This event occurs when the receiving host is able to supply a hardware address for the requested network address. The host is either the target of the request or contains a proxy ARP entry for the actual target. It constructs an ARP reply which is transferred to the link-level (Ethernet) output function. This event is part of the auxiliary net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 1 (output).
ether_output-send: Ethernet frame sent to driver layerThis event indicates that the network stack has generated an Ethernet frame for transmission by a network interface. The ether_output( ) routine processes IP packets for delivery to BSD drivers by prepending an Ethernet header to the corresponding M_BLK chain. It obtains the destination hardware address from the ARP cache which is accessed through the route entry for the destination IP address.If that information is not present when the IP layer calls the routine, it caches the packet for later delivery and initiates the ARP resolution process. Once the destination IP address is resolved, a second call to this routine from the ARP input processing will complete the header construction and transfer the resulting frame to the driver layer.
This event occurs after adding the Ethernet frame to a network interface's send queue and triggering the driver's start routine to begin transmitting the data.This event is part of the core net event class. No additional filters are available.
ether_input-start: Ethernet frame received from driver layerThis event indicates that the network stack has received an Ethernet frame from a network interface. The ether_input( ) routine processes incoming frames from BSD drivers for delivery to the protocol-specific input routine. The only frames currently supported contain IP or ARP packets (types 0x800 and 0x806) in the Ethernet DIX format.
This event occurs before any processing of the newly arrived frame. If the network interface is currently unavailable (because the IFF_UP flag is not set) the frame will be silently discarded. The frame will also be discarded if the IFF_PROMISC flag is set and the link-level destination address does not match the destination MAC address or a broadcast or multicast address. Those frames would degrade network performance by needlessly triggering the IP forwarding process. This event is part of the core net event class. No additional filters are available.
igmp_input-recv: IGMP message received from IP layerThis event indicates that the network stack has received and validated an IGMP message. The igmp_input( ) routine handles data contained in IP packets with a protocol value of 2. This event occurs after verifying that the M_BLK chain containing the message is not truncated and passes the checksum validation test. It also follows the completion of internal processing for IGMP queries (type 1) and reports (type 2). After this event, the input routine calls rip_input( ) to relay the IGMP message to the appropriate sockets of type SOCK_RAW in the PF_INET domain, if any. This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 0 (input).
igmp_sendreport-send: IGMP message sent to IP layerThis event indicates that the network stack has constructed an IGMP report message for transmission by the IP layer. The igmp_sendreport( ) routine generates that message for a single multicast group when the appropriate timer expires. The timer is set whenever a new group is joined or when an IGMP query arrives.
After this event, the send routine calls ip_output( ) to transmit the IGMP message to the appropriate multicast address. This event is part of the core net event class. Additional filtering based on the IP address is available with a type value of 1(destination) and direction of 1(output).
icmp_input-start: ICMP message received from IP layerThis event indicates that the network stack has received an ICMP message. The icmp_input( ) routine handles data contained in IP packets with a protocol value of 1, generating replies for all supported request messages (types 8, 13, and 17). After completing any necessary processing, the input routine calls rip_input( ) to relay all other messages to the appropriate sockets of type SOCK_RAW in the PF_INET domain, if any.
This event occurs before any processing of the newly arrived message. If the M_BLK chain containing the message is unexpectedly truncated or less than the minimum length, it will be discarded. The message is also discarded if it fails the checksum validation test. This event is part of the core net event class. No additional filters are available.
icmp_reflect-start: ICMP request received - generating replyThis event indicates that the network stack has received a supported ICMP request message. The icmp_input( ) routine calls the icmp_reflect( ) routine to generate replies for echo requests (type 8), timestamp requests (type 13), and address mask requests (type 17).
This event occurs before any processing of the pending ICMP reply. If the intended destination is invalid, such as a multicast or broadcast address, the reply will be silently discarded. This event is part of the core net event class. No additional filters are available.
icmp_send-start: relaying ICMP reply to IP layerThis event indicates that the network stack has received a supported ICMP request message. The icmp_send( ) routine generates the ICMP checksum after the icmp_reflect( ) routine validates the destination address and constructs the IP payload.
After this event, the send routine calls ip_output( ) to transmit the ICMP reply to the appropriate destination address. This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 1(output).
ipintr-recv: transferring IP packet to protocol input routineThis event indicates that the network stack has accepted an IP packet for local processing. The ipintr( ) routine executes at task level in response to an interrupt from a network driver delivering a link-level frame containing IP data. Packets to remote destination addresses are transferred to the IP forwarding routine (if the receiving host is configured as a router) or discarded. Packets to a local destination address or a valid multicast or broadcast address are transferred to the protocol-specific input routine.
This event occurs after completing the checksum validation and any necessary packet reassembly. Following this event, the protocol-specific input routine will begin handling the M_BLK chain containing the packet. This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 0 (input).
ip_forward-result: sending IP packet to next hop destinationThis event indicates that the network stack has received an IP packet intended for a remote destination. The ip_forward( ) routine updates the time-to-live field for an IP packet and retrieves the appropriate route entry for delivery to the destination address. It executes in response to the arrival of an IP packet with an unrecognized unicast destination address if the receiving host is configured as a router. It also handles any IP packets which include a source routing option in the header. If no route to the destination exists or the time-to-live hop count is exceeded, the packet is silently discarded after attempting to send an appropriate ICMP error message. Attempts to generate ICMP messages also occur if the forwarding attempt fails or redirection is desirable. This event provides the results of the ip_output( ) routine for a packet with a known route to the destination. This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 1(output).
tunnel_send-result: transmitting multicast packet with unicast routersThis event indicates that the network stack has received a multicast IP packet intended for a remote destination. The ip_mforward( ) routine performs multicast routing. It uses the tunnel_send( ) routine to encapsulate the original multicast datagram into an appropriate unicast datagram when necessary. The VIFF_TUNNEL flag distinguishes tunnel interfaces from physical interfaces.Tunnels provide support for multicast routing over route segments which contain non-multicast routers. Typically, an implementation of the DVMRP routing protocol assigns that flag and the associated device when creating the (virtual) interface. This event provides the results of the ip_output( ) routine for the transmission attempt through the tunnel. It is part of the core net event class. Additional filtering based on the IP addresses of the tunnel endpoints is available with type values of 0 and 1(source or destination) and direction of 1(output).
phyint_send-result: transmitting multicast packet from multicast interfaceThis event indicates that the network stack has received a multicast IP packet intended for a remote destination. The ip_mforward( ) routine performs multicast routing. It uses the phyint_send( ) routine to transmit the original multicast datagram from a specific (multicast-capable) device. The VIFF_TUNNEL flag distinguishes tunnel interfaces from physical interfaces. Tunnels provide support for multicast routing over route segments which contain non-multicast routers. Typically, an implementation of the DVMRP routing protocol assigns that flag and the associated device when creating the (virtual) interface. This event provides the results of the ip_output( ) routine for the (multicast) transmission attempt through the physical interface. It is part of the core net event class. No additional filters are available.
rip_input-start: transferring IP packet to registered socketsThis event indicates that the network stack has received an IP packet for local delivery. The rip_input( ) routine is the protocol-specific input routine which relays selected IP packets to the appropriate sockets of type SOCK_RAW in the PF_INET domain, based on the protocol type and source and destination addresses in the IP header. The routine handles all incoming packets with unknown IP protocol types or unknown ICMP message types, as well as some (valid) ICMP messages and all IGMP messages. The attach( ), bind( ) and connect( ) routines will limit a raw socket to specific values for the protocol and address fields, but it will receive all available packets by default.
This event occurs after the ipintr( ) routine validates the packet checksum and performs any necessary reassembly, but before searching for a matching socket. If no socket is found, the received data is discarded after incrementing the appropriate counter in the IP statistics. This event is part of the core net event class. No additional filters are available.
rip_output-result: completed transmission of raw IP dataThis event indicates that the network stack is generating an IP packet using a socket endpoint with type SOCK_RAW in the PF_INET domain. All of the BSD socket API send calls (or writes to the associated file descriptor) ultimately produce a PRU_SEND request. The rip_output( ) routine implements that request for raw IP sockets. The routine adds an IP header to the given data, if necessary, and calls the ip_output( ) routine to transmit the resulting IP packet. This event provides the results of the ip_output( ) routine for that transmission attempt. It is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 1(output).
raw_input-start: transferring routing message to registered socketsThis event indicates that the network stack is processing an incoming routing message for a socket endpoint with type SOCK_RAW in the PF_ROUTE domain. These routing messages occur to allow applications, such as implementations of the routing protocols, to monitor the routing table. The messages can be restricted to routes for a specific address family by including the family value in the protocol argument when creating the socket.Otherwise, any routing socket receives all messages.
Most routing messages occur in response to a specific external event, such as creating or deleting a route or a change in status for an interface. An ICMP redirect message and a failed route lookup will also generate appropriate messages.
All routing sockets also receive copies of any outgoing messages, which correspond to direct manipulation of the routing table by local applications. That default behavior can be disabled for individual sockets.
This event occurs before searching for a matching routing socket. If no socket is found, the message is silently discarded. This event is part of the core net event class. No additional filters are available.
route_output-start: accessing routing table for local applicationThis event indicates that the network stack is processing an outgoing routing message from a socket endpoint with type SOCK_RAW in the PF_ROUTE domain. All of the BSD socket API send calls (or writes to the associated file descriptor) ultimately produce a PRU_SEND request. The route_output( ) routine implements that request for raw routing sockets. The routing messages support direct manipulation of the routing table by local applications. The message types (RTM_ADD, RTM_CHANGE, RTM_GET, RTM_LOCK, and RTM_DELETE) correspond to the available operations. By default, copies of these messages are sent to every routing socket, allowing all local applications to monitor any changes. Any routing socket can restrict incoming messages to routes for a specific address family or disable them entirely.
This event occurs before any processing of the outgoing message, so the message type is unavailable. If an error occurs, the intended operation is ignored and the routing table remains unchanged. Copies of the message are sent to all routing sockets whether or not the operation succeeds. This event is part of the core net event class. No additional filters are available.
tcp_input-start: TCP segment received from IP layerThis event indicates that the network stack has received a TCP segment from a remote host. The tcp_input( ) routine is the protocol-specific input routine which the ipintr( ) routine invokes to process each segment for the corresponding socket of type SOCK_STREAM in the PF_INET domain. The processing varies depending on the current state of each TCP socket. The tcp_input( ) routine validates the segment's checksum and handles all state transitions associated with establishing and closing connections. While a connection is active, it copies the payload into the receive buffers of the matching socket, which is selected by the address and port number values, after completing any necessary reassembly. The routine also initiates the transmission of any needed acknowledgements or other responses (such as reset messages if an error occurs) and updates the dynamic congestion control variables.
This event occurs before any processing of the newly arrived segment. If the segment is out of sequence or an error occurs, the data will be discarded after incrementing the appropriate TCP statistic. Other WindView events may occur to provide more specific information in those cases. This event is part of the core net event class. No additional filters are available.
tcp_output-result: completed transmission of TCP segment to remote hostThis event indicates that the network stack is generating a TCP segment for a remote host. Outgoing TCP data often occurs using a socket endpoint with type SOCK_STREAM in the PF_INET domain. All of the BSD socket API send calls (or writes to the associated file descriptor) ultimately produce a PRU_SEND request. The tcp_output( ) routine implements that request for TCP sockets, but also generates segments in response to some incoming TCP segments and timer-related events, as well as the connect( ), disconnect( ), and shutdown( ) routines.
The routine always sends "status" segments (ACK, SYN, RST, and FIN messages) but might not transfer any data to the IP layer. The amount of data sent depends on the current state of the TCP socket and the values of the congestion control variables. The routine adds TCP and IP headers to the new segment and calls the ip_output( ) routine to transmit the resulting IP packet. This event provides the results of the ip_output( ) routine for that transmission attempt. It is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 1(output).
tcp_respond-start: transmit asynchronous TCP segment to remote hostThis event indicates that the network stack is generating a TCP segment for a remote host. Outgoing TCP data often occurs using a socket endpoint with type SOCK_STREAM in the PF_INET domain, but the tcp_respond( ) routine only creates TCP segments because of connection errors or timer expirations. The routine sends either reset messages (triggered by errors processing an incoming segment) or keepalive segments (if that timer expires).
This event occurs before attempting to construct the appropriate TCP segment. If any problem occurs, the segment is silently discarded. This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 1(output).
udp_input-start: UDP datagram received from IP layerThis event indicates that the network stack has received a UDP datagram from a remote host. The udp_input( ) routine is the protocol-specific input routine which the ipintr( ) routine invokes to process each datagram for the associated sockets of type SOCK_DGRAM in the PF_INET domain. The udp_input( ) routine validates the datagram checksum and copies the payload into the receive buffers of any matching sockets, which are selected by the address and port number values.
This event occurs before any processing of the newly arrived datagram. If no matching sockets exist or an error occurs the data will be discarded after incrementing the appropriate UDP statistic. Other WindView events may occur to provide more specific information in those cases. This event is part of the core net event class. No additional filters are available.
udp_output-result: completed transmission of UDP datagram to remote hostThis event indicates that the network stack is generating a UDP datagram for a remote host. Outgoing UDP data occurs using a socket endpoint with type SOCK_DGRAM in the PF_INET domain. All of the BSD socket API send calls (or writes to the associated file descriptor) ultimately produce a PRU_SEND request. The udp_output( ) routine implements that request for UDP sockets. If the send call includes a specific destination, the socket is temporarily connected to that address. Otherwise, it uses the information assigned earlier by the connect( ) routine. The udp_output( ) routine adds UDP and IP headers to the given data and calls the ip_output( ) routine to transmit the resulting IP packet. This event provides the results of the ip_output( ) routine for that transmission attempt. It is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 1(output).
if_slowtimo-ifWdStart: interface timer expired - calling watchdog routineThis event occurs during the network stack's slow timeout update for interfaces. Currently, the if_slowtimo( ) routine executes once per second to update any watchdog timers which are active for specific interfaces. Any interface can schedule a function for periodic execution by storing the function pointer in the if_watchdog field in the interface structure and setting the if_timer field to a nonzero value. This event indicates that an interface watchdog timer has expired. It occurs before calling any installed watchdog routine. The capability to execute an interface-specific watchdog routine is currently not used by any supplied network devices.
This event is part of the auxiliary net event class. No additional filters are available.
ifioctl-start: executing control operation for an interfaceThis event occurs when the network stack is processing a request from the generic I/O control interface. The ioctl.h include file defines the available operations. The request parameter included in this event contains the resulting four byte value. The first two arguments to the _IOxx macros in the include file provide the values for the final two bytes, which indicate the particular request. The third byte indicates whether it applies to sockets (`s': 0x73), routes (`r': 0x72), or interfaces (`i': 0x69). The fourth byte (second argument) is a unique offset within each category.
The ifioctl( ) routine handles some interface-specific operations (request values with the format 0xaabb69dd) and performs preliminary processing for the remainder. This event occurs before any processing of the request. If any error occurs the current settings will remain unchanged and the corresponding ioctl( ) call will return ERROR with an error number setting indicating the problem. This event is part of the auxiliary net event class. No additional filters are available.
arptimer-free: timer expired - removing ARP entryThis event indicates that an ARP entry has expired. The arptimer( ) routine examines all ARP entries at intervals specified by the arpt_prune global variable, which has a default value of 60 seconds. The address resolution process creates dynamic ARP entries with a lifetime determined by the arpt_keep global variable, which has a default value of 20 minutes. Static ARP entries usually never expire.
This event occurs before calling the arptfree( ) routine to remove the expired ARP entry. It is part of the auxiliary net event class. No additional filters are available.
arpioctl-start: executing control operation for ARP tableThis event occurs when the network stack is processing a request from the generic I/O control interface. The ioctl.h include file defines the available operations. The request parameter included in this event contains the resulting four byte value. The first two arguments to the _IOxx macros in the include file provide the values for the final two bytes, which indicate the particular request. The third byte indicates whether it applies to sockets (`s': 0x73), routes (`r': 0x72), or interfaces (`i': 0x69). The fourth byte (second argument) is a unique offset within each category.
The arpioctl( ) routine handles the interface-specific SIOCSARP, SIOCGARP, and SIOCDARP operations (request values with the format 0xaa2469dd) which provide applications with direct access to the ARP table. This event occurs before any processing of the request. If an error occurs, the current ARP table will remain unchanged and the corresponding ioctl( ) call will return ERROR with an error number setting indicating the problem. This event is part of the auxiliary net event class. No additional filters are available.
igmp_fasttimo-start: updating multicast group timersThis event occurs during the network stack's fast timeout update for protocols, which occurs five times per second. That feature allows any protocol which registers a fast timeout function during initialization to perform any operations at that interval.
The igmp_fasttimo( ) routine is the protocol-specific function for IGMP. It updates the timers for all active multicast groups and triggers any pending IGMP report using the igmp_sendreport( ) routine.
This event occurs before examining any multicast groups. The routine exits immediately if no reports are pending. This event is part of the auxiliary net event class. No additional filters are available.
ipintr-newpkt: received IP packet for local destinationThis event indicates that the network stack has accepted an IP packet for local delivery. The ipintr( ) routine executes at task level in response to an interrupt from a network driver delivering a link-level frame containing IP data. Packets to remote destination addresses are transferred to the IP forwarding routine (if the receiving host is configured as a router) or discarded. Packets to a local destination address or a valid multicast or broadcast address are transferred to the protocol-specific input routine.
This event occurs after completing the checksum validation and matching the destination address to a local interface (so the forwarding routine is bypassed). If any necessary reassembly completes successfully, the protocol-specific input routine will begin handling the M_BLK chain containing the packet. This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 0 (input).
ip_freef-start: discard reassembly fragments for an IP packetThis event indicates that the network stack is releasing the IP reassembly fragments for a particular packet. The ip_freef( ) routine removes the fragments for a single packet as part of the slow timeout update for the IP protocol if the associated reassembly timer expires. The ipfragttl global variable has a default value of 60, which provides a maximum lifetime of 30 seconds for each partial packet.
The protocol-specific drain function also uses the ip_freef( ) routine to discard all the fragments on the reassembly list if the network stack requires additional memory.
This event is part of the auxiliary net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 0 (input).
ip_slowtimo-start: updating fragment reassembly timersThis event occurs during the network stack's slow timeout update for protocols, which occurs twice per second. That feature allows any protocol which registers a slow timeout function during initialization to perform any operations at that interval.
The ip_slowtimo( ) routine is the protocol-specific function for IP. It updates the timers for any partial packets on the reassembly list and triggers the ip_freef( ) routine if a timer expires. The ipfragttl global variable has a default value of 60, which provides a maximum lifetime of 30 seconds for each partial packet.
This event occurs before examining any partial packets. The routine exits immediately if no fragments are present. This event is part of the auxiliary net event class. No additional filters are available.
ip_mrouter_cmd-start: executing control operation for multicast routerThis event indicates that the network stack is processing a control operation related to multicast routing support. The setsockopt( ) routine provides access to these commands through raw sockets with a level argument of IPPROTO_IP. It is typically called by an implementation of the DVMRP routing protocol. The ip_mrouter_cmd( ) routine is the default handler for all related options, which have values beginning at 100 (DVMRP_INIT). This event occurs before any processing of the command. If an error occurs, the corresponding setsockopt( ) call returns ERROR with an error number setting indicating the problem.
Custom handling is available by assigning an alternate function to the _mCastRouteCmdHook global variable. If an alternate function is used, this event will not occur.This event is part of the auxiliary net event class. No additional filters are available.
ip_output-sendall: transferring IP packet to driver layerThis event occurs when the network stack is processing an outgoing IP packet. The ip_output( ) routine handles both packet forwarding (if enabled) and locally generated packets. It performs any necessary route lookups and fragmentation, then passes the resulting M_BLK chain to the interface-specific transmit routine.
This event indicates that the network stack has completed the processing of a valid IP packet. This event occurs immediately before calculating the IP checksum (if necessary) when no fragmentation is required. It is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 1(output).
ip_output-sendfrag: fragmenting outgoing IP packetThis event occurs when the network stack is processing an outgoing IP packet. The ip_output( ) routine handles both packet forwarding (if enabled) and locally generated packets. It performs any necessary route lookups and fragmentation, then passes the resulting M_BLK chain to the interface-specific transmit routine.
This event indicates that the network stack is processing a valid IP packet which exceeds the MTU size of the selected output interface. This event occurs before constructing the IP fragments. If an error occurs during that process, the entire original packet is discarded. Otherwise, each M_BLK chain containing a fragment is transferred to the interface's output routine. If that routine fails, any remaining fragments are discarded. This event is part of the core net event class. Additional filtering based on the IP address is available with type values of 0 and 1(source or destination) and direction of 1(output).
ip_ctloutput-start: executing control operation for IP protocolThis event occurs when the network stack is processing a control operation related to the IP protocol. The setsockopt( ) and getsockopt( ) routines provide access to these settings using UDP, TCP, or raw sockets with a <level> argument of IPPROTO_IP. The ip_ctloutput( ) routine handles all options with values from 1 (IP_OPTIONS) to 13 (IP_DROP_MEMBERSHIP) except for IP_HDRINCL (2), which is only available for raw sockets. This event occurs before any processing of the command. If an error occurs, the corresponding setsockopt( ) or getsockopt( ) call returns ERROR with an error number setting indicating the problem.
This event is part of the auxiliary net event class. No additional filters are available.
ip_mloopback-start: copying outgoing multicast IP packet to local interfaceThis event indicates that the network stack is sending a multicast IP packet to the local host. The ip_output( ) routine uses the ip_mloopback( ) routine to deliver a copy of outgoing multicast packets if the selected output interface is also a member of the destination multicast group. This loopback operation occurs for all multicast transmissions unless disabled by calling the setsockopt( ) routine with a <level> argument of IPPROTO_IP for the IP_MULTICAST_LOOP command. If the sending host is configured as a multicast router, the loopback will always occur for IGMP reports and multicast forwarding, regardless of the option setting.
This event is part of the auxiliary net event class. No additional filters are available.
rip_ctloutput-start: executing control operation with raw socketsThis event indicates that the network stack is processing a control operation requested using a socket of type SOCK_RAW in the PF_INET domain. The rip_ctloutput( ) routine provides a switchboard for the options available through the setsockopt( ) and getsockopt( ) routines with a <level> argument of IPPROTO_IP.
The IP_HDRINCL option is unique to raw sockets and is handled directly. All options with values over 100 (DVMRP_INIT) are processed as multicast routing settings. The ip_ctloutput( ) routine handles all other options. This event is part of the auxiliary net event class. No additional filters are available.
rip_usrreq-start: executing raw socket operationThis event indicates that the network stack is processing a socket operation for an endpoint with type SOCK_RAW in the PF_INET domain. The rip_usrreq( ) routine handles all generic socket library routines for these raw sockets except for the setsockopt and getsockopt commands. If a failure occurs, the corresponding socket call usually sets the error number value to the result of the specific operation and returns ERROR. In some cases (such as a partial send operation which returns EWOULDBLOCK) the socket operation ignores the error result and returns the amount of data transferred.
This event is part of the core net event class. No additional filters are available.
raw_usrreq-start: executing routing socket operationThis event indicates that the network stack is processing a socket operation for an endpoint with type SOCK_RAW in the PF_ROUTE domain. The raw_usrreq( ) routine performs common functions to support any available generic socket library routines for routing sockets, which provide applications with direct access to the routing table.
The routing socket endpoints never send data to a remote host. Besides the socket write routines, which produce PRU_SEND requests, the getpeername( ) function is the only supported operation. Routing sockets do not support the setsockopt and getsockopt commands, the ioctl interface, or any of the receive routines. Reading from the file descriptor is the only method available for retrieving data. If a failure occurs, the corresponding socket call sets the error number value to the result of the specific operation and returns ERROR.
This event is part of the core net event class. No additional filters are available.
rtalloc1-clone: cloning a route entryThis event indicates that the network stack is creating a new route entry based on an existing entry to a destination. The rtalloc1( ) routine is the primary internal interface to the routing engine which provides three related operations. The routine will perform route searches, unconditionally attempt to create new route entries, or attempt to create route entries if no matching entry exists.
Cloning a route occurs when a route creation attempt detects an existing entry (with the cloning flag set) which matches the destination according to the route search routine. The new entry inherits properties from the existing entry with the overlapping or identical search key.
This situation typically occurs when creating a new ARP entry. The matching entry in that case is usually the destination to the directly connected logical subnet for a local interface.
This event is part of the auxiliary net event class. No additional filters are available.
rtalloc1-match: found an existing route entryThis event indicates that the network stack detected an entry with an overlapping or identical destination to the search key. The rtalloc1( ) routine is the primary internal interface to the routing engine which provides three related operations. The routine will perform route searches, unconditionally attempt to create new route entries, or attempt to create route entries if no matching entry exists.
This event typically occurs when the calling routine initiated a (successful) search. It can also occur if a route creation attempt unexpectedly detects a matching entry which does not support cloning. In either case, the existing entry is returned after incrementing the reference count.
This event is part of the auxiliary net event class. No additional filters are available.
rtfree-start: releasing a route entryThis event indicates that the network stack is removing a reference to an existing route entry. A panic message will occur if the supplied route entry pointer is NULL. The entry is not actually deleted unless the reference count reaches zero and the RTF_UP flag is not set.
The rtfree( ) routine is frequently called when a protocol closes a connection which included a reference to a routing entry. Both the UDP and TCP protocols cache route entries in an attempt to reduce the overhead of routing lookups. TCP also uses the route entry to store congestion control values while the connection is active.
This event is part of the auxiliary net event class. No additional filters are available.
rtioctl-start: executing control operation for routing tableThis event occurs when the network stack is processing a request from the generic I/O control interface. The ioctl.h include file defines the available operations. The request parameter included in this event contains the resulting four byte value. The first two arguments to the _IOxx macros in the include file provide the values for the final two bytes, which indicate the particular request. The third byte indicates whether it applies to sockets (`s': 0x73), routes (`r': 0x72), or interfaces (`i': 0x69). The fourth byte (second argument) is a unique offset within each category.
The rtioctl( ) routine handles the routing control operations SIOCADDRT and SIOCDELRT (request values with the format 0x803472dd) which provide applications with direct access to the routing table. This event occurs before any processing of the request. If an error occurs, the current routing table will remain unchanged and the corresponding ioctl( ) call will return ERROR with an error number setting indicating the problem. This event is part of the auxiliary net event class. No additional filters are available.
route_usrreq-start: executing routing socket operationThis event indicates that the network stack is processing a socket operation for an endpoint with type SOCK_RAW in the PF_ROUTE domain. The route_usrreq( ) routine handles any available generic socket library routines for routing sockets. Except for the PRU_ATTACH and PRU_DETACH requests, it uses the raw_usrreq( ) routine for all the actual processing.
Routing socket endpoints only provide applications with direct access to the routing table and never send data to a remote host. Besides the socket write routines, the getpeername( ) function is the only supported operation. The sockets do not support the setsockopt and getsockopt commands, the ioctl interface, or any of the receive routines. Reading from the file descriptor is the only method available for retrieving data.If a failure occurs, the corresponding socket call sets the error number value to the result of the specific operation and returns ERROR.
This event is part of the core net event class. No additional filters are available.
soo_ioctl-start: executing control operation with socketsThis event indicates that the network stack is processing a request from the generic I/O control interface. The ioctl.h include file defines the available operations. The request parameter included in this event contains the resulting four byte value. The first two arguments to the _IOxx macros in the include file provide the values for the final two bytes, which indicate the particular request. The third byte indicates whether it applies to sockets (`s': 0x73), routes (`r': 0x72), or interfaces (`i': 0x69). The fourth byte (second argument) is a unique offset within each category.
This event occurs for every ioctl( ) call issued using a BSD socket before any processing of the request. If an error occurs, the ioctl( ) call will return ERROR with an error number setting indicating the problem. This event is part of the auxiliary net event class. No additional filters are available.
soo_select-start: check sockets for pending dataThis event indicates that the network stack is processing the I/O interface select( ) routine, which pends on arbitrary file descriptors until either data arrives or the descriptor is writable. The soo_select( ) routine performs the type-specific setup required to support the select( ) call for all BSD sockets . It executes once for each socket whose file descriptor is included in the monitored set.
Following this event, the soo_select( ) routine immediately signals the pending select( ) routine to set the appropriate file descriptor and return if the required condition is already met. Otherwise, it installs the corresponding socket on the appropriate internal queue so that the select( ) routine will be notified once the socket is readable or writable.
This event is part of the auxiliary net event class. No additional filters are available.
soo_unselect-start: selection complete - removing socket from queueThis event indicates that the network stack is cleaning up following a completed execution of the I/O interface select( ) routine, which pends on arbitrary file descriptors until either data arrives or the descriptor is writable. The soo_unselect( ) routine implements the required behavior for all BSD sockets. It executes once for each socket whose file descriptor was included in the monitored set.
This event usually occurs when the select( ) routine is exiting normally because the expected condition has been met for at least one of the monitored file descriptors. It can also occur if the type-specific setup for the select( ) call, which the soo_select( ) routine performs for BSD sockets, fails for one of the given file descriptors. In that case, the select( ) routine will return ERROR.
Following this event, the soo_unselect( ) routine removes the corresponding socket from the appropriate internal queue to prevent invalid attempts to notify the (exiting) select( ) routine.
This event is part of the auxiliary net event class. No additional filters are available.
tcp_reass-segdrop: discarding redundant TCP segmentThis event occurs when the network stack has received a TCP segment from a remote host. The tcp_reass( ) routine processes each segment which contains data to deliver that payload to the corresponding socket of type SOCK_STREAM in the PF_INET domain in the correct order. If the segment's initial sequence number matches the current expected value, it is transferred to the socket's receive buffer for handling by the application. If the segment fills a gap in the data stream, the tcp_reass( ) routine also transfers the appropriate previously queued segments to the socket. Otherwise, it is added to the socket's reassembly queue or discarded.
This event indicates that a preceding segment on the reassembly queue completely overlaps the newly arrived segment. The new segment is discarded after incrementing the appropriate TCP statistics. This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-pureack: header prediction - acknowledging previously sent dataThis event occurs when the network stack has received a TCP segment from a remote host. The tcp_input( ) routine processes each segment for the corresponding socket of type SOCK_STREAM in the PF_INET domain. This event indicates the arrival of a simple acknowledgement on an established connection. The segment does not include any control flags, except for ACK (and possibly PSH), or any data. Also, the sequence number equals the next expected value, the window size is unchanged, and the previous segment sent was not a retransmission. This common case bypasses the slower general-purpose processing. After discarding the segment, the tcp_input( ) routine removes the acknowledged data from the socket's send buffer, resumes any pending write or task waiting on select( ), and calls tcp_output( ) to generate a new IP packet if appropriate.This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-puredata: header prediction - receiving ordered TCP dataThis event occurs when the network stack has received a TCP segment from a remote host. The tcp_input( ) routine processes each segment for the corresponding socket of type SOCK_STREAM in the PF_INET domain. This event indicates the arrival of a pure in-sequence data packet on an established connection. The only control flags in the segment are ACK (and possibly PSH), although no additional data is acknowledged. Also, the sequence number equals the next expected value, the window size is unchanged, and the previous segment sent was not a retransmission. This event occurs when the socket's reassembly queue is empty and the receive buffer has enough space for the in-sequence data. This common case bypasses the slower general-purpose processing. The tcp_input( ) routine moves the data to the socket's receive buffer and resumes any pending read or task waiting on a select( ) call.This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-accept: starting new passive connectionThis event occurs when the network stack has received a TCP segment from a remote host. The tcp_input( ) routine processes each segment for the corresponding socket of type SOCK_STREAM in the PF_INET domain.This event indicates the successful processing of the initial message (containing the SYN flag) in the handshake sequence which establishes a connection for a matching socket (with connection state LISTEN) which completed the listen( ) routine. It occurs after cloning a socket from that parent and setting the new state to SYN_RECEIVED.
Following this event, the tcp_input( ) routine calls the tcp_reass( ) routine to move any included data to the reassembly queue and uses the tcp_output( ) routine to send the second handshake message containing the SYN and ACK control flags. This event is part of the auxiliary net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-connect: completing new connectionThis event occurs when the network stack has received a TCP segment from a remote host. The tcp_input( ) routine processes each segment for the corresponding socket of type SOCK_STREAM in the PF_INET domain.This event indicates the successful completion of the handshake sequence which establishes a connection. A connection occurs after receiving a segment with the SYN and ACK flags for a socket (with connection state SYN_SENT) which completed the connect( ) routine. It also occurs after receiving a segment with the ACK flag for a socket (with connection state SYN_RECEIVED) which results from the listen( ) routine or (rarely) from a simultaneous open. Following this event, the tcp_input( ) routine sets the connection state to ESTABLISHED and calls the tcp_reass( ) routine to move any queued data to the socket's receive buffer. This event is part of the auxiliary net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-dataclosed: receiving data on closed connectionThis event occurs when the network stack has received a TCP segment from a remote host. The tcp_input( ) routine processes each segment for the corresponding socket of type SOCK_STREAM in the PF_INET domain.This event indicates the unexpected arrival of valid data for an inactive connection. It occurs after verifying that some portion of the data lies within the receive window of a matching socket (with connection state following CLOSE_WAIT) which completed the close( ) or shutdown( ) routines.
Following this event, the tcp_input( ) routine discards the incoming segment and calls the tcp_respond( ) routine to send a response containing the RST control flag. This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-reset: receiving reset message - breaking connectionThis event occurs when the network stack has received a TCP segment from a remote host. The tcp_input( ) routine processes each segment for the corresponding socket of type SOCK_STREAM in the PF_INET domain.This event indicates the arrival of a segment which includes the RST control flag. It occurs after verifying that some portion of the data lies within the receive window of a matching socket. The connection state for the socket is not equal to the LISTEN or SYN_SENT states (indicating a pending connection) that result from the listen( ) and connect( ) routines or to the CLOSING, LAST_ACK, and TIME_WAIT states that result from the close( ) and shutdown( ) routines.
Following this event, the tcp_input( ) routine sets the connection state to CLOSED, discards the incoming segment, and uses the tcp_close( ) routine to reset the local connection data. All future and pending attempts to use the socket for sending or receiving data will return ERROR with an error number setting of ECONNRESET (if the connection was active) or ECONNREFUSED (for an incomplete connection) until cleared by getsockopt( ) or a receive using MSG_PEEK. This event is part of the auxiliary net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-sendclosed: receiving final ACK - beginning active closeThis event occurs when the network stack has received a TCP segment from a remote host. The tcp_input( ) routine processes each segment for the corresponding socket of type SOCK_STREAM in the PF_INET domain.This event indicates the start of the handshake sequence which terminates a connection. The local end of a connection is closed after receiving a FIN message (ending the inbound link) and an acknowledgement for the FIN message sent during the close( ) or shutdown( ) routines (ending the outbound link). In an active close, a segment containing the FIN control flag is always sent first. This event occurs while processing the ACK flag for a matching socket in the FIN_WAIT_1 state, which results from sending the FIN message that this segment acknowledges.
Following this event, the tcp_input( ) routine sets the connection state to FIN_WAIT_2 to await the parallel FIN message from the remote peer. No further data may be sent using this socket. Data reception is possible following a half-close established by the shutdown( ) routine instead of the complete connection termination of the close( ) routine. This event is part of the auxiliary net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-closewait: receiving final segment - completing active closeThis event occurs when the network stack has received a TCP segment from a remote host. The tcp_input( ) routine processes each segment for the corresponding socket of type SOCK_STREAM in the PF_INET domain.This event indicates the completion of the handshake sequence which terminates a connection. The local end of a connection is closed after receiving a FIN message (ending the inbound link) and an acknowledgement for the FIN message sent during the close( ) or shutdown( ) routines (ending the outbound link). In an active close, a segment containing the FIN control flag is always sent first. If the close is simultaneous, this event occurs while processing the ACK flag for a socket in the CLOSING state. Otherwise, it occurs while handling the FIN flag for a state of FIN_WAIT_2, indicating that the FIN segment arrives with or after the ACK flag, not before it.
Following this event, the tcp_input( ) routine sets the connection state to TIME_WAIT. This state allows retransmission of any lost acknowledgements and enforces a mandatory delay before allowing the connection to be reused. No further data may be sent or received until the socket is reconnected, although it is still valid after completing the shutdown( ) routine. This event is part of the auxiliary net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-recvclosed: receiving initial FIN - beginning passive closeThis event occurs when the network stack has received a TCP segment from a remote host. The tcp_input( ) routine processes each segment for the corresponding socket of type SOCK_STREAM in the PF_INET domain.This event indicates the partial completion of the handshake sequence which terminates a connection. The local end of a connection is closed after receiving a FIN message (ending the inbound link) and an acknowledgement for the FIN message sent during the close( ) or shutdown( ) routines (ending the outbound link). In a passive close, a segment containing the FIN control flag always arrives first. This event occurs while processing the FIN flag for a matching socket with a connection state of either SYN_RECEIVED (indicating an incomplete passive connection or simultaneous open) or ESTABLISHED (for an active connection).
Following this event, the tcp_input( ) routine sets the connection state to CLOSE_WAIT.No further data may be received from this socket. Data transmission is possible until a half-close (using the shutdown( ) routine) or complete connection termination (using the close( ) routine) occurs. This event is part of the auxiliary net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-closing: receiving initial FIN - continuing active closeThis event occurs when the network stack has received a TCP segment from a remote host. The tcp_input( ) routine processes each segment for the corresponding socket of type SOCK_STREAM in the PF_INET domain.This event indicates the continuation of the handshake sequence which terminates a connection. The local end of a connection is closed after receiving a FIN message (ending the inbound link) and an acknowledgement for the FIN message sent during the close( ) or shutdown( ) routines (ending the outbound link). In an active close, a segment containing the FIN control flag is always sent first. This event occurs when processing the FIN flag for a segment after processing the ACK flag. The connection state for the matching socket is FIN_WAIT_1, which results from sending a FIN message. This event indicates the remote peer is simultaneously performing an active close. The pending FIN message has not been acknowledged.
Following this event, the tcp_input( ) routine sets the connection state to CLOSING to wait for the final acknowledgement and complete the simultaneous close. No further data may be sent or received from the socket. This event is part of the auxiliary net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-close-restart: receiving duplicate FIN - restart timerThis event occurs when the network stack has received a TCP segment from a remote host. The tcp_input( ) routine processes each segment for the corresponding socket of type SOCK_STREAM in the PF_INET domain.This event indicates the arrival of a segment containing the FIN control flag for a closed connection. A connection is closed after both ends send a FIN message and both messages are acknowledged. The connection state for the matching socket is TIME_WAIT, which enforces a mandatory delay before a connection can be reused.
Following this event, the tcp_input( ) routine resets the connection delay timer to the mandatory initial value of twice the maximum segment lifetime. If the segment includes an ACK flag, the routine also retransmits the (lost) acknowledgement of the FIN message. Otherwise, this segment is a duplicate FIN message and no response occurs. This event is part of the auxiliary net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_drop-start: breaking connection - assign socket errorThis event occurs when the network stack aborts an (active or pending) TCP connection, which is associated with a socket of type SOCK_STREAM in the PF_INET domain. The tcp_drop( ) routine stores a hard error in the matching socket to indicate the problem. This event occurs when the network stack is unable to establish or maintain a connection because it receives an explicit reset or is unable to clone a new socket. It also occurs after TCP timers expire if the idle time exceeds the maximum values. The connection is also dropped when closing a socket.
Following this event, the tcp_drop( ) routine sets the connection state to CLOSED , calls tcp_output( ) to send a RST (if needed), and uses the tcp_close( ) routine to reset the local connection data. All future and pending attempts to use the socket for sending or receiving data will return ERROR with the given value (or soft error) until cleared by getsockopt( ) or a receive using MSG_PEEK. This event is part of the auxiliary net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 1(output).
tcp_close-start: ending connection - reset local connection dataThis event occurs when the network stack is returning the connection data for a socket of type SOCK_STREAM in the PF_INET domain to the initial state. The tcp_close( ) routine releases the control information associated with that socket and the corresponding connection. This event occurs after the TIME_WAIT connection state, which results from completing the handshake sequence that terminates a connection. That state enforces a delay before connection reuse after an active close. The network stack truncates the delay if it receives a SYM message in the TIME_WAIT state which reincarnates a connection. The tcp_close( ) routine also executes immediately after a passive close and when a remote peer explicitly resets a synchronized connection. The local connection data is also reset when the close( ) or shutdown( ) routines end the incoming and outgoing links and when data arrives on a connection matching a closed socket. Finally, tcp_close( ) resets the local connection data during the tcp_drop( ) routine. Following this event, the tcp_close( ) routine stores any valid congestion control variable settings in the routing table and detaches the socket from the connection. All future or pending send attempts to use the socket for sending data will return ERROR with an error number setting of EPIPE. Receive attempts will not retrieve additional data. This event is part of the auxiliary net event class. No additional filters are available.
tcp_notify-ignore: transmit failure for established connectionThis event indicates that the network stack has received an ICMP error message for a socket of type SOCK_STREAM in the PF_INET domain. The tcp_ctlinput( ) routine is the protocol-specific routine which the icmp_input( ) routine uses to handle all supported ICMP errors for TCP payloads. The tcp_notify( ) routine handles all destination unreachable errors (type 3) and all parameter problem errors (type 12) and records the associated error number value as a soft or hard error.
This event occurs when the network stack receives an ICMP destination unreachable error (type 3) which maps to the error number EHOSTUNREACH for a socket with an established connection. These errors (ICMP codes 0, 1, and 5-12) are silently ignored after completing a connection to the remote peer.
Following this event, the tcp_notify( ) routine calls the wakeup routines to trigger any pending send and receive calls or any select( ) calls waiting on the socket. This event is part of the auxiliary net event class. No additional filters are available.
tcp_notify-harderror: repeated failure for incomplete connectionThis event indicates that the network stack has received an ICMP error message for a socket of type SOCK_STREAM in the PF_INET domain. The tcp_ctlinput( ) routine is the protocol-specific routine which the icmp_input( ) routine uses to handle all supported ICMP errors for TCP payloads. The tcp_notify( ) routine handles all destination unreachable errors (type 3) and all parameter problem errors (type 12) and records the associated error number value as a soft or hard error.
This event occurs when the network stack receives an ICMP error for a socket with an incomplete connection which has already recorded a soft error and resent the current segment at least four times. The error number is stored as a hard error for the socket. Following this event, the tcp_notify( ) routine calls the wakeup routines to trigger any pending send and receive calls or any select( ) calls waiting on the socket. All future and pending attempts to use the socket for sending or receiving data will return ERROR with the recorded error number until cleared by getsockopt( ) or a receive using MSG_PEEK. This event is part of the auxiliary net event class. No additional filters are available.
tcp_notify-softerror: initial communication failure for connectionThis event indicates that the network stack has received an ICMP error message for a socket of type SOCK_STREAM in the PF_INET domain. The tcp_ctlinput( ) routine is the protocol-specific routine which the icmp_input( ) routine uses to handle all supported ICMP errors for TCP payloads. The tcp_notify( ) routine in turn handles all destination unreachable errors (type 3) and all parameter problem errors (type 12) and records the associated error number value as a soft or hard error.
This event occurs for an ICMP message classified as a soft error, which does not prevent sending or receiving data. For a socket with an incomplete connection, the tcp_notify( ) routine stores a value as a soft error for the first ICMP message, or any later message that occurs before retransmitting a segment four times without any acknowledgements. Soft errors also occur for an established connection receiving ICMP messages (type 3, codes 2-4 or type 12) that do not map to EHOSTUNREACH
Following this event, the tcp_notify( ) routine calls the wakeup routines to trigger any pending send and receive calls or any select( ) calls waiting on the socket. This event is part of the auxiliary net event class. No additional filters are available.
tcp_ctlinput-start: process asynchronous events for TCPThis event indicates that the network stack is either disabling an interface or has received an ICMP error message. The tcp_ctlinput( ) routine is the protocol-specific routine which the icmp_input( ) routine uses to handle all ICMP error messages for TCP payloads. It also responds to the PRC_IFDOWN event which occurs when an ioctl( ) call disables an interface by clearing the IFF_UP flag.
Following this event, the tcp_ctlinput( ) routine passes all supported ICMP messages to the in_pcbnotify( ) routine, which filters out redirects and sends the remaining events to the appropriate TCP routines. The tcp_quench( ) routine closes the congestion window and triggers the slow start algorithm in response to the PRC_QUENCH command resulting from an ICMP source quench message. The default tcp_notify( ) routine processes all other ICMP messages for the appropriate sockets. The tcp_ctlinput( ) routine ignores the PRC_IFDOWN event.
This event is part of the auxiliary net event class. No additional filters are available.
tcp_fasttimo-start: processing delayed ACK timerThis event occurs during the network stack's fast timeout update for protocols, which occurs five times per second. That feature allows any protocol which registers a fast timeout function during initialization to perform any operations at that interval.
The tcp_fasttimo( ) routine is the protocol-specific function for TCP. It implements the delayed ACK timer which attempts to piggyback ACK messages with data by deferring the acknowledgement.
Following this event, the tcp_fasttimo( ) routine checks each established connection for delayed acknowledgements and uses the tcp_output( ) routine to send the ACK message after incrementing the appropriate counter in the TCP statistics.
This event is part of the auxiliary net event class. No additional filters are available.
tcp_slowtimo-start: updating connection status timersThis event occurs during the network stack's slow timeout update for protocols, which occurs twice per second. That feature allows any protocol which registers a slow timeout function during initialization to perform any operations at that interval.
The tcp_slowtimo( ) routine is the protocol-specific function for TCP. It updates the counters which maintain the retransmission timer, persist timer (which sends window probes), and keepalive timer, as well as the connection establishment and FIN_WAIT_2 timers (which impose time limits for starting and ending connections) and the TIME_WAIT timer (which enforces the delay before connection reuse).
Following this event, the tcp_slowtimo( ) routine updates the idle time counter for each connection and uses the tcp_timers( ) routine to handle any expired timer. This event is part of the auxiliary net event class. No additional filters are available.
tcp_usrreq-start: executing TCP socket operationThis event indicates that the network stack is processing a socket operation for an endpoint with type SOCK_STREAM in the PF_INET domain. The tcp_usrreq( ) routine handles all generic socket library routines for these sockets except for the setsockopt and getsockopt commands. If a failure occurs, the corresponding socket call usually sets the error number value to the result of the specific operation and returns ERROR. In some cases (such as a partial send operation which returns EWOULDBLOCK) the socket operation ignores the error result and returns the amount of data transferred.
This event is part of the auxiliary net event class. No additional filters are available.
tcp_ctloutput-start: accessing TCP or IP socket optionThis event indicates that the network stack is processing a control operation requested using a socket of type SOCK_STREAM in the PF_INET domain. The tcp_ctloutput( ) routine provides a switchboard for the options available through the setsockopt( ) and getsockopt( ) routines with a <level> argument of IPPROTO_TCP. Following this event, the tcp_ctloutput( ) routine handles the native TCP_NODELAY and TCP_MAXSEG options directly and uses the ip_ctloutput( ) routine for all other options. If an error occurs, the corresponding setsockopt( ) or getsockopt( ) call returns ERROR with an error number setting indicating the problem.
This event is part of the auxiliary net event class. No additional filters are available.
udp_input-newdata: accepting UDP datagram - socket foundThis event indicates that the network stack is processing a UDP datagram from a remote host. The udp_input( ) routine is the protocol-specific input routine which the ipintr( ) routine invokes to process each datagram for the associated sockets of type SOCK_DGRAM in the PF_INET domain. The udp_input( ) routine validates the datagram checksum and copies the payload into the receive buffers of any matching sockets, which are selected by the address and port number values.
This event occurs after each successful search for a matching socket. Following this event, the udp_input( ) routine moves the data to the socket's receive buffer and resumes any pending receive calls and any select( ) calls waiting on the socket. This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
udp_notify-error: communication failure for UDP datagramThis event indicates that the network stack has received an ICMP error message for a socket of type SOCK_DGRAM in the PF_INET domain. The udp_ctlinput( ) routine is the protocol-specific routine which the icmp_input( ) routine uses to handle all supported ICMP errors for UDP payloads. The udp_notify( ) routine in turn handles all destination unreachable errors (type 3) and parameter problem errors (type 12).
This event occurs before any processing of the reported ICMP error. The error number is stored as a hard error for the socket. Following this event, the udp_notify( ) routine calls the wakeup routines to trigger any pending send and receive calls or any select( ) calls waiting on the socket. All future and pending attempts to use the socket for sending or receiving data will return ERROR with the recorded error number until cleared by getsockopt( ) or a receive using MSG_PEEK. This event is part of the auxiliary net event class. No additional filters are available.
udp_ctlinput-start: process asynchronous events for UDPThis event indicates that the network stack is either disabling an interface or has received an ICMP error message. The udp_ctlinput( ) routine is the protocol-specific routine which the icmp_input( ) routine uses to handle all ICMP error messages for UDP payloads. It also responds to the PRC_IFDOWN event which occurs when an ioctl( ) call disables an interface by clearing the IFF_UP flag.
Following this event, the udp_ctlinput( ) routine passes all supported ICMP messages to the in_pcbnotify( ) routine, which filters out redirects and sends the remaining events to the default udp_notify( ) routine for processing by all appropriate sockets. The udp_ctlinput( ) routine ignores the PRC_IFDOWN event and the PRC_QUENCH, PRC_TIMXCEED_INTRANS and PRC_TIMXCEED_REASS events (generated by the corresponding ICMP messages). This event is part of the auxiliary net event class. No additional filters are available.
udp_usrreq-start: executing UDP socket operationThis event indicates that the network stack is processing a socket operation for an endpoint with type SOCK_DGRAM in the PF_INET domain. The udp_usrreq( ) routine handles all generic socket library routines for these sockets except for the setsockopt and getsockopt commands. If a failure occurs, the corresponding socket call usually sets the error number value to the result of the specific operation and returns ERROR. In some cases (such as a partial send operation which returns EWOULDBLOCK) the socket operation ignores the error result and returns the amount of data transferred.
This event is part of the auxiliary net event class. No additional filters are available.
soclose-sleep: deferring socket removal until connection expiresThis event occurs when the network stack is processing the close( ) routine for a socket endpoint with the SO_LINGER option set. The socket close will not complete until the current connection ends. This event indicates the pending block of the calling task until signalled by a change in the socket state. Following this event, the calling task blocks until released. Upon restarting, the soclose( ) routine checks the socket status and will block again if still connected. This event is part of the auxiliary net event class. No additional filters are available.
sbwait-sleep: pausing during incomplete data transferThis event occurs when the network stack is processing a send or receive option for a socket which cannot be completed immediately. Either the amount of data requested is not available or the send buffer is currently full. This event indicates the pending block of the calling task until a wakeup routine signals that the appropriate buffer is available for additional reads or writes. Following this event, the calling task blocks until released. This event is part of the core net event class. No additional filters are available.
sbwakeup-start: restart pending data transfersThis event occurs when the network stack reports a change in status of a socket's input or output buffers. Following this event, the sbwakeup( ) routine resumes any pending send (or receive) calls, depending on the type of change, and any select( ) calls waiting on the socket. This event is part of the core net event class. No additional filters are available.
ifinit-start: initializing network interfacesThis event occurs when the network stack is attaching to the available interfaces during startup. Following this event, the ifinit( ) routine sets the length of the output queue for each interface (if not already assigned by the interface-specific attach routine) and starts the interface update timer, which fires once per second. This event is part of the auxiliary net event class. No additional filters are available.
ifreset-start: closing network interfacesThis event occurs when the network stack is executing a complete shutdown. The ifreset( ) routine handles that process for the network as part of the processing for the reboot( ) routine. Following this event, the ifreset( ) routine calls all the interface-specific reset routines provided by the attached interfaces, returning the corresponding devices to their uninitialized state.signed by the interface-specific attach routine) and starts the interface update timer, which fires once per second. This event is part of the auxiliary net event class. No additional filters are available.
if_attach-start: activating network interface - add to active listThis event occurs when the network stack is inserting a new interface into the list of active interfaces during startup. Following this event, the if_attach( ) routine assigns a device name and unit number to the interface, adds the interface to the list of available devices, and uses the ether_ifattach( ) routine to complete the initialization of the interface-specific data structure. This event is part of the auxiliary net event class. No additional filters are available.
if_dettach-start: deleting network interfaceThis event occurs when the network stack is removing an interface as part of the processing for an interface-specific detach operation. Following this event, the if_dettach( ) routine handles the interface shutdown for the IP protocol. It uses the in_ifaddr_remove( ) and in_delmulti( ) routines to remove all unicast and multicast IP addresses associated with the interface, then removes the interface data structure from the list of active interfaces. This event is part of the auxiliary net event class. No additional filters are available.
if_down-start: disabling network interfaceThis event indicates that the network stack is disabling an interface after an ioctl( ) call which clears the IFF_UP flag. While that flag is not set, the interface will not send or receive any data. Following this event, the if_down( ) routine generates a PRC_IFDOWN event for any transport protocols using the interface, uses the if_qflush( ) routine to empty the send queue, and sends a status change message to the routing system. Both the TCP and UDP protocols ignore interface shutdowns, relying on the routing system to find an alternate path. This event is part of the auxiliary net event class. No additional filters are available.
if_up-start: enabling network interfaceThis event indicates that the network stack is enabling an interface after an ioctl( ) call to restore the IFF_UP flag. Following this event, the if_up( ) routine sets that flag and sends a status change message to the routing system. No further action is required. Since that flag is now set, the interface will resume sending and receiving data. This event is part of the auxiliary net event class. No additional filters are available.
ifpromisc-start: changing promiscuous mode for an interfaceThis event indicates that the network stack is attempting to enable or disable promiscuous mode for a particular device. This setting, which is disabled by default, allows a device to receive all link-layer frames regardless of the destination address. The IFF_PROMISC flag which reflects the current setting cannot be altered with an ioctl( ) call like other flags. The setting can only be changed with this routine. Following this event, the if_promisc( ) routine sets (or clears) the flag and uses the interface-specific control routine to alter the behavior of the device appropriately. Only the first "on" request and final "off" request have any effect. This event is part of the auxiliary net event class. No additional filters are available.
arp_rtrequest-start: changing or retrieving ARP table entryThis event occurs when the network stack is accessing ARP information stored in the routing table. Every address assigned to an interface is associated with a route to the corresponding network. It is also associated with an optional routine to support storing link-level entries in the routing table. The arp_rtrequest( ) routine maintains that information for all Ethernet devices attached to the IP network protocol. The route entries which it creates contain the protocol address in the destination field and the hardware address in the gateway field.
This event indicates that the network stack is adding, deleting, or retrieving the link-level ARP information as part of ordinary processing. These operations can occur as a result of specific user requests or because data is being sent or received by the interface using the protocol address.
This event is part of the auxiliary net event class. No additional filters are available.
arprequest-send: ARP request sent to driver layerThis event indicates that the network stack is transmitting an ARP request. That transmission generally occurs as part of the ARP resolution process to determine the destination hardware address which matches a destination network protocol address, if that information is not present in the ARP cache. An ARP transmission also occurs after adding a static ARP entry to the system with the ATF_PUBL flag set. That ARP "request" for a known value announces the new hardware address/network address pair to all other hosts.
This event is part of the auxiliary net event class. No additional filters are available.
arpresolve-start: finding hardware address for destinationThis event occurs when the network stack is processing an IP packet for transmission using an Ethernet device. The arpresolve( ) routine determines the hardware address required for the Ethernet header. Following this event, it uses the arprequest( ) routine to find that address from the appropriate host if it is not already available. Determining the hardware address with an ARP request is not necessary if the destination is a broadcast or multicast address, or if the information is already present in the ARP cache. The arpresolve( ) routine also bypasses the request transmission if the IFF_NOARP flag is set for the outgoing interface.
This event is part of the auxiliary net event class. Additional filtering based on the IP address is available with a type value of 1( destination) and direction of 1(output).
arpintr-start: received ARP packet for local destinationThis event indicates that the network stack has accepted an ARP packet for local delivery. The arpintr( ) routine executes at task level in response to an interrupt from a network driver delivering a link-level frame containing ARP data. Following this event, the arpintr( ) routine uses the in_arpinput( ) routine to handle all ARP packets which contain Ethernet hardware and IP network addresses. The routine discards all other frames.
This event is part of the auxiliary net event class. No additional filters are available.
ether_ifattach-start: activating network interface - storing hardware addressThis event occurs when the network stack is inserting a new interface into the list of active interfaces during startup. The ether_ifattach( ) routine completes the initialization process by storing the hardware address and Ethernet MTU size in the interface-specific data structure. This event is part of the auxiliary net event class. No additional filters are available.
ether_attach-start: activating network interface - attach to deviceThis event occurs when the network stack is inserting a new interface into the list of active interfaces during startup. All Ethernet drivers using the BSD interface call the ether_attach( ) routine to store the required entry points in the interface-specific data structure. Following this event, the ether_attach routine uses the if_attach( ) routine to complete the partial attachment. The ifunit( ) routine will be unable to find the interface until the if_attach( ) routine is complete. This event is part of the auxiliary net event class. No additional filters are available.
igmp_init-start: initializing IGMP componentThis event occurs when the network stack is initializing all included components during startup. The Internet Group Management Protocol reports the multicast group membership for the host to support correct forwarding by multicast routers.
Following this event, the igmp_init( ) routine installs the internal hook routines which generate the appropriate IGMP messages when the local group membership changes.
The IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP options for the setsockopt( ) routine will use those hook routines to trigger IGMP messages after adding or removing a multicast group membership. The network stack also removes a multicast group automatically when the last socket using the group closes.
The usrNetProtoInit( ) routine installs the igmp_init( ) routine when the INCLUDE_IGMP constant adds that protocol to the system. That initialization routine executes within the netLibInit( ) routine whenever the INCLUDE_NET_INIT constant starts the network automatically.
This event is part of the auxiliary net event class. No additional filters are available
igmp_joingroup-start: advertising new multicast group membershipThis event indicates that the network stack is processing the IP_ADD_MEMBERSHIP control operation which joins a multicast group. The setsockopt( ) routine provide access to this setting using UDP, TCP, or raw sockets with a <level> argument of IPPROTO_IP.
This event occurs when joining a multicast group for the first time. The network stack does not announce subsequent sockets joining the same group. Following this event, the igmp_joingroup( ) routine usually activates a timer to issue a new group membership report and also uses the igmp_sendreport( ) routine routine to advertise the membership immediately. That process does not occur when joining the all-hosts group or if the target of the report is the loopback interface.
This event is part of the auxiliary net event class. No additional filters are available
igmp_leavegroup-start: "advertising" old multicast group membershipThis event indicates that the network stack is leaving a multicast group. Except for the all hosts multicast group, which is automatically joined by all multicast interfaces, this process occurs whenever the final socket which was using a group closes. The IP_DROP_MEMBERSHIP control operation will also trigger this event by manually removing the final group membership. The setsockopt( ) routine performs that operation using UDP, TCP, or raw sockets with a <level> argument of IPPROTO_IP.
No further action is necessary following this event. The network stack does not announce the departure from multicast groups. It will not include the group in the reply to subsequent queries from multicast routers.
This event is part of the auxiliary net event class. No additional filters are available
in_control-start: accessing interface address or netmaskThis event occurs when the network stack is processing a request from the generic I/O control interface. The ioctl.h include file defines the available operations. The request parameter included in this event contains the resulting four byte value. The first two arguments to the _IOxx macros in the include file provide the values for the final two bytes, which indicate the particular request. The third byte indicates whether it applies to sockets (`s': 0x73), routes (`r': 0x72), or interfaces (`i': 0x69). The fourth byte (second argument) is a unique offset within each category.
The in_control( ) routine handles most interface-specific operations (request values with the format 0xaabb69dd). Following this event, the network stack attempts to assign or retrieve the broadcast address, destination address, network address, or netmask setting for an interface. It also handles requests to remove an assigned network address. If the requested operation fails, the corresponding ioctl( ) call returns ERROR with an error number indicating the problem.
This event is part of the auxiliary net event class. No additional filters are available.
in_ifscrub-start: removing interface routesThis event indicates that the network stack is deleting the internally generated route associated with a network address. The network stack uses those route entries to access the directly connected networks for each interface, based on the network address and netmask setting.
This event occurs during the SIOCSIFADDR and SIOCDIFADDR ioctl( ) operations, because the internally generated route entry is no longer valid. It also occurs if the SIOCAIFADDR operation changes the netmask setting of a broadcast interface or the destination address of a point-to-point interface. a request from the generic I/O control interface.
Following this event, the in_ifscrub( ) routine uses the rtinit( ) routine to remove the obsolete route entry. This event is part of the auxiliary net event class. No additional filters are available.
in_ifinit-start: creating interface addresses and route entryThis event indicates that the network stack is assigning an address to an interface and creating the corresponding internally generated route entry. The network stack uses those route entries to access the directly connected networks for each interface, based on the network address and netmask setting.
This event occurs during the SIOCSIFADDR and SIOCAIFADDR ioctl( ) operations. The network startup code uses the SIOCSIFADDR operation during the setup of any network boot device.
Following this event, the in_ifinit( ) routine calls the driver-specific control routine (if any) with the SIOCSIFADDR option to perform any necessary link-level processing, sets the netmask (if necessary), assigns the broadcast or destination address, and uses the rtinit( ) routine to add the appropriate route entry. For multicast-capable interfaces, it also uses the in_addmulti( ) routine to join the all hosts multicast group.
This event is part of the auxiliary net event class. No additional filters are available.
in_ifaddr-remove: deleting interface addressesThis event occurs when the network stack is removing an interface as part of the processing for an interface-specific detach operation. The in_ifaddr_remove( ) routine deletes all the unicast IP addresses associated with the interface as part of the processing within the if_dettach( ) routine.
This event is part of the auxiliary net event class. No additional filters are available.
in_addmulti-start: joining multicast groupThis event occurs when the network stack is processing the IP_ADD_MEMBERSHIP control operation which joins a multicast group. The setsockopt( ) routine provide access to this setting using UDP, TCP, or raw sockets with a <level> argument of IPPROTO_IP.
Following this event, the in_addmulti( ) routine either stores the group address in a new list entry or increments the reference count for an existing membership. When creating a new list entry, it uses the igmp_joingroup( ) routine to send a new group membership report, if the IGMP protocol is installed.
This event is part of the auxiliary net event class. No additional filters are available
This event occurs when the network stack is removing an interface as part of the processing for an interface-specific detach operation. The in_ifaddr_remove( ) routine deletes all the unicast IP addresses associated with the interface as part of the processing within the if_dettach( ) routine.
This event is part of the auxiliary net event class. No additional filters are available.
in_delmulti-start: leaving multicast groupThis event occurs when the network stack is processing the IP_DROP_MEMBERSHIP control operation which leaves a multicast group. The setsockopt( ) routine provide access to this setting using UDP, TCP, or raw sockets with a <level> argument of IPPROTO_IP. It also occurs automatically whenever the final socket which was using a group closes, and when removing all multicast addresses associated with an interface as part of the processing within the if_dettach( ) routine.
Following this event, the in_delmulti( ) routine decrements the reference count for the membership. If that value drops to zero, it calls the driver-specific control routine with the SIOCDELMULTI option to perform any necessary link-level processing and uses the igmp_leavegroup( ) routine to update the IGMP settings, if that protocol is installed.
This event is part of the auxiliary net event class. No additional filters are available.
in_pcbbind-start: assigning local socket nameThis event occurs when the network stack is assigning a local name to socket endpoints with type SOCK_STREAM or SOCK_DGRAM in the PF_INET domain. For these TCP and UDP sockets, the socket name is a local IP address and a port number. The socket name is usually assigned by an explicit call to the bind( ) routine, but may be added automatically when necessary. Implicit binds occur during the listen( ) routine for unbound TCP sockets, during the sendto( ) routine for unconnected UDP sockets, and during the connect( ) routine for unbound sockets of either type.
The in_pcbbind( ) routine handles both explicit binds (corresponding to the PRU_BIND operation for the tcp_usrreq( ) and udp_usrreq( ) generic control routines) and implicit bind operations.
Following this event, the routine validates the given address and port number, assigning default values if necessary, and stores the resulting information in the protocol control block for the socket. This event is part of the auxiliary net event class. No additional filters are available.
in_pcbconnect-start: assigning remote socket nameThis event occurs when the network stack is assigning a remote name to socket endpoints with type SOCK_STREAM or SOCK_DGRAM in the PF_INET domain. For these TCP and UDP sockets, the remote name is a foreign IP address and port number. The resulting connection is usually established explicitly by the connect( ) call, but temporary connections are also created by the sendto( ) call for unconnected UDP sockets. The in_pcbconnect( ) routine also adds the remote name information for a TCP socket in the LISTEN state which completes a passive connection.
Following this event, the in_pcbconnect( ) routine uses the in_pcbladdr( ) routine to provide any necessary local name information, validates the uniqueness of the resulting connection, and stores the resulting remote name information in the protocol control block for the socket. This event is part of the auxiliary net event class. No additional filters are available.
in_pcbdisconnect-start: clearing remote socket nameThis event indicates that the network stack is removing a remote name from socket endpoints with type SOCK_STREAM or SOCK_DGRAM in the PF_INET domain. For these TCP and UDP sockets, the remote name is a foreign IP address and port number.
The in_pcbdisconnect( ) routine handles the PRU_DISCONNECT operation (which occurs during the close( ) routine for UDP sockets) for the udp_usrreq( ) generic control routine. It also clears the remote name for temporary connections created during the sendto( ) call for unconnected UDP sockets and for some failed active connection attempts by TCP sockets.
Following this event, the in_pcbdisconnect( ) routine sets the remote name information in the protocol control block for the socket to the initial (wildcard) default values. This event is part of the auxiliary net event class. No additional filters are available.
in_pcbnotify-start: processing ICMP events for all socketsThis event occurs when the network stack has received an ICMP message resulting from sending a TCP or UDP payload. The in_pcbnotify( ) routine continues the processing started by the protocol-specific tcp_ctlinput( ) and udp_ctlinput( ) asynchronous event handlers.
Following this event, the in_pcbnotify( ) routine uses the in_rtchange( ) routine to handle all ICMP redirect messages by invalidating any cached routes in the protocol control blocks of sockets bound to the source address of the original packet. The routine calls the provided protocol-specific routines to process all other ICMP events for each matching socket, based on the local and remote names in the associated protocol control blocks.
This event is part of the auxiliary net event class. No additional filters are available.
ip_output-cachemiss: emptying invalid cached routeThis event occurs when the network stack is processing an outgoing IP packet. The ip_output( ) routine handles both packet forwarding (if enabled) and locally generated packets. It performs any necessary route lookups and fragmentation, then passes the resulting M_BLK chain to the interface-specific transmit routine.
This event indicates that the route cache is no longer valid. To reduce potentially costly route lookups, the network stack stores a reference to the route used for the previous IP packet, assuming that a host generally produces a sequence of transmissions to the same destination. This event typically occurs when the destination address changes from the previous value, but also happens after disabling the referenced route during the route delete operation.
Following this event, the ip_output( ) routine releases the referenced route and empties the cache, forcing a new route lookup. The route will be deleted if the release operation removes the last reference. This event is part of the core net event class. Additional filtering based on the IP address is available with type value of 1(destination) and direction of 1(output).
ip_init-start: initializing IP componentThis event occurs when the network stack is initializing all included components during startup. The Internet Protocol routes all outgoing packets to the next hop destination based on the contents of the routing table. Following this event, the ip_init( ) routine initializes the fragment reassembly and packet reception queues and selects a starting value for the packet identification field.
The usrNetProtoInit( ) routine installs the ip_init( ) routine unconditionally whenever the INCLUDE_NET_INIT constant starts the network automatically. The IP protocol is always included in the network stack.
This event is part of the auxiliary net event class. No additional filters are available
raw_attach-start: creating new routing socketThis event occurs when the network stack is creating a socket endpoint of type SOCK_RAW in the PF_ROUTE domain. The routing sockets allow applications to alter and monitor the contents of the routing table by sending and receiving routing messages. The messages can be restricted to routes for a specific address family (such as AF_INET for IP destinations) by including the family value in the protocol argument when creating the socket. Otherwise, the routing socket receives all messages.
The raw_attach( ) routine completes the PRU_ATTACH operation (which occurs during the socket( ) routine) for the route_usrreq( ) generic control routine. Following this event, the raw_attach( ) routine stores the value of the protocol argument from the socket( ) routine (which may restrict the route messages) in the pre-allocated protocol control block associated with the socket.
This event is part of the core net event class. No additional filters are available.
raw_detach-start: removing routing socketThis event occurs when the network stack is closing a socket endpoint of type SOCK_RAW in the PF_ROUTE domain. The routing sockets allow applications to alter and monitor the contents of the routing table by sending and receiving routing messages. The messages can be restricted to routes for a specific address family (such as AF_INET for IP destinations) by including the family value in the protocol argument when creating the socket. Otherwise, the routing socket receives all messages.
The raw_detach( ) routine handles the PRU_DETACH operation (which occurs during the close( ) routine) for the route_usrreq( ) generic control routine. Following this event, the raw_detach( ) routine frees the protocol control block associated with the socket.
This event is part of the core net event class. No additional filters are available.
rip_init-start: initializing raw IP socket interfaceThis event occurs when the network stack is initializing all included components during startup. The raw IP sockets provide direct access to selected IP traffic. This feature allows applications to send and receive ICMP and IGMP messages, generate IP directly, and receive all incoming IP packets with protocol types other than TCP and UDP, which the network stack otherwise ignores.
Following this event, the rip_init( ) routine initializes the storage for the protocol control blocks associated with raw IP sockets.
The usrNetProtoInit( ) routine installs the rip_init( ) routine unconditionally whenever the INCLUDE_NET_INIT constant starts the network automatically. The raw IP socket interface is always included in the network stack.
This event is part of the auxiliary net event class. No additional filters are available
raw_init-start: completing routing socket initializationThis event occurs when the network stack is initializing all included components during startup. The routing sockets allow applications to alter and monitor the contents of the routing table by sending and receiving routing messages. The messages can be restricted to routes for a specific address family (such as AF_INET for IP destinations) by including the family value in the protocol argument when creating the socket. Otherwise, the routing socket receives all messages.
Following this event, the raw_init( ) routine initializes the storage for the protocol control blocks associated with routing sockets.
The rtSockLibInit( ) routine installs the rtSockInit( ) routine when the INCLUDE_ROUTE_SOCK and INCLUDE_BSD_SOCKET constants add the routing socket interface to the system. That initialization routine executes within the netLibInit( ) routine whenever the INCLUDE_NET_INIT constant starts the network automatically. It uses the raw_init( ) routine to complete the initialization of the routing sockets.
This event is part of the auxiliary net event class. No additional filters are available
route_init-start: initializing routing storageThis event occurs when the network stack is initializing all included components during startup. The routing table stores all routing information for any network protocols. It returns entries which identify the next hop for a particular destination address, among other information.
Following this event, the route_init( ) routine allocates internal storage and creates the initial routing table for all supported network protocols. Each address family uses separate storage for the associated routes. The default installation creates a single routing table for IP routing entries.
The route_init( ) routine executes within the netLibInit( ) routine whenever the INCLUDE_NET_INIT constant starts the network automatically. The routing table storage is always included in the network stack.
This event is part of the auxiliary net event class. No additional filters are available
rtredirect-result: automatically changing routing tableThis event occurs when the network stack is processing an ICMP redirect message. These messages occur when a router forwards a packet using the identical (incoming) interface. That router optionally sends an ICMP redirect message to the original source to eliminate the unnecessary hop which it currently implements.
The icmp_input( ) routine uses the rtredirect( ) routine to update the routing table to the new gateway address in the ICMP message, after validating the information. The current gateway must match the source address of the ICMP message and the new gateway address must be directly reachable or the routing table is unchanged.
This event indicates that the network stack has completed processing the ICMP message and altered the routing table if appropriate. This event is part of the auxiliary net event class. No additional filters are available
rtinit-start: updating routing table for local interfaceThis event occurs when the network stack is modifying the address assigned to an interface. Each address assigned to an interface produces a corresponding route entry. The network stack uses those route entries to access the directly connected networks for each interface, based on the network address and netmask setting.
This event occurs during the SIOCSIFADDR, SIOCSIFDSTADDR, SIOCAIFADDR and SIOCDIFADDR ioctl( ) operations. The rtinit( ) routine removes the internally generated route entry when an address is deleted and creates the appropriate entry for each new address. The network startup code uses the SIOCSIFADDR operation during the setup of any network boot device.
Following this event, the rtinit( ) routine updates the routing table by adding or removing an entry for the given interface address.This event is part of the auxiliary net event class. No additional filters are available.
rtSockInit-start: initializing routing socket interfaceThis event occurs when the network stack is initializing all included components during startup. The routing sockets allow applications to alter and monitor the contents of the routing table by sending and receiving routing messages. The messages can be restricted to routes for a specific address family (such as AF_INET for IP destinations) by including the family value in the protocol argument when creating the socket. Otherwise, the routing socket receives all messages.
Following this event, the rtSockInit( ) routine installs the internal hook routines which the network stack uses to generate the appropriate routing messages when the routing table changes. Those hook routines use the raw_input( ) routine to relay the routing messages to all available socket endpoints with type SOCK_RAW in the PF_ROUTE domain.
The rtSockLibInit( ) routine installs the rtSockInit( ) routine when the INCLUDE_ROUTE_SOCK and INCLUDE_BSD_SOCKET constants add the routing socket interface to the system. That initialization routine then executes within the netLibInit( ) routine whenever the INCLUDE_NET_INIT constant starts the network automatically.
This event is part of the auxiliary net event class. No additional filters are available
tcp_reass-dupdata: discarding redundant TCP segmentThis event occurs when the network stack has received a TCP segment from a remote host. The tcp_reass( ) routine processes each segment which contains data to deliver that payload to the corresponding socket of type SOCK_STREAM in the PF_INET domain in the correct order. If the segment's initial sequence number matches the expected value, it is transferred to the socket's receive buffer for handling by the application. If the segment fills a gap in the data stream, the tcp_reass( ) routine also transfers the appropriate segments to the socket. Otherwise, it is added to the socket's reassembly queue or discarded. This event indicates that the newly arrived segment completely overlaps a succeeding segment on the reassembly queue. The existing segment is discarded. This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
tcp_input-shortseg: invalid segment received - insufficient headerThis event indicates that the network stack is unable to process a received TCP segment. The tcp_input( ) routine is the protocol-specific input routine which the ipintr( ) routine invokes to relay incoming data to the appropriate socket of type SOCK_STREAM in the PF_INET domain. This event occurs because the M_BLK chain containing the data does not include the minimum 40 bytes needed for the TCP and IP headers. The data is discarded after incrementing the appropriate counter in the TCP statistics.This event is part of the core net event class. No additional filters are available.
tcp_init-start: initializing TCP componentThis event occurs when the network stack is initializing all included components during startup. The Transmission Control Protocol provides reliable end-to-end delivery of data between a pair of hosts using a connection-oriented mechanism. Following this event, the tcp_init( ) routine initializes the protocol control block hash table used to track available socket endpoints and selects a starting value for the connection sequence numbers.
The usrNetProtoInit( ) routine installs the tcp_init( ) routine when the INCLUDE_TCP constant adds the protocol to the system. That initialization routine executes within the netLibInit( ) routine whenever the INCLUDE_NET_INIT constant starts the network automatically.
This event is part of the auxiliary net event class. No additional filters are available
tcp_timers-start: handle expired TCP timerThis event indicates that one of the four connection-related TCP timers has expired. The tcp_slowtimo( ) routine uses the tcp_timers( ) routine to perform the appropriate action.
Following this event, the tcp_timers( ) routine either removes the idle control block from a closed connection once the mandatory quiet period ends, transmits data when the persistence, keepalive, or retransmit timers expire, or drops the connection if it exceeds the idle time. This event is part of the auxiliary net event class. No additional filters are available.
tcp_attach-start: creating new TCP socketThis event occurs when the network stack is creating a socket endpoint of type SOCK_STREAM in the PF_INET domain. The TCP sockets allow applications to reliably send and receive data to and from a connected host.
The tcp_attach( ) routine completes the PRU_ATTACH operation (which occurs during the socket( ) routine) for the tcp_usrreq( ) generic control routine. Following this event, the tcp_attach( ) routine allocates the protocol control block associated with the socket and sets the connection state to the initial value of CLOSED.
This event is part of the core net event class. No additional filters are available.
tcp_disconnect-start: closing TCP connectionThis event indicates that the network stack is ending a TCP connection for a socket endpoint of type SOCK_STREAM in the PF_INET domain.
The tcp_disconnect( ) routine handles the PRU_DISCONNECT and PRU_DETACH operations for the tcp_usrreq( ) generic control routine. Both operations typically occurs during the close( ) routine for a TCP socket. The disconnect operation may also occur during the connect( ) routine to remove an active connection.
Following this event, the processing varies depending on the current state of the TCP socket. If the connection is not established, the tcp_disconnect( ) routine uses the tcp_close( ) routine to immediately release the associated control blocks. If the SO_LINGER socket option is set with a duration of 0, the tcp_drop( ) routine executes a hard disconnect, sending a reset message to the connected peer, releasing the control blocks, and setting the connection state to CLOSED. Otherwise, the tcp_disconnect( ) routine discards any pending data in the receive buffer and sets the connection state to the next value, either FIN_WAIT_1 (for active closes) or LAST_ACK (for passive closes).
This event is part of the auxiliary net event class. No additional filters are available.
udp_init-start: initializing UDP componentThis event occurs when the network stack is initializing all included components during startup. The User Datagram Protocol provides unreliable end-to-end delivery of data between to and from one or more hosts using a connectionless mechanism. Following this event, the udp_init( ) routine initializes the protocol control block hash table used to track available socket endpoints.
The usrNetProtoInit( ) routine installs the udp_init( ) routine when the INCLUDE_UDP constant adds the protocol to the system. That initialization routine executes within the netLibInit( ) routine whenever the INCLUDE_NET_INIT constant starts the network automatically.
This event is part of the auxiliary net event class. No additional filters are available
udp_input-cachemiss: searching for UDP socketThis event occurs when the network stack is processing an incoming UDP datagram. The udp_input( ) routine is the protocol-specific input routine which the ipintr( ) routine invokes to process each datagram for the associated sockets of type SOCK_DGRAM in the PF_INET domain. The udp_input( ) copies the payload into the receive buffers of any matching sockets, which are selected by the address and port number values stored in the associated protocol control block.
This event indicates that the address and port values of a unicast datagram do not match the cached values. To reduce potentially costly searches for the associated socket, the network stack stores the most recently used control block, assuming that a host generally receives a series of datagrams with the same endpoints. This event occurs when any of the addresses or port numbers change. Following this event, the udp_input( ) routine searches for a matching socket. This event is part of the core net event class. Additional filtering based on the port number is available with type values of 0 and 1(source or destination) and direction of 0 (input).
socreate-start: creating a socket endpointThis event occurs when the network stack is processing the socket( ) routine which creates a socket endpoint. All socket types are listed in a switchboard which accesses the necessary protocol-specific operations for a specific domain. The type parameter (and protocol parameter if non-zero) to the socket( ) routine provide the keys used to search the switchboard specified by the domain parameter.
The socreate( ) routine creates all sockets in the PF_INET and PF_ROUTE domains. Following this event, that routine validates the type and protocol arguments, creates the internal semaphores for the socket, and calls the protocol-specific control routine with the PRU_ATTACH operation to complete the socket initialization.
This event is part of the auxiliary net event class. No additional filters are available.
sobind-start: assigning local socket nameThis event occurs when the network stack is processing the bind( ) routine for a socket endpoint in the PF_INET or PF_ROUTE domains. That routine specifies the local name for a socket, which identifies the source of outgoing data and the destination of incoming data.
In the PF_INET domain, the socket name always includes a local IP address. For TCP sockets (type SOCK_STREAM) and UDP sockets (type SOCK_DGRAM) , the name also includes a port number, which is not needed for raw sockets (type SOCK_RAW). If the bind operation does not occur, the network stack will assign a local name when necessary.
Routing sockets (in the PF_ROUTE domain) do not support the bind operation, which will always return an error for those endpoints.
Following this event, the sobind( ) routine calls the protocol-specific control routine with the PRU_BIND operation to complete the local name assignment.
This event is part of the auxiliary net event class. No additional filters are available.
solisten-start: enabling socket connectionsThis event occurs when the network stack is processing the listen( ) routine for a socket endpoint in the PF_INET or PF_ROUTE domains. That routine allows sockets which use a connection-oriented mechanism to accept connection requests from remote hosts.
The listen operation is only valid for TCP sockets (type SOCK_STREAM) in the PF_INET domain. The listen( ) routine will always return an error for other endpoints.
Following this event, the solisten( ) routine calls the protocol-specific control routine with the PRU_LISTEN operation to enable remote connections.
This event is part of the auxiliary net event class. No additional filters are available.
sofree-start: releasing socket resourcesThis event occurs when the network stack is processing the close( ) routine which removes a socket endpoint.
The sofree( ) routine executes as part of the soclose( ) routine which removes socket endpoints in the PF_INET and PF_ROUTE domains. Following this event, the sofree( ) routine removes the internal semaphores and data buffers for the socket.
This event is part of the auxiliary net event class. No additional filters are available.
soclose-start: removing a socket endpointThis event occurs when the network stack is processing the close( ) routine which removes a socket endpoint.
The soclose( ) routine removes all sockets in the PF_INET and PF_ROUTE domains. Following this event, the routine terminates any pending and active connections, calls the protocol-specific control routine with the PRU_DETACH operation to remove the association with a protocol, and uses the sofree( ) routine to release the internal socket resources.
This event is part of the auxiliary net event class. No additional filters are available.
soabort-start: destroying a temporary connected socketThis event typically occurs when the network stack is processing the close( ) routine which removes a socket endpoint.
The soabort( ) routine removes all pending sockets in the PF_INET and PF_ROUTE domains. Existing sockets in these domains maintain two queues which store sockets for connections in progress and established connections awaiting user acceptance through the accept( ) routine. When a socket closes, the soabort( ) routine removes these child sockets. The routine also removes TCP sockets (type SOCK_STREAM) which are created before the connection establishment fails.
Following this event, the soabort( ) routine calls the protocol-specific control routine with the PRU_ABORT operation to end any active connection, remove the association with a protocol, and release all socket resources.
This event is part of the auxiliary net event class. No additional filters are available.
soaccept-start: retrieving a new connected socketThis event occurs when the network stack is processing the accept( ) routine for a socket endpoint in the PF_INET or PF_ROUTE domains. That routine allows sockets which use a connection-oriented mechanism to retreive child sockets associated with new connections.
The accept operation is only valid for TCP sockets (type SOCK_STREAM) in the PF_INET domain. The accept( ) routine will always return an error for other endpoints.
Following this event, the soaccept( ) routine calls the protocol-specific control routine with the PRU_ACCEPT operation to complete the initialization of the accepted child socket.
This event is part of the auxiliary net event class. No additional filters are available.
soconnect-start: assigning remote socket nameThis event occurs when the network stack is processing the connect( ) routine for a socket endpoint in the PF_INET or PF_ROUTE domains. That routine specifies the remote name for a socket, which identifies the destination of outgoing data and the source of incoming data.
In the PF_INET domain, the socket name always includes a local IP address. For TCP sockets (type SOCK_STREAM) and UDP sockets (type SOCK_DGRAM) , the name also includes a port number, which is not needed for raw sockets (type SOCK_RAW). The connect operation is required before sending or receiving data with TCP sockets. It is optional for UDP and raw sockets, and is not supported for routing sockets (in the PF_ROUTE domain). The connect( ) routine will always return an error for those endpoints.
Following this event, the soconnect( ) routine calls the protocol-specific control routine with the PRU_CONNECT operation to complete the remote name assignment. For TCP sockets, that operation also begins connecting to a remote host.
This event is part of the auxiliary net event class. No additional filters are available.
sosend-finish: transferred data to a protocolThis event indicates that the network stack is sending data using a socket endpoint in the PF_INET or PF_ROUTE domains. All of the BSD socket API send calls (or writes to the associated file descriptor) ultimately use the sosend( ) routine. That routine waits until sufficient space is available in a socket buffer (if necessary), creates an M_BLK chain including the user data, and calls the protocol-specific control routine with the PRU_SEND or PRU_SENDOOB operations to complete the data transmission.
For sockets in the PF_INET domain, the network stack attempts to send the data to a remote host using the associated protocol. For routing sockets (in the PF_ROUTE domain) the data contains a message which examines or alters the internal routing table.
This event occurs when the data was successfully transferred to the appropriate protocol. Actual delivery may not occur immediately depending on the protocol characteristics.
This event is part of the core net event class. No additional filters are available.
soreceive-finish: completed data transfer from a protocolThis event indicates that the network stack is attempting to retrieve data using a socket endpoint in the PF_INET or PF_ROUTE domains. All of the BSD socket API receive calls (or reads from the associated file descriptor) ultimately use the soreceive( ) routine. That routine copies available data into the provided buffer from an M_BLK chain provided by the protocol.
It may wait for additional data or call the protocol-specific control routine with the PRU_SENDOOB operation, depending on the user settings. When transferring data to a TCP socket, the soreceive( ) routine calls the protocol-specific control routine with the PRU_RCVD operation after transferring the available data to update the receive window for the connection.
This event occurs after transferring any available data from the appropriate protocol. It is part of the core net event class. No additional filters are available.
soshutdown-start: disabling socket connectionThis event indicates that the network stack is processing the shutdown( ) routine for a socket endpoint in the PF_INET or PF_ROUTE domains. That routine disables send or receive operations (or both) without closing the socket.
Following this event, the soshutdown( ) routine removes the receive buffer and associated semaphore (if disabling receives) and calls the protocol-specific control routine with the PRU_SHUTDOWN operation (if disabling sends).
This event is part of the auxiliary net event class. No additional filters are available.
eventReceive -- receive a VxWorks event
eventSend -- send a VxWorks event
