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
    • 0 Attachment
      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/
    • Steve Karg
      Hello BACnet BTL and MS/TP Groups members, Attached is a proposal that would correct the issue. Best Regards, Steve -- http://steve.kargs.net/
      Message 2 of 6 , Jul 13, 2007
      • 0 Attachment
        Hello BACnet BTL and MS/TP Groups members,

        Attached is a proposal that would correct the issue.

        Best Regards,

        Steve
        --
        http://steve.kargs.net/
      • Hartman, John (St. Paul)
        You also need to add a third transition to the DATA_CRC state to account for the case where the CRC is good but the DestinationAddress ISN T TS or broadcast.
        Message 3 of 6 , Jul 16, 2007
        • 0 Attachment
          You also need to add a third transition to the DATA_CRC state to account
          for the case where the CRC is good but the DestinationAddress ISN'T TS
          or broadcast. Action is simply to enter the IDLE state (without setting
          either ReceivedValidFrame or ReceivedInvalidFrame)

          As a historical note, I believe that the current version is the
          unfortunate result of changes made in response to the first public
          review: In the review draft, frames were delimited by the 3-octet gap
          between them (as in PROFIBUS). The state machine didn't leave the IDLE
          state until there had been at least 3 octets of silence. This
          essentially "ate" the data from any previous frame if an early jump to
          IDLE occurred - as from address mismatch or framing error.

          Review comments came from people who didn't want to implement the
          octet-speed timer that the original version required. It seems that we
          missed updating this aspect of the state machine.



          In the amazing-but-true category, in the early 80's I worked on a system
          that used a 16-bit communications CRC (same one as MS/TP). The
          implementation had a flaw similar to that in current MS/TP. And the
          system managed to find what appeared to be a complete frame INCUDING A
          GOOD CRC inside the data of another frame. I didn't believe it until I
          saw the line capture.

          That's one reason I liked the original gap-delimited MS/TP.






          -----Original Message-----
          From: bacnet-mstpwg@yahoogroups.com
          [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Steve Karg
          Sent: Friday, July 13, 2007 7:03 PM
          To: btl-wg@yahoogroups.com; bacnet-mstpwg@yahoogroups.com
          Cc: Swan, Bill
          Subject: [bacnet-mstpwg] Re: [btl-wg] MSTP testing and 55 FF 55 FF

          Hello BACnet BTL and MS/TP Groups members,

          Attached is a proposal that would correct the issue.

          Best Regards,

          Steve
          --
          http://steve.kargs.net/



          Yahoo! Groups Links
        • Robert Bacs
          Hi, This is just a proposal ! How about introducing a new state, skip next N bytes, where N = data length + 2 (for CRC), this way you don t need to allocate
          Message 4 of 6 , Jul 16, 2007
          • 0 Attachment
            Hi,

            This is just a proposal !

            How about introducing a new state, skip next N bytes,
            where N = data length + 2 (for CRC), this way you
            don't need to allocate new buffer and calculate Data
            CRC.

            Best regards,
            Boby





            --- Steve Karg <steve@...> wrote:

            > Hello BACnet BTL and MS/TP Groups members,
            >
            > Attached is a proposal that would correct the issue.
            >
            > Best Regards,
            >
            > Steve
            > --
            > http://steve.kargs.net/
            >




            ____________________________________________________________________________________
            Get the Yahoo! toolbar and be alerted to new email wherever you're surfing.
            http://new.toolbar.yahoo.com/toolbar/features/mail/index.php
          • Steve Karg
            Hi John ... Thank you for the suggestion. I added it to the proposal (attached). Enjoyed the history and the amazing but true anecdote! Best Regards, Steve --
            Message 5 of 6 , Jul 17, 2007
            • 0 Attachment
              Hi John

              > You also need to add a third transition to the DATA_CRC state to account
              > for the case where the CRC is good but the DestinationAddress ISN'T TS
              > or broadcast. Action is simply to enter the IDLE state (without setting
              > either ReceivedValidFrame or ReceivedInvalidFrame)

              Thank you for the suggestion. I added it to the proposal (attached).

              Enjoyed the history and the amazing but true anecdote!

              Best Regards,

              Steve
              --
              http://steve.kargs.net/
            • Steve Karg
              Hi BACneteers! I noticed in my MS/TP change proposal that I had forgotten to mention that the diagram needs updated. I don t have the source for the existing
              Message 6 of 6 , Jul 17, 2007
              • 0 Attachment
                Hi BACneteers!

                I noticed in my MS/TP change proposal that I had forgotten to mention
                that the diagram needs updated. I don't have the source for the
                existing diagram (does anyone?), so I used text to note the changes.
                Attached is another revision...

                Boby: Your proposal is intriguing. If I didn't mind causing more work
                for myself, I might consider adding another state.

                Best Regards,

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