A Modbus UDP master transmits locally but the Linux listener stays silent when the destination changes to a remote 192.168.xx.xx address. Follow the datagram from the communicator process to the receiving socket. The successful loopback and comparison-application tests isolate different portions of that path; neither proves that the communicator's remote datagram leaves the source host.
Where can the UDP datagram stop?
The configured sender uses master behavior, local port 10004, remote port 10005, and communicator software version 5.0.0.2. Its intended path is the communicator process, local UDP socket, host network policy, selected interface, network hops, Linux host policy, and the listening socket.
| Field | Configured value | Meaning |
|---|---|---|
| Role | Master | Originates a request when its configured trigger or polling schedule runs |
| Local port | 10004 |
UDP source port; normally the destination port for a reply |
| Remote address | 192.168.xx.xx |
Target host; substitute the complete address during testing |
| Remote port | 10005 |
UDP destination port on the Linux host |
| Transmit timing | Not specified | Confirm whether transmission is cyclic, event-driven, or initiated by a configured request |
A destination of 127.0.0.1 terminates inside the source host. It bypasses the physical interface, address resolution, gateway, switches, routers, and remote Linux system. Local receipt therefore proves that the communicator can construct and submit a UDP datagram, but it does not test remote interface selection or delivery.
What do the comparison tests actually prove?
| Test | Observed result | Path proven | Remaining fault domain |
|---|---|---|---|
Communicator to 192.168.xx.xx:10005
|
No data displayed by nc -l -u -p 10005
|
No end-to-end delivery proven | Sender, interface, network, receiver policy, or listener |
| Hercules to the same remote destination | Data arrives | The hosts have a usable UDP path for that application's traffic | Application-specific policy, binding, source port, or packet differences |
Communicator to 127.0.0.1
|
Data arrives locally | Communicator generation and local UDP stack | All off-host portions of the path |
| Firewall disabled | No improvement | The tested firewall control did not clear the fault | Other filters, application policy, binding, routing, or remote rules |
Hercules and the communicator are different processes and may produce different five-tuples: source address, source port, destination address, destination port, and protocol. A security rule can permit one executable or source port while rejecting another. Disabling one firewall interface also does not remove endpoint filtering performed by another service.
Which diagnostic approach best separates the causes?
| Approach | What it answers | Limitation |
|---|---|---|
| Change firewall rules repeatedly | Whether a particular rule affects delivery | Does not reveal whether the communicator transmitted anything |
| Repeat application-level listener tests | Whether payload reaches the selected socket | Cannot distinguish network loss from listener binding or display behavior |
| Capture at both endpoints | Whether the datagram leaves the sender and reaches Linux, including its addresses and ports | Requires access to both interfaces and a repeatable request trigger |
Use endpoint captures as the primary method. Layer one comes first: confirm that the intended source interface is up and that its route selects the expected gateway or directly connected subnet. Then follow one request through each boundary. A source capture is the decisive split: no packet means the fault remains in the communicator or source host; a visible outbound packet moves the investigation toward the network or receiver.
How do you follow the packet?
- Establish a repeatable transmission trigger. A master does not create useful traffic merely because ports are configured; activate the configured poll, request, or event and record when it should execute.
- Verify the active settings after restarting the communicator: master behavior, local port
10004, complete remote address, and remote port10005. Confirm that the edited configuration is the one currently running. - Check the selected source interface, link state, IP configuration, and route to the actual remote address. If the target is outside the local subnet, verify that the route selects the intended gateway.
- Capture on the source interface while triggering one request. Filter for UDP traffic to the remote host and destination port
10005. Inspect the actual source address and confirm source port10004. - If no packet appears, compare the working loopback test with the remote configuration. Check whether the communicator binds only to loopback, selects the wrong adapter, lacks an application-specific network permission, or rejects the remote address before socket transmission.
- If the packet leaves the source, capture on the Linux interface. A packet absent there points to an intervening route, access rule, or filter. Compare the communicator datagram's five-tuple with the working Hercules datagram; the source port may differ even when the destination is identical.
- If Linux captures the datagram but
nc -l -u -p 10005remains silent, verify that the listener is bound to the intended interface and that no other process owns UDP port10005. Also confirm that the installedncvariant accepts the shown options.
Which fix matches each capture result?
| Capture result | Correction |
|---|---|
| No remote datagram on the source interface | Correct the communicator's remote address, transmission trigger, adapter binding, or application-specific outbound permission. Restart it after applying the active configuration. |
| Datagram uses an unexpected source address | Select the intended outbound interface or correct the host route. Match any security rule to the address actually used. |
Datagram leaves with source port other than 10004
|
Recheck the local-port setting and whether another process already owns that port. |
| Source sees it, Linux does not | Inspect host and network filters for UDP destination port 10005, including rules that distinguish source port 10004. |
| Linux sees it, listener does not | Correct the listener binding or port conflict; keep the receiver open before triggering the request. |
| Request arrives but no reply returns | Verify the responder and permit the return datagram to the master's address and UDP port 10004. |
The strongest initial fault candidates are source-interface selection and process-specific filtering because loopback succeeds while the communicator's remote path does not. The working Hercules test lowers the probability of a general connectivity failure, but it does not eliminate rules keyed to executable, source address, or source port.
How do you verify transport and Modbus separately?
First verify UDP transport: capture one datagram leaving the communicator and the same datagram arriving on Linux with destination port 10005. Compare payload length and bytes so an unrelated UDP packet cannot produce a false pass.
Next verify the application exchange. The receiver must recognize the configured Modbus-over-UDP framing and generate the intended response. Capture that response leaving the remote host from port 10005 and arriving at the master on local port 10004. A successful nc display proves UDP payload delivery only; it does not prove that a Modbus responder accepted the request.
FAQ
How do I know whether the Modbus UDP master transmitted?
Trigger a configured request and capture the intended source interface. Look for a UDP datagram addressed to the remote host on destination port 10005, with local source port 10004.
How do I explain UDP working in Hercules but not the communicator?
Compare the two datagrams' executable policy, source address, source port, destination address, and destination port. An application-specific filter, adapter binding, or source-port rule can pass Hercules while blocking communicator software version 5.0.0.2.
How do I verify the final Modbus UDP fix?
Capture the request at both endpoints, then capture the reply leaving remote port 10005 and arriving at local port 10004; finally confirm that the master accepts the response for the triggered request.