eclipse-threadx / netxduo

Eclipse ThreadX - NetXDuo is an advanced, industrial-grade TCP/IP network stack designed specifically for deeply embedded real-time and IoT applications
https://github.com/eclipse-threadx/rtos-docs/blob/main/rtos-docs/netx-duo/index.md
MIT License
230 stars 131 forks source link

PTP client stuck in non-responsive state #175

Open leobbditestcom opened 1 year ago

leobbditestcom commented 1 year ago

When the first message seen by the NetX Duo PTP client is not an "Announce" message, the code begins to cycle through a state sequence which keeps it from entering the "Delay_request" sequence. This is prevented by entering NX_PTP_CLIENT_STATE_LISTENING when this happens. The following changes do this:

@@ -1321,10 +1343,14 @@ NX_PTP_MSG_HEADER hdr;
     {
         if ((client_ptr -> nx_ptp_client_state != NX_PTP_CLIENT_STATE_WAIT_FOLLOW_UP) ||
             (client_ptr -> nx_ptp_client_sync_id != hdr.sequenceId) ||
             (packet_ptr -> nx_packet_length < NX_PTP_MSG_FOLLOW_UP_LEN))
         {
+            // Restart state sequence.
+            client_ptr -> nx_ptp_client_state = NX_PTP_CLIENT_STATE_LISTENING;
+            client_ptr -> nx_ptp_client_delay_req_timer = -1;
+            client_ptr -> nx_ptp_client_announce_timeout = -1;

             /* not a follow up for a previous Sync or invalid message */
             return;
         }

@@ -1338,10 +1364,14 @@ NX_PTP_MSG_HEADER hdr;
             (packet_ptr -> nx_packet_length < NX_PTP_MSG_DELAY_RESP_LEN) ||
             (memcmp(client_ptr -> nx_ptp_client_port_identity,
                     packet_ptr -> nx_packet_prepend_ptr + NX_PTP_MSG_TIMESTAMP_LEN,
                     NX_PTP_CLOCK_PORT_IDENTITY_SIZE) != 0))
         {
+            // Restart state sequence.
+            client_ptr -> nx_ptp_client_state = NX_PTP_CLIENT_STATE_LISTENING;
+            client_ptr -> nx_ptp_client_delay_req_timer = -1;
+            client_ptr -> nx_ptp_client_announce_timeout = -1;

             /* not a delay_resp for a previous delay_req or invalid message */
             return;
         }
leobbditestcom commented 1 year ago

The above changes greatly reduced the hang sequence frequency, but it would still occur with some builds. The following change was tried, and the code is once again not displaying the hang:

@@ -1218,10 +1218,15 @@ NX_PTP_MSG_HEADER hdr;
         return;
     }

     if (hdr.messageType != NX_PTP_MSG_TYPE_SYNC)
     {
+        // Restart state sequence.
+        client_ptr -> nx_ptp_client_state = NX_PTP_CLIENT_STATE_LISTENING;
+        client_ptr -> nx_ptp_client_delay_req_timer = -1;
+        client_ptr -> nx_ptp_client_announce_timeout = -1;
+
         return;
     }

     if (((client_ptr -> nx_ptp_client_state != NX_PTP_CLIENT_STATE_WAIT_SYNC) &&
          (client_ptr -> nx_ptp_client_state != NX_PTP_CLIENT_STATE_WAIT_FOLLOW_UP)) ||