On 08/30/2017 10:49 AM, Michael Mann via Wireshark-dev wrote:
>>> 2. There is no support currently for "classless" service codes (like
>>> those used in Rockwell Automation PLCs), which is what
>>> _https://www.wireshark.org/lists/ethereal-dev/200601/msg00174.html_ appears
>>> to be talking about.
>
>> As I understand it the service codes mentioned in that thread are class
>> specific.
>> I have never encountered "classless" service codes until now, I didn't even
>> know that
>> existed (as CIP doesn't implement this behaviour, or at least I couldn't
>> find it in the documentation).
>
> To me, in layman's terms, the format of a CIP message is <service
> code><identifier>
> In the CIP specs, they focus on <identifier> being an object class and
> instance, but
> for some Rockwell PLCs, the <identifier> is just a string (and there is no
> class in the message).
> That's what I mean when I refer to "classless" requests.
Sorry to jump in, but I thought I'd clarify this part. The
specification does mandate support for class/instance and
class/instance/attribute EPATHs in compliant devices for spec'd classes,
but doesn't require that for vendor-specific objects.
The spec *does* call out Message Router-specific service code 0x4B for
Symbolic Translation, offering a spec-standard way to convert symbolic
EPATHs to corresponding class/instance EPATHs.
Given the specification's treatment of this, I'd suggest keeping the
dissection of non-class EPATHs in place.
{ FWIW, I'm a ODVA spec subscriber and registered vendor... }
Regards,
Phil Turmel, Owner
--
Automation Professionals, LLC
97 Howell Ave
Fairburn, GA 30213
Office: (678) 817-4261 x24
Mobile: (404) 713-7284
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
