Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: V3.4.0.0
    • Fix Version/s: V3.4.0.1, V3.4.1.0, V3.5.0.0
    • Component/s: None
    • Labels:
      None
    • Account:
      SPC EthernetIp Slave (SPCETHERNE)

      Description

      We still have issues with connection multiplexing. Requirements wrap-up and problems:

      1) If a Class 3 CIP connection was opened via Encap Session -> Encap Session must not be closed as long as class 3 connection is still active. This is ok.

      2) If a Class 1 CIP connection opened via Encap Session -> Encap session can be closed (although not recommended by specification). CLass 1 connection persists. This is ok.

      3) In case 2), when first encap session which opened the class 1 CIP connection was closed, and another encap session is opened on the same lwIP socket and finally, the Class 1 connection times out, then it closes the new (unrelated) encap session. This is a bug. We can reproduce this easily, although it is not a show stopper for certification, this should be fixed. We want unique identifiation of each newly created encap session and keep track of which encap sessions openeed which CIP connections.

      4) Class 1 or class 3 connections which time out have to close the underlying Encap Session, if no other active connections remain which were opened over that encap session. This is ok, except for case 2, where we tear down the wrong encap session.

      5) We should think about the case where an originator has opened an encap session and a class 3 connection over that session and then closes the transport. Should we tear down the class 3 connection? I found no information on this in the standard. It is probably ok to keep the class 3 connection and let it time out. Then, we have the same issue as described in bullet 2. Since the encap session and the class3 connection are bound to each other, it may also be a good idea to tear it down. This may also be something which we can pipe back to the ODVA; because the specification is not precise at this point.

      6) Special cases device reset and reconfiguration of PHYs and IP layers should be considered. We should bring all connections down and then of course have to take all the points mentioned above into account. These situations are partly not handled very cleanly.

        Attachments

          Expenses

            Activity

              Status Description

                People

                • Reporter:
                  MBommert Marc Bommert
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: