Cannot connect to TI module in HLS(2)

Hello everyone,
I just started approaching the world of DLMS/COSEM, in particular the development of a DLMS server. I'm currently using the MSP430 micro from Texas Instruments and both the GuruX Director and java libraries as client.

I have no problems connecting the device using none or low security. Since the Director doesn't have support for High authentication natively (it can be set creating a new manufacturer, but that's not the issue) I started using the client example that comes within the libraries.

I modified the tis.obx to include a new GXAuthentication type named 'High' with Client ID = 48 (0x30H) and set the flag for iec starting protocol to false (since the iec opening is not supported).
With the manufacturer, password and serial port set within the run commands, i got a "Access Error : Device reports a inconsistent Class or object".

I started digging into the function and found out that in the aarq sent to the server there were two elements to pay attention to:
1) the calling-authentication-value (tag AC) with the 16 bytes password set in the run commands
2) the dedicated-key among the user-info field as a randomly generated string.

As far as I understand the CtoS should be set in the calling-authentication-value and since I don't need the APDU encryption I removed the dedicated-key field of the initiate request and set the calling-authentication-value as a fixed 16 bytes randomly generated string just to try.

The device will always reply with "Access Error : Device reports a inconsistent Class or object", still the reply_to_HLS reply has the correct encryption of the CtoS!
So, has anyone succeeded in connecting the TI devices in HLS(2) or am I missing some steps?

Thanks for your help

This is the aarq I send:
60 3e a1 09 06 07 60 85 74 05 08 01 01 8a 02 07 80 8b 07 60 85 74 05 08 02 02 ac 12 80 10 3f 3a 3f 2b 6d 26 2a 6d 5c 3f 32 67 59 27 34 31 be 10 04 0e 01 00 00 00 06 5f 1f 04 00 00 7e 1f ff ff

This is the aare I receive:
61 4a a1 09 06 07 60 85 74 05 08 01 01 a2 03 02 01 0 a3 05 a1 03 02 01 0e 88 02 07 80 89 07 60 85 74 05 08 02 02 aa 12 80 10 54 65 78 61 73 49 6e 73 74 72 75 6d 65 6e 74 73 be 10 04 0e 08 0 06 5f 1f 04 0 0 18 1d 0 64 0 07

This is the action reply_to_HLS call:
c3 01 81 00 0f 00 00 28 00 00 ff 01 01 09 20 02 ac c4 1a 49 2b df e7 bf af 69 f4 53 05 45 2a dc 3a 2c 49 aa 38 5b 0c 67 42 d9 c3 2b 18 12 15 00 00 00 00 00 00 00 00 00 00

This is the reply_to_HLS reply:
c7 01 81 00 01 09 10 a8 e6 14 a7 c6 dd 36 55 2b 6e 1c de 72 be fd 2c

EDIT
I think I got it. In the reply_to_HLS reply I have
c7 01 = Action-Response-Normal
81 = ID & Priority
00 = Action-Result Success
01 = I cannot explain this one (data-access-result)... Since the next bytes are an octect string I was
expecting 0100.
09 10 = octect string of length 16

In fact, if I comment the piece of code that checks for the data-access-result field of the action response, the connection is established.