Question on FD-BBMD ADDRESS (host 'n' port) and lifetime props writability in netport as per 135-2020 clause 12.56.37 - WIP

[metelik]

I have been working on Writable FD BBMD ADDRESS and PORT as well as FD REGISTRATION LIFETIME as per _12.56.37 FD_BBMD_Address
This property, of type BACnetHostNPort, indicates the BBMD with which the local device is to register as a foreign device
when BACnet_IP_Mode is FOREIGN. This property shall be present and writable if BACnet_IP_Mode is FOREIGN.
If this property is writable, then a successful write to this property shall set the Changes_Pending property to TRUE. A value
written to this property shall become effective when the device receives a ReinitializeDevice service request with a
'Reinitialized State of Device' of ACTIVATE_CHANGES or WARMSTART.

The main question is whether I found a bug in the stack or perhaps I am doing something wrong. In the code-base I see a multitude of various constructed data types, which rose the doubt.

Please find the detailed analysis below.

In order to test it with the BIP I used VTS and constructed the WP req' as shown on the screenshot, following the tagging spec *ASHRAE 135-2020) ; the request matches one from the Read Prop' ACK regarding same host'n'port (prop 418) - I attach the analysis of the RP ACK as well just for the sake of completness._

The solution :
https://github.com/se-apc/bacnet-stack/blob/4bc5fe211b6a6c58bc03cd1892a844e023781381/src/bacnet/basic/object/netport.c#L3258 .

did not work (resulting in one of BACnet errors. Please forgive me the fprintfs but I wanted to figure out what I have been doing wrong.

The first point of error:

I added the: https://github.com/se-apc/bacnet-stack/blob/4bc5fe211b6a6c58bc03cd1892a844e023781381/src/bacnet/bacdcode.c#L545 ; Otherwise it was entering the https://github.com/se-apc/bacnet-stack/blob/4bc5fe211b6a6c58bc03cd1892a844e023781381/src/bacnet/bacdcode.c#L548 and resulting with tag.context == false and failing decode.

Second point of error:
Ist that the hotnport.c decoding function expects the context tag '0xe' rather than passed sobsequeent '0x1c' for tagging actual octet string (see the apdu-- here: https://github.com/se-apc/bacnet-stack/blob/4bc5fe211b6a6c58bc03cd1892a844e023781381/src/bacnet/hostnport.c#L146 . Looks like I would have been missing one more tagging? Yet haven't been able to decipher the clause
20.2.1.3.2 Constructed Data
If the production being encoded contains tagged elements, then the encoding is called "constructed" and shall consist of
(a) an "opening" tag whose Tag Number field shall contain the value of the tag number, whose Class field shall indicate
"context specific," and whose length/value/type field shall have the value B'110';
(b) the complete encoding, with tags, of the zero, one, or more elements that comprise the data;
(c) a "closing" tag, whose Class and Tag Number fields shall contain the same values as the "opening" tag and whose
length/value/type field shall have the value B'111'.
In this case, the length/value/type fields of the "opening" and "closing" tags shall be interpreted as types.
Note that a contained tagged element may itself be a constructed element. This recursion does not result in ambiguous encoding,
as each "opening" tag is required to have a corresponding "closing" tag that will be contained within any outer "opening" and
"closing" tags.

correctly.
I also infer that the decoding must work well for the stack's routing part where the address and port must be flying around quite frequently.
I would appreciate any insight into this. I shall share the code once ready and tested.

[metelik]

I'd truly appreciate an insight because I am in a pickle with this...