Loading ...
Sorry, an error occurred while loading the content.
 

Re: [btl-wg] MSTP testing and 55 FF 55 FF

Expand Messages
  • Steve Karg
    Hi Ted (and others), ... As Bill and Roland pointed out, this could happen anytime that a 55 FF preamble was in the DATA portion of the Frame. I think that
    Message 1 of 6 , Jul 13, 2007
      Hi Ted (and others),

      > In my evaluation I was able to determine that if a
      > preceding message ended with 55, and this vendor used the padding
      > character (FF) - the next message would not be responded to. In short
      > if the preceding message ended with 55 FF and the start of the next
      > message (being 55 FF) - this message would be rejected and not be
      > responded to.

      As Bill and Roland pointed out, this could happen anytime that a "55 FF" preamble was in the DATA portion of the Frame.

      I think that the problem that you are seeing is coming from the MS/TP Receive Frame State Machine in 9.5.4.4 HEADER_CRC, NotForUs and Data.

      If the frame has DATA (length > 0) and it is not for us, the Receive FSM goes to IDLE.  Then the DATA portion of a frame is parsed as EatAnOctet until the Preamble is seen, and the Receive FSM potentially misses the beginning of the next frame depending on the contents of the DATA.

      Perhaps changing the Receive Frame State Machine to finish receiving the DATA would fix this issue (i.e. get rid of NotForUs, and allow Data to parse regardless of the value of DestinationAddress).

      Ted: do you have some specific messages that demonstrate this behavior that we could test with?  Or is Wayne's suggestion of having a device return the value of 127.66896 (0x42ff55ff) in response to a ReadProperty request a valid test?

      Best Regards,

      Steve
      --
      http://steve.kargs.net/
    Your message has been successfully submitted and would be delivered to recipients shortly.