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 220.127.116.11
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?