Follow the data from the network interface to the Feed Engine, Handler processing, and application callbacks. A packet capture, a connected feed, and a book update establish different things.
Dashed arrows mark transitions to verify. These are observation points for the standard Socket Feed Engine, not separate threads. For kernel-bypass reception, see Solarflare Feed Engine.
Before changing network settings:
An OnixS::CME::MDH::Issue::ReceiveTimeout warning (No data received within N seconds) reports that the feed received no packets within its receive interval. For the source feed named in the warning, follow No relevant traffic at the host interface, then Traffic is visible, but processing is absent if traffic is visible. A timeout can switch feeds when a failover layout is configured, so recheck which feed is connected.
For the standard Socket Feed Engine, use the chart after checking configuration and engine execution, confirming that the feed is currently connected, and establishing when traffic is expected. Select a diagnostic box to open its section.
Start with the currently connected incremental feeds. Confirm each feed's current connection/join from the latest connection/disconnection logs or the OnixS::CME::MDH::ChannelFeedListener::onFeedConnected and OnixS::CME::MDH::ChannelFeedListener::onFeedDisconnected events before interpreting an empty capture.
Instrument-definition and MBP/MBO snapshot feeds are connected for their recovery procedures and are normally disconnected afterwards; see Market State Recovery. With the default recovery feed layout, feed A is primary and feed B is used after failover. An enabled endpoint need not currently be joined.
Capture while the application is running, the feed is connected and traffic is expected. Repeat for the currently connected A/B endpoints; seeing A does not establish that B works. Replace every angle-bracket placeholder with the recorded interface, multicast group or UDP port.
On Linux, with tcpdump installed and capture privileges, run:
Stop with Ctrl+C after the observation interval. Matching lines show traffic at that capture point, including its source IP. Capture drop counts describe the capture mechanism, not the Handler's socket; see the tcpdump manual.
On Windows, use Wireshark with its capture driver installed and the required capture permissions. Select the intended adapter and apply this display filter, replacing the placeholders:
See Wireshark capture prerequisites and display filters.
If no matching traffic appears for a feed that remains connected, verify the adapter and filter first. Then check the provider's feed availability, entitlement, multicast routing and switch group membership with the network administrator. Keep the receiver running so its multicast joins can be observed. A successful ping to a router tests unicast reachability, not delivery of the configured multicast group and port. If matching traffic appears, check feed and Handler processing. Capture visibility does not prove socket delivery.
With the standard Socket Feed Engine, check that the process has the expected UDP endpoint while the feed is connected. On Linux, sudo ss -unap lists UDP sockets and owning processes. On Windows, use PowerShell with the NetTCPIP module, replacing <handler-pid>:
Compare the port and owning process, allowing for wildcard local addresses. A bound endpoint does not prove multicast membership or packet delivery. If it is absent, inspect connection errors and confirm the correct process and active feed. See Get-NetUDPEndpoint.
If endpoint, interface and engine checks agree but reception remains absent, inspect host filtering with the administrator. Firewall logs or drop counters showing blocked feed traffic can justify a narrow rule for the required source, destination group, UDP port and interface/application. Rule changes require administrative privileges; keep the firewall enabled rather than disabling it as a general diagnostic step.
When captured packets arrive on one interface but the route to their source IP uses another, strict reverse-path filtering is a possible cause. With iproute2 and sysctl available, read:
The route lookup is an initial check; policy routing may require further analysis. The effective rp_filter value is the maximum of all and the receiving interface: 0 disables source validation, 1 requires the best reverse path to use that interface, and 2 requires the source to be reachable through some interface. default supplies defaults for newly created interfaces; it does not describe the effective policy on an existing interface. See the Linux kernel documentation.
If routing and filtering evidence explains the failure, have the administrator correct the route or choose an appropriate interface policy. Loose mode can accommodate asymmetric routing while retaining source reachability checks.
Retest feed packet reception after an agreed change.
Record issue codes, feed sources, sequence ranges and recovery timings. An OnixS::CME::MDH::Issue::SequenceError warning identifies a gap in the Handler's incremental sequence; it does not locate the loss in the network, NIC, socket buffers or recovery queue.
Use the measured bottleneck to choose the next action: investigate upstream loss, correct a missing feed, reduce processing delays, or review the relevant buffer/queue limit. Increasing a recovery queue limit does not repair socket loss or a processing bottleneck.
For further investigation, retain the effective configuration, SDK version, timestamps, issue codes, feed traces and counter changes for OnixS Support.
