 |
Synergy Software Package User's Manual
|
|
Synergy Software Package User's Manual
|
TheNetX™ and NetX Duo™ source modules allow the developer to modify some of the key properties that control NetX operations. Adding the NetX or NetX Duo source component enables you in the Synergy configurator environment to customize the NetX and NetX Duo libraries, change values from default settings, and enable or disable certain features. Otherwise they must use the prebuilt NetX or NetX Duo library. In most projects beyond simple socket programs, you will typically want to customize their NetX or NetX Duo environment. Note that the ThreadX® source component is automatically added when adding a NetX or NetX Duo source component.
Without adding the NetX or NetX Duo source component, the Synergy ISDE configurator will use a prebuilt library with NetX and NetX Duo default settings.
There are no APIs associated with the NetX or NetX Duo source module. This module is used to configure various NetX or NetX Duo properties.INote: Lower level drivers may return Common Error Codes. Refer to the SSP User's Manual, API References for the associated module for a definition of all relevant status return values.
Using the NetX or NetX Duo source module is a bit different than using other SSP modules. The NetX or NetX Duo source module is used to configure networking operations; it doesn't provide API functions, callbacks or other typical module functions. There is no typical operational overview of the NetX or NetX Duo module. Refer to the NetX User's Manual, available from the Synergy Gallery for the operational details of NetX.
If TraceX is enabled in the ThreadX source component, it is automatically included when adding NetX or NetX Duo source components. The project containing the ThreadX and NetX, or NetX Duo library must be rebuilt. Otherwise the TraceX macros that log events will not be executed.
A network project generated in the e2 studio configurator will automatically include an object Add NetX Source.
To add the NetX or NetX Duo source component to a project, click on the Add NetX Source (optional) or Add NetX Duo Source (optional) object) for NetX Duo in the e2 studio configurator and choose New. If there are multiple Add NetX Source boxes, all of them will be updated automatically. Note that a ThreadX source component is added automatically.
The list of properties below may not match the order of the NetX or NetX Duo property table. They are grouped according to general categories; ARP, TCP and IGMP for easier reference.
This section describes the configurable properties available to the NetX or NetX Duo source module and in what cases they can be changed from the default values to customize NetX or NetX Duo operations.
These are some important notes that need to be understood by the developer before diving into the details of the large number of properties available for the NetX or Net Duo source module.
Default Settings. Most default settings are derived from RFC recommendations for the protocol relevant to the property.
IP Helper Thread Stack Size (bytes) – default value 1024. This is the stack size of the IP thread task which processes application NetX API calls, periodic events and deferred ISR events; packets received. There are some cases where a larger stack size will be required. Optimal stack size is usually determined empirically for an individual application.
IP fragmentation – default value enabled. To enable/disable fragmentation use the NetX/NetX Duo Source Fragmentation Option property. This property in the IP instance component is being deprecated.
__IP Helper Thread Priority – default value 3.__ This is the priority at which the IP thread task operates. Under some circumstances it might work best to increase this to 1 (highest valid priority). For example, if there are multiple network application thread tasks (DNS, HTTP, DHCP) in a project, then an IP helper thread at a higher priority (higher than network application threads) can service all network operations with higher priority, effectively improving responsiveness of the application thread tasks.
Error Checking – default value enabled. It is generally enabled during development and debugging phase, and disabled when building a release version. When enabled, the NetX and NetX Duo include error checking services that will checks input and other parameters before calling the actual API. Some of the things it checks for are:
nx_tcp_socket_receive API.These last two checks guard against an application using a different version of the NetX or NetX Duo library than the application is using.
Static Routing – default value disabled allows certain destinations to be routed through a specific router. Normally a packet being transmitted is routed through the IP instance gateway/router as the next hop. When static routing is enabled, NetX checks the static routing table to determine if a packet's next hop address should go through a specific router rather than the IP instance gateway. The static routing table is limited to NX_IP_ROUTING_TABLE_SIZE entries, and there are various API such as nx_ip_static_route_add for managing the routing table. This is not commonly used but there are certain situations where it is necessary.
Physical Header and Physical Trailer – default value 16 and 4 bytes respectively: the type of network medium determines the physical (sometimes referred to as frame) header. An Ethernet network has a header of size 16 bytes. Wi-Fi has a larger header. The physical trailer is currently not being used for Ethernet but may need to be configured, depending on the physical network being used by the application. If the physical header is not set correctly, packets will not be assembled and most NetX packet send and receive services will not function correctly.
Maximum Listen Requests – default value 10 – This value is used by the TCP server applications to define the TCP listen queue size. When a TCP server socket binds a port (using the nx_tcp_server_socket_listen API), it requests a listen request on the IP instance. When it unlistens on that port, (using the nx_tcp_server_socket_unlisten API) the listen request is released, and the port is available to listen by another socket. This default value is not usually changed.
Driver Deferred Processing – default value Enabled – this feature enables the IP thread task to defer handling of the packet receive interrupts to the context of the IP thread task. Otherwise a packet receive event is handled in the context of the interrupt. This might lead to faster response to a specific packet but makes the overall system performance slower.
Loopback Interface – default value Enabled – if enabled, the NetX creates a loopback interface for sending and receiving packets to itself. Note that this is not counted as a physical interface. An application needs to be concerned about the number of network interfaces if they are using multiple physical interfaces. The loopback interface is not counted as a physical network interface (see below).
Maximum Physical Interfaces – default value 1 – The default is one network interface, generally referred to as the primary interface. The IP instance keeps a table of interfaces, and the primary interface is at index 0. For secondary interface(s), the Maximum Physical Interface value should be incremented by one for each secondary interface. Typical scenarios for multiple interface use is a router, with a local or private network on one interface and a global or public interface on the other. Another scenario is a device with two different network interfaces; ethernet and Wi-Fi.
To attach secondary interfaces to the IP instance, use the nx_ip_interface_attach API. When an interface is not referenced in an API, the action is on the primary interface. For example, nx_ip_status_check operates on the primary interface, while nx_ip_interface_status_checkperforms the operation on a specific interface.
Note: Some developers have used multiple IP instances to handle multiple physical networks. It is strongly not recommended to create multiple IP instances!
NAT (available in NetX Duo only) – default value disabled – NAT is a protocol that allows NetX Duo to map packets between the local/private and public/global networks, acting as a kind of router. To do this, the NetX Duo must be enabled to forward packets from a local host onto the global network with the host's global IP address and a port that the NetX Duo host determines. When NAT is enabled on the IP instance, NetX Duo can now forward packets in the manner. Note that NAT also requires that Maximum Physical Interfaces must be set to 2. SWIOT-5387 has an example project for setting up NAT.
Fragmentation option – default value enabled – Fragmentation occurs when the packet data exceeds the device MTU (maximum transfer unit) which is most typically 1518 bytes including frame header for Ethernet networks. An application should avoid fragmentation at the IP layer if possible, although there is not much one can do on the receiving side.
Another aspect of fragmentation to consider is the potential to deplete the packet pool used to receive packet fragments. When NetX is receiving many packet fragments, the packet pool used to receive these packets can easily be depleted, since packets cannot be returned to the packet pool until the entire packet is assembled by the IP layer and forwarded to the application. This can be remedied by increasing the number of packets in the packet pool at start up time (cannot be done at run time), if the board has sufficient memory to do so.
Packet Header Pad Size – default value 0 (no padding) – Hardware operations on some boards require memory to be certain cache line is aligned. In those cases, the size of a NetX or NetX Duo packet instance must be aligned based on hardware requirements. For example, if the hardware requires the starting address of the data buffer to be 32-byte aligned and the size of the NX_PACKET header size is 56-bytes, defining the Packet Header ad size to be 8, can bring the starting address of the packet buffer to be 32-byte aligned.
Checksums – default value enabled – In NetX and NetX Duo, checksums for incoming (RX) and outgoing (TX) packets can be separately enabled or disabled. Checksums should not be disabled unless the RFC for that particular network protocol; UDP, TCP, or ICMP, indicate a zero checksum is allowable. Checksums generally need to be enabled. Disabling checksums might increase throughput but might also cause packets to be dropped by the other side of a connection.
Extended Notify Support – default value Disabled – When enabled, NetX will notify the application of various events related to TCP socket connections, above and beyond what NetX normally does (e.g. the callbacks specified in the nx_tcp_socket_receive_notify and nx_udp_socket_receive_notify APIs).
Extended Notify Support is required by NetX and NetX Duo BSD sockets.
The APIs enabled for this feature are listed below. They allow NetX to notify the application when NetX receives a TCP connection request, a TCP connection is completed, a TCP disconnect on a socket is completed, and to set the TCP socket state in the timed wait state. This is necessary for a TCP to operate in a non-blocking context.
nx_tcp_socket_syn_received_notify
nx_tcp_establish_notify
nx_tcp_disconnect_complete_notify
nx_tcp_timed_wait_callback
Source Address Check – default value Disabled – This checks all incoming packets for an invalid IP address. Specifically, it checks if 1) the IP address bits masked with the network mask does not equal the 1s complement of the network mask; 0xFF, 2) the IP address is not zero and the unmasked address bits do not equal zero, and 3) the address is not type D address (0xE0000000). This extra bit of processing at the IP level in NetX incurs a small performance penalty.
ICMP Address Check – default value Disabled – When enabled, the source address of ICMP packet is checked.
Maximum String Length – default value 1024 – This option specifies the maximum string length.
Enable random IP id – default value Disabled – When enabled, the default IP id is increased by one for each packet.
Enable VLAN – default value Disabled – When enabled, the VLAN feature is enabled.
Maximum multicast groups – default value 7 – Defines the size of the multicast table in effect set the limit on the number of multicast groups that can be joined. Not generally modified.
IGMPV – default value Enabled – IGMPv2 is enabled by default. IGMPv2, unlike IGMPv1, allows group-specific join queries, leave messages and a method for determining which router will forward queries (instead of all IGMP routers on the network).
ARP cache storage units – default in Bytes – Defines the ARP storage type in bytes. User can also select the option in Entries to define the number of ARP entries in table which will be aligned to the size of ARP.
ARP Cache size (in storage units) – default value 520 – Defines the size of the ARP cache in bytes. If user selects the storage units in Entries, then the value should be an integer. If user selects the storage units in Bytes, then the value should be a multiple of size of ARP (52 Bytes). This table holds all the ARP entries. If a table is full, no more ARP entries can be added till existing entries 'age' (see explanation of ARP Expiration Rate in this section) and are removed. There are some configurable options listed with the NetX/Duo Source element that can affect the number of ARP entries added to the table, such as ARP Auto ARP Entry and ARP Expiration Rate defined in this section.
The ARP cache size may need to be increased if the node is expected to communicate with large amount of the nodes on its local network.
ARP Auto ARP Entry – default value Enabled – This allows NetX to add an ARP entry when an ARP packet is received for which the table has no matching IP address. This will happen regardless of whether the response was directed to/from the NetX device. The idea behind auto ARP entry is to increase the efficiency of NetX by reducing the need to send ARP queries if the data is already in its ARP table. The downside is the ARP table can fill up and no more new ARP queries can be added. To prevent this, disable this feature. When disabled, NetX will only save ARP entries if the request was generated by NetX or directed to the NetX device.
This option is not required for most applications.
Alternatively, one can leave the Auto ARP Entry enabled, and set the expiration rate to non-zero to guarantee the entries will expire (and therefore be deleted) if not used. See ARP Expiration Rate for more details on the table entry expiration in this section.
ARP Expiration Rate – default value 0 seconds – By default ARP entries in NetX are static. They have no expiration rate and thus do not age. Otherwise, as an ARP entry ages, its timeout value decreases. When the timeout value reaches zero, the ARP entry is removed. If a new query pertaining to that ARP entry is received, the timeout value is reset. The timeout is also reset if the entry is accessed by the IP layer to transmit a packet. To determine if entries are being aged/deleted, an application can call the nx_arp_info_get API for statistics on aged entries as well as other useful statistics on ARP table management.
ARP Update Rate – default value 10 seconds – This is the interval between retransmission of ARP queries. When the number of retries reaches the ARP Maximum Retries, NetX abandons the attempt to find a physical mapping of IP address to a MAC address. There is no side effect to reducing this value to a smaller value.
ARP Maximum Queue Depth – default value 4 – This is the maximum number of IPv4 packets from the application trying to transmit packets for which NetX has no MAC address mapping. These packets are enqueued while NetX tries to find the MAC address mapping. When the queue is full, the oldest packet is removed. To determine if this is happening, an application can check the nx_ip_transmit_resource_errors field in the IP instance data structure using the Expressions view in e2 studio. Currently there is no API for obtaining this statistic.
This value does not need to be changed except under exceptional conditions. It is unusual for the queue to fill up using this default value. If the destination IP address is alive, an ARP response will be received by NetX and corresponding packets on the ARP queue will be transmitted. If the destination IP is dead, it does not make sense to queue any more packets to be sent to that address.
ARP Maximum Retries – default value 18 – This is the number of times NetX retransmits an ARP query for an IP address mapping before it gives up. There is no side effect to reducing this value to a smaller value.
ARP Defend by Reply – default value Disabled – This is intended for use with hosts who need to keep their current IP address.
Normally when a host gets an ARP packet with a matching source IP address but different MAC address, NetX may broadcast an ARP request to announce that it owns the IP address. It can only do so if it has not received a conflicting ARP packet within the interval of time specified by the ARP Defend Interval property (defined in this section). If it does send a defend reply, it resets the timeout to wait before responding to the next ARP conflict, if one occurs. If this is not the first conflicting ARP packet the host has seen, and the time recorded for the previous conflicting ARP packet is within the ARP Defend Interval, then the host MUST immediately cease using this address. This is necessary to ensure that two hosts do not get stuck in an endless loop with both hosts trying to defend the same address.
For more details on ARP conflicts, see RFC 5227 IPv4 Address Conflicts Section 2.4 (b).
When ARP Defend by Reply is defined, an ARP reply is broadcast in addition to the one sent once the ARP Defend Interval expires. There is no requirement for a wait interval to expire for this ARP defend packet. This property is used because Windows XP ignores ARP request packets sent out when the ARP Defend Interval timeout expires.
ARP Defend Interval – default value 10 seconds – this is the interval during a NetX host that may not send an ARP defend packet if it receives a conflict ARP packet. 10 seconds is the default value recommended in the RFC 5227 for handling IPv4 address conflicts. After NetX sends the ARP defend packet, it resets the timeout back to this value.
ARP Mac Change Notification – default value Disabled – If NetX receives an ARP packet whose MAC address matches an entry in the ARP cache table, and this feature is enabled, NetX will call the ARP collision handler for the application to examine the packet and decide what to do with it. Without this feature, NetX will update the entry in its ARP table to the new MAC address. This behavior, that is a normal ARP protocol, can be taken advantage of in what is called the man in the middle attack, ARP cache poisoning or spoofing. This enables an attacker to redirect packets from one host to another by altering the MAC address information in the ARP table. NetX has internal handlers for these situations so applications need not handle them.
Regarding the following group of rate setting properties, NetX timing is based on the NX_IP_PERIODIC_RATE setting. NX_IP_PERIODIC_RATE is derived directly from TX_TIMER_TICKS_PER_SECOND. The latter defaults to 100 but can be user defined, optionally in tx_port.h. If it is, NX_IP_PERIODIC_RATE is set to that value. If it is not, then NetX defaults it to 100 ticks (10 msec/tick).
TCP Fast Timer Rate – default value 10 – This determines the interval on how the fast timer periodic executes in NetX. If set to 10, and NX_IP_PERIODIC_RATE is set to 100, the fast periodic timer executes every 100 msec.
This timer is used to decrement the delayed ACK timeout (see TCP ACK Timer Rate) and the socket timeout (see TCP Transmit Timer Rate) for when to retransmit the ACK and data packets respectively. Increasing the TCP Faster Timer Rate shortens intervals between how the fast timer executes. In fact, it can potentially degrade performance for the extra overhead of processing the fast periodic timer more often.
TCP Retransmit Timer Rate – default value 1 (1 second) – This value is used to set the TCP socket timeout value. When a TCP socket sends or receives a SYN packet, or sends a data packet, it waits for an acknowledgment (ACK). If the socket timeout expires before receiving an ACK, the timeout is reset (and the packet retransmitted) up to a maximum of the TCP Maximum Retries. After that, NetX closes the connection.
It is generally not recommended to reduce this value. It will not make the TCP transactions happen quicker.
TCP ACK Timer Rate – default value 5 – This determines the interval between what NetX retransmits an ACK for missing data (or ACK probe). The NetX fast periodic timer decrements this timeout on each iteration of the faster timer periodic. If it expires, NetX sends another ACK packet. If a data packet is received, NetX resets the timeout. When data is sent from the NetX, it will also reset the timeout. If it expires, NetX increments the number of retries and resends an ACK. When the maximum number retries is reached (see TCP Maximum Retries defined in this section), NetX closes the connection.
A setting of 5, with NX_IP_PERIODIC_RATE set to 100, yields a delayed timeout of 200 msec. The greater the NX_TCP_ACK_TIMER_RATE the smaller the ACK timeout. Increasing the value does not increase performance or response time to the NetX ACK. It only sends them after a shorter interval.
TCP Maximum Retries – default value 10 – When a socket timeout expires without receiving a response from the TCP peer, the socket timeout is reset up until the number of retries equals the TCP Maximum Retries.
TCP Retry Shift – default value 0 – This is the bit shift applied to the retransmission interval. The default value of zero keeps the interval constant between socket retries (to get a response from the TCP peer). If it is set to 1, it doubles the interval; bit-shifts the timeout value by 1. This value is not often modified.
TCP Maximum TX Queue – default value 20 – This is the maximum number of packets that NetX will enqueue on a TCP socket for transmission and retransmission. A packet is enqueued when the socket is waiting to receive an ACK for the data, or it is waiting for the receive window of the other side to increase so it can send the data. For applications using smaller packet pools; limited memory resources, this value can be reduced to prevent packet pool depletion where a significant number of packets are sitting on the transmit queue, unavailable for other packet transmissions.
When the TCP socket has reached the maximum number of packets it can enqueue, the tcp socket will send call returns an NX_TCP_QUEUE_DEPTH error. If it cannot send a packet because the TCP receive window is too small it returns an NX_WINDOW_OVERFLOW error.
TCP Keepalive – default value disabled – The Keepalive feature starts a timer on the TCP socket in the established state; connected to a peer. When the timer expires, NetX sends a Keepalive ACK to the peer. Receiving a SYN or ACK packet, an ACK packet in response to NetX device's Keep Alive Ack, or any TCP packet with a valid sequence number resets the timer and the retry count.
When NetX initiates a Keepalive ACK exchange, it sends a Keepalive ACK packet with the ACK packet's sequence number decreased by one. This is how a TCP peer can distinguish a keepalive ACK from an ACK that indicates 1 byte of data has been sent.
When Keepalive is enabled on a socket, NetX also periodically checks if the other side has sent a Keepalive ACK.
If the Keepalive timer expires without a response from the peer, the number of Keepalive retries is incremented. If the retries reaches the TCP Keepalive Retries maximum, NetX deems the connection broken and terminates it. Without Keepalive, a TCP connection can persist indefinitely if neither side is transmitting a packet. In that situation, there is no way to know if the socket connection should be closed or remain open.
TCP Keepalive Retries – default value 10 - After 10 tries to get a response to a keepalive ACK, NetX resets closes the connection.
TCP Keepalive Initial – default value 7200 seconds (2 hours) – this is the interval before the first Keepalive is sent when a connection is completed, or a response is received from a previously sent Keepalive packet.
TCP Keepalive Retry – default value 75 seconds – NetX waits for the time specified by this option before resending another Keepalive packet, unless it has received a response to a previously sent Keepalive packet from the TCP peer.
TCP Window Scaling – default value Disabled – This feature allows a TCP receive window to exceed 65k up to a theoretical maximum of 1,073,725,440 bytes. When a NetX TCP Client socket initiates a connection, NetX computes a scaling factor based on the window size (set when the TCP socket is created). The window scaling values are exchanged during the TCP connection establishment phase. Note that the lack of window scaling option in peer's SYN packet is an indication that the peer does not support window scaling. In this situation, window scaling is not used for this connection.
TCP Maximum Out of Order Packets – default value disabled – If enabled, this option sets the maximum number of out of order packets that can be stored on the TCP socket receive queue. Subsequent out of order packets received are dropped if the socket receive queue has the maximum out of order packets. Eventually the NetX host should send an ACK indicating the missing data to the sender and get the dropped packet retransmitted. At this point, NetX can quickly process all the rest of the data on the receive queue and release the packets.
This feature is useful in the following scenario:
If a packet is lost or dropped, and the sender keeps sending packets, the TCP socket must enqueue all the packets back to the missing packet on its receive queue. It cannot release any because it is waiting for the missing data to be retransmitted. If the depth of the receive queue is not limited, this can starve the packet pool, rendering the NetX host effectively unresponsive. This can happen in a bursty data transmission, where many packets are sent by the TCP peer. A dropped packet may subsequently lead to many packets enqueued on the TCP receive queue.
TCP MSS Minimum – default value 128 – MSS, or maximum segment size is the largest amount of TCP data that will not require fragmentation. The minimum MSS is the lowest MSS that a NetX TCP socket will accept from a TCP peer. If the MSS parsed from the TCP header option data is below this value, the connection is dropped.
The intended usage of this is when an application wants to reject connections with small MSS values.
TCP ACK every N Packets – default is disabled – To enable this feature, enter a positive number. NetX sends an ACK out for every other data packet with new data, not retransmitted data. This is usually the optimal setting to minimize network traffic, packet processing and keep the TCP peer advertise window up to date. Note that if TCP Immediate ACK is enabled, this value is overridden; set to 1 automatically. Increasing the value increases the possibility the other side must wait on the nth ACK to know that the advertise window has increased enough to send more data. This may result in slower network throughput. The optimal setting is generally based on testing.
This ratio of ACKs per N packets is associated with the delayed ACK logic in TCP. For applications like Telnet, a higher N can greatly optimize the work on the Telnet Server receiving many 1 byte packets.
TCP Immediate ACK – default value disabled – If enabled, NetX sends an ACK for every packet of new data received. This is useful where a delayed ACK is not desirable.
Reset Disconnect – default value Enabled – When enabled, this allows an application to call a disconnect on a TCP socket with a zero wait option without sending a RST packet. It simply sends a FIN packet to indicate it is initiating a disconnection and closes the socket. It does not wait for an ACK or FIN ACK from the TCP peer. This is useful for hosts that do not want to wait to close a socket, such as servers wishing to free up sockets for the next Client request, and can do so without indicating something is wrong like a RST packet usually does.
RX Size Checking – default value Enabled – If enabled, NetX checks that a received packet has at least enough room for the IP or transport layer header; TCP, UDP, IGMP and ICMP depending on where the packet is being processed. In the IP layer, for example, NetX checks if the packet has at least enough room for the IP header. In the TCP layer, NetX checks if the packet has at least enough room for the TCP header.
As a packet travels up the stack in NetX, the packet prepend pointer and packet length are adjusted for each network layer. When the packet passes from the IP layer to the TCP layer, it moves the prepend pointer to the start of the TCP header, and subtracts the size of the packet length by the size of the IP layer. Similarly, going from the TCP layer to the application layer, the prepend pointer is moved past the TCP header to the application data or header in the case of something like an HTTP packet. The packet length is subtracted by the size of the TCP header.
This internal manipulation of the packet eliminates the need for the application adjust pointers and data size. An application or NetX protocol will typically make a socket call such as the nx_tcp_socket_receive API. If any packets are waiting on a socket receive queue, the application receives the packet and knows where the data is located and how much there is. The application can use the_nx_packet_length_getAPI (preferably) to obtain the packet data size, or access the nx_packet_length field in the NX_PACKET instance directly.
TCP/IP offload feature – default value disabled – If enabled, TCP/IP offload feature will be enabled. This feature enables NetX Duo to support a network interface card that offers TCP/IP service on the hardware. Certain WiFi modules offer TCP/IP processing on the module, and applications on MCU send and receive packets through APIs to access its TCP/IP stack. With this feature enabled, developers can run native NetX Duo applications directly.
Configure the "Enable the extra capability of the link driver" property to define NX_ENABLE_INTERFACE_CAPABILITY to enable the TCP/IP offload feature. This property is disabled by default.
Disable Assertion – default value disabled – If enabled, Assert is disabled.
Assert Fail – default value disabled – If enabled, the assert fail process is defined.
If enabled, NetX keeps statistics on its internal operations. These statistics are at the component level, like IP, TCP, ARP and Packet (pool). For TCP and UDP, there are statistics for all TCP/UDP transmissions and statistics per socket. Disabling these statistics reduces processing time slightly.
The value of these statistics is to be able to diagnose problems or optimize network performance without having to stop or interrupt program flow, or write tedious debug code.
Examples:
nx_packet_pool_info_get.c
If an application does not appear to be sending or transmitting packets, check the nx_packet_pool_empty_requests statistic. This is incremented every time nx_packet_allocatefails because no packets are in the packet pool. This is helpful if nx_packet_allocate is called from a void function or by a NetX protocol which may return a different value.
nx_ip_info_get.c
If an application is not receiving data, but packets are visible on a third-party packet trace, check the nx_ip_total_packets_received statistic to see if the data is forwarded at least as far as the IP level. Similarly, for not seeing packets from the NetX device on a packet trace is to check the nx_ip_total_packets_sent statistic.
The following is a partial list APIs for NetX statistics:
IP info – Statistics at the level of the IP layer receiving packets from the driver, and forwarding packets from the transport layer to the driver:
nx_ip_interface_info_get.c is the same but specific to the specified interface.
ARP Info – Statistics on ARP packets sent and received, and ARP table statistics:
Packet Pool Info – Statistics on available packets, empty packet (pool) requests, and invalid packet releases; invalid packet pool or packet pointer supplied.
TCP Info – Statistics on the total number of TCP packets sent/received, number of connections and disconnections, dropped and retransmitted packets. The socket specific API includes the receive window size.
UDP Info – Statistics on the total number of UDP packets sent/received, dropped packets, improperly formed packets to send or receive. The socket specific API does not include the count of invalid packets received.
ICMP Info – Satistics on control message transmission, including count of unsupported ICMP messages, ping requests that timed out, and responses to ping request.
IGMP Info – Statics on multicast groups joined, IGMP queries received, and IGMP reports sent.