ela-compil / BACnet

BACnet protocol library for .NET :satellite:
https://www.nuget.org/packages/bacnet/
MIT License
215 stars 95 forks source link

ReadPropertyAsync on OBJECT_CHARACTERSTRING_VALUE with MS/TP transport silently truncates data #105

Closed Machinegon closed 2 years ago

Machinegon commented 2 years ago

I'm using BACnet library Release 2.0.4 on mono 6.10 with linux, target framework 4.8. This type of request, about 1 time out of 5, truncates the expected string to the last character only and does not raise any exception.

The code:

            var getValue = this.client.ReadPropertyAsync(node.Addr, BacnetObjectTypes.OBJECT_CHARACTERSTRING_VALUE, 0, BacnetPropertyIds.PROP_PRESENT_VALUE);
            var updateValue = getValue.ContinueWith(task => 
            {
                 byte[] bytes = Convert.FromBase64String(task.Result[0].Value.ToString());
                 .....

I'm expecting a base64 encoded string : L6BOMurAqAVIAAA= and I'm receiving only the character '=' after the getValue async task completes successfully. The Bacnet encoding used is 00 (ANSI / ASCII)

image

I have a data dump of the link between the 2 devices while I'm debugging that shows this string was sent:

55 FF 00 01 00 00 00 73 55 FF 00 00 01 00 00 62 55 FF 05 01 00 00 0D 11 01 04 00 03 01 0C 0C 0A 00 00 00 19 55 F3 12 55 FF 06 00 01 00 21 6C 01 00 30 01 0C 0C 0A 00 00 00 19 55 3E 75 11 06 4C 36 42 4F 4D 55 72 41 71 41 56 49 41 41 41 3D 3F AC D3
55 FF 00 01 00 00 00 73 55 FF 00 00 01 00 00 62 55 FF 00 01 00 00 00 73

Could you provide any help on why this is happening? Any workarounds?

Thank you, Mikael

Machinegon commented 2 years ago

I did further investigation on this. The wrong encoding is provided (06 instead of expected 00) and the function multi_charset_characterstring_decode tries to interpret the string in the wrong way instead of throwing an exception or returning an error. I will close the issue and let you decide if that's correct behavior or not.