• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 722 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DP83640: Behavior in IP fragment without PTP packets

kenshow
Genius 3725 points
Part Number: DP83640

Hi,

I would like to confirm about the operation specifications of PTP/IEEE1588v2 compatible products in DP83830 and DP83840.

If an IP fragment occurs in a packet other than PTP, does the PHY device misrecognize the fragment packet as a PTP packet and rewrite the data even though it does not need to be rewritten?
For example, updating collection fields.

Best regards,
Kenshow

  • 0
    TI__Mastermind 23675 points

    Are you asking if a frame that is not a ptp frame were to somehow be corrupted to become a ptp frame and the PHY change the time portion of the frame where it might actually be data? I find this highly unlikely because the CRC would not match. 

  • 0 in reply to Ross Pimentel
    Genius 3725 points

    Hi Ross,


    Yes, your understanding is correct.

    Despite this rare case, can TI's PHY devices prevent such failures? Or do we have to prevent it on the MAC side?

    Regards,
    Kenshow

  • 0 in reply to kenshow
    Genius 3725 points

    Hi Ross,

    Do you have any update?

    I just would like to know if there is a function to protect something as a TI device when this corrupted data comes into a PTP frame.

    Or does it have no protection function and change the time part of the frame?

    Best Regards,
    Kenshow

  • 0 in reply to kenshow
    Genius 4905 points

    Hi Ross,

    I'm working with Kenshow. I would appreciate it if you could give us your reply by October 3.

    =====
    We just would like to know if there is a function to protect something as a TI device when this corrupted data comes into a PTP frame.
    Or does it have no protection function and change the time part of the frame
    =====

    Nao

  • 0 in reply to Nao
    Genius 3725 points

    HI Ross,

     There is a register to check the UDP protocol field in the data sheet, and I understood that it seems to have a corresponding function, but I could not read about the confirmation item this time.

     The confirmation items are described below in detail.

     PTP packets are based on Ether Type and IPv4 IP / UDP header port numbers (319/320). This time, I would like to confirm about IPv4 IP / UDP header port number.

     When IP fragmentation is performed with IP / UDP, the first packet will not be recognized as a PTP packet if the PTP port number in the UDP header is not 319/320. In the subsequent fragment packet, there is no UDP header part for storing this port number, and data can be seen. And if this data part happens to coincide with the port number for PTP, I want to confirm if it is erroneously recognized as a PTP packet and the data is updated (rewritten) to update the time.

    Best Regards,
    Kenshow

  • 0 in reply to Nao
    TI__Mastermind 23675 points

    Hi Nao and Kenshow,

    Sorry for the delay. I was ooo the last week.

    There is no way to prevent such an accident from occurring.

    However, I would imagine this case to be extremely rare since there is a CRC.

    If the frame is altered, the CRC would also need to miraculously be altered to a value associated with the frame.