• Created by Unknown User (cdutz), last updated on Sep 29, 2021 2 minute read

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Extended handling of "optional" fields

Proposal:

Make the expression of an "optional" field optional.

When parsing an optional field the parser always saves the current position before starting to parse the field. 

If when parsing the field no "AssertionException" is being caught, this information is just discarded. If however such an exception is caught, then the parser resets the position to the initial position and the next field can continue parsing from that location.

In addition to this, we add a new field type: "assertion" ... these can generally be seen similar to "const" fields. However in contrast to "const" fields these need to be saved as properties in the model. An assert field contains an expression field. If the value parsed matches this, the value is saved in the property. If however this value doesn't match the expected value, an "AssertionException" is thrown.

These changes are intended especially for protocols like BacNET and PROFINET where there are optional fields, based on their content. 

Example:

['0x07' BACnetUnconfirmedServiceRequestWhoHas
    [optional BACnetComplexTagUnsignedInteger 'deviceInstanceRangeLowLimit'                                                                 ['0', 'BACnetDataType.UNSIGNED_INTEGER' ]]
    [optional BACnetComplexTagUnsignedInteger 'deviceInstanceRangeHighLimit' 'deviceInstanceRangeLowLimit != null' ['1', 'BACnetDataType.UNSIGNED_INTEGER' ]]
    [optional BACnetComplexTagOctetString          'objectIdentifier'                                                                                        ['2', 'BACnetDataType.OCTET_STRING' ]]
    [optional BACnetComplexTagOctetString          'objectName'                               'objectIdentifier == null'                       ['3', 'BACnetDataType.OCTET_STRING' ]]
]


Controlling/Changing the endianess

Especially in parts of the PROFINET protocol, the endianess needs to change througout the protocol stack. So our current approach with one fixed endianess doesn't work well in this case. I've tried using manual fields, but the result was everything but ideal. 

In general I've encountered multiple situations:

  • One layer of the protocol stack is fixed to a given endianess (UDP is Big Endian, for example, PROFINET IO CM Blocks are Big Endian too)
  • Endianess of fields are dependent on some parsed values (In DCE/RPC there is a 4 bit field, that controlls if the following fields are BigEndian or LittleEndian)
  • Endianess of all fields of a complex type are dependent on the endianess of the parten (In case of PROFINET IO CM the ProfinetIO CM packet has the same endianess of the DCE/RPC packet that contains it)
  • No labels