mz-automation / lib60870 Goto Github PK

/root/iotbase/thirdpart/lib60870/lib60870-2.0.0/lib60870-C/src/hal/serial/linux/serial_port_linux.c:44:20: error: field ‘timeout’ has incomplete type
struct timeval timeout;
^
/root/iotbase/thirdpart/lib60870/lib60870-2.0.0/lib60870-C/src/hal/serial/linux/serial_port_linux.c: In function ‘SerialPort_readByte’:
/root/iotbase/thirdpart/lib60870/lib60870-2.0.0/lib60870-C/src/hal/serial/linux/serial_port_linux.c:241:5: error: unknown type name ‘fd_set’
fd_set set;

How can I build this library as shared library?

hello,
in the simple_client example, i compiled sourcecode which two delay funtions "Thread_sleep(5000)" at line 89 and 93 were commented with make in ubuntu12.04 . the program run to Segmentation fault (core dumped).

when debug with gdb , it throw below info.

(gdb) bt
#0 0xb7e79410 in __GI___libc_free (mem=0x8060128) at malloc.c:2984
#1 0x08056bdd in Memory_free (memb=0x8060128) at src/common/lib_memory.c:79
#2 0x08056a8b in Thread_destroy (thread=0x8060128)
at src/hal/thread/linux/thread_linux.c:114
#3 0x08049712 in T104Connection_close (self=0x8060008)
at src/iec60870/t104/t104_connection.c:321
#4 0x08049725 in T104Connection_destroy (self=0x8060008)
at src/iec60870/t104/t104_connection.c:328
#5 0x08048ffb in main (argc=1, argv=0xbffff334) at simple_client.c:118

coredumped at free() funtion in glibc , could you give some cue.

BTW, v0.9.3 does not get this problem.

I think following line

should be changed to

uint32_t value = self->value

otherwise the following code that extracts the single bytes might produce incorrect results when (int) self->value is negative.

This same applies to the bitstring variants with time tags.

Hello, I found a SEGV inlib60870/lib60870-C/examples/cs104_server/simple_server.c.

Below are steps followed to reproduce crash
Download latest source code from: /mz-automation/lib60870/, compiled with clang and ASANexport CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address"before make

Input data
crash.zip

ASAN Output

ASAN:DEADLYSIGNAL
=================================================================
==23512==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x000000561b31 bp 0x7f3b2b2fbd70 sp 0x7f3b2b2fbb10 T4)                                                                                ==23512==The signal is caused by a READ memory access.                                                                                                                                                             ==23512==Hint: address points to the zero page.
    #0 0x561b30 in CS101_ASDU_getCOT /root/temp/iec/lib60870/lib60870-C/src/iec60870/cs101/cs101_asdu.c:308:47
    #1 0x58a963 in handleASDU /root/temp/iec/lib60870/lib60870-C/src/iec60870/cs104/cs104_slave.c:1708:19
    #2 0x58a963 in handleMessage /root/temp/iec/lib60870/lib60870-C/src/iec60870/cs104/cs104_slave.c:2043
    #3 0x5882b6 in connectionHandlingThread /root/temp/iec/lib60870/lib60870-C/src/iec60870/cs104/cs104_slave.c:2410:21
    #4 0x5a0962 in destroyAutomaticThread /root/temp/iec/lib60870/lib60870-C/src/hal/thread/linux/thread_linux.c:87:2
    #5 0x7f3b302ac6b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
    #6 0x7f3b2f6b741c in clone /build/glibc-LK5gWL/glibc-2.23/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:109

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /root/temp/iec/lib60870/lib60870-C/src/iec60870/cs101/cs101_asdu.c:308:47 in CS101_ASDU_getCOT
Thread T4 created by T1 here:
    #0 0x431d2d in __interceptor_pthread_create (/root/temp/iec/lib60870/lib60870-C/examples/cs104_server/simple_server+0x431d2d)
    #1 0x5a05eb in Thread_start /root/temp/iec/lib60870/lib60870-C/src/hal/thread/linux/thread_linux.c:98:3
    #2 0x7f3b302ac6b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)

Thread T1 created by T0 here:
    #0 0x431d2d in __interceptor_pthread_create (/root/temp/iec/lib60870/lib60870-C/examples/cs104_server/simple_server+0x431d2d)
    #1 0x5a06bb in Thread_start /root/temp/iec/lib60870/lib60870-C/src/hal/thread/linux/thread_linux.c:102:3

==23512==ABORTING

How can a CS104 slave close a specific incoming connection from a master?
IMasterConnection has methods for sending responses and querying parameters but not for closing the connection - if, say, slave detected some unrecoverable condition during exchange.

I expect calling ConnectionHandler with CS104_CONNECTION_CLOSED event, but nothing happens

Hello,

Since 2.0.0 version you add new header files in library but this files have not "extern C" instruction to use library in C++

Error issue

Hi, I started the some test with lib60870 to see how much it is controllable as it is called as "lib".
In fact just after writing some sample code, I found there is no way to access to the application layer flow control.
For example we are preparing to prepare high information object to be sent, and using the enqueue to queues or by sending to asdu. But there is no way to find if queue be full or sending is OK or not and etc.
Most of these are available in lib but they are internal and we could not access to check them. Please advise if there is away to find the sending ASDU or enqueuing that has been done OK or FAIL.
Thanks

There is an issue with timeout handling in cs104_connection.c.
In static bool handleTimeouts(CS104_Connection self) we can get situation when
if ((currentTime - self->sentASDUs[self->oldestSentASDU].sentTime) >= (uint64_t) (self->parameters.t1 * 1000)) condition does not work as expected.
Expression currentTime - self->sentASDUs[self->oldestSentASDU].sentTime could return negative result (and that happened, when I investigated an issue in some project). So I propose look at signed arithmetics and change this condition with something like that:
if ((int32_t)(currentTime - self->sentASDUs[self->oldestSentASDU].sentTime) >= (self->parameters.t1 * 1000)) {

Hello.

Valgrind says:

==9657== Invalid free() / delete / delete[] / realloc()
==9657==    at 0x483997B: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==9657==    by 0x129DBC: Memory_free (lib_memory.c:79)
==9657==    by 0x129A41: Socket_destroy (socket_linux.c:460)
==9657==    by 0x128190: handleConnection (cs104_connection.c:817)
==9657==    by 0x488E181: start_thread (pthread_create.c:486)
==9657==    by 0x49C3B1E: clone (clone.S:95)
==9657==  Address 0x4a96a20 is 0 bytes inside a block of size 8 free'd
==9657==    at 0x483997B: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==9657==    by 0x129DBC: Memory_free (lib_memory.c:79)
==9657==    by 0x129A41: Socket_destroy (socket_linux.c:460)
==9657==    by 0x128190: handleConnection (cs104_connection.c:817)
==9657==    by 0x488E181: start_thread (pthread_create.c:486)
==9657==    by 0x49C3B1E: clone (clone.S:95)
==9657==  Block was alloc'd at
==9657==    at 0x483874F: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==9657==    by 0x129D1C: Memory_malloc (lib_memory.c:44)
==9657==    by 0x129343: TcpSocket_create (socket_linux.c:263)
==9657==    by 0x127F22: handleConnection (cs104_connection.c:729)
==9657==    by 0x488E181: start_thread (pthread_create.c:486)
==9657==    by 0x49C3B1E: clone (clone.S:95)
==9657== 

Looks like this problem occurs after timed out connection attempt.

Thank you.

• START_DT on a connection should trigger the Server.Activate function to set the other connection inactive

file: cs101_salve.c
func: handleASDU
line: 765
BUG: memory crack. the dac is from _io,but _io is a local variable，should not be freed.
the DelayAcquisitionCommand_destroy(dac); should be deleted.

By default backlog parameter for listen is set to 0. This causes the server not to accept any clients. There's a setter function ServerSocket_setBacklog but it does not seem to be used anywhere.

When attempting to send the M_ST_TB ASDU wire shark reports it as Invalid APDU length.

When I remove the time stamp and send as M_ST_NA wire shark recognise the frame correctly.

104dump.pcap.zip

If the library is used in 101 balanced master mode, there seems to be no way for changing the link layer address used by the LinkLayerSecondaryBalanced part of LinkLayerBalanced

CS101_Master_setOwnAddress() only modifies sCS101_Master::linkLayer and does not change sCS101_Master::balancedLinkLayer, for this reason the link layer address of frames sent in reverse direction by the library is always 0.

I may have missed something but I’ve found no way to configure that address using the public API, is this behaviour intentional?

Hello,

i have q question. Hopefully u can help me

where can I set or find the maximum Payload of an Asdu with a 104 server. I am using the server example and can only add 30 InformationObjects to the ASDU (MeasuredShortValues). So is 30 the maximum Number of InformationObjects per ASDU?

I solved this problem by cutting my message down to pieces and add an ASDU for every piece of information. But thats very slow. We want to send 3000 values. How fast can we send these values.

When I try to compile example in folder "cs_104_server" I see error message:"socket_win32.c|100|undefined reference to `__imp_select'|"
What can I do to resolve this error?
I'm developing in Code::Blocks 17.12

Hello,
I observe a strange behaviour with multi_client_server example. The memory of program increase according to the number of simultaneous connected clients (I tested with 1 to 5 simultaneous clients). But after client disconnections, the memory does not decrease.

I use top or htop command and I see the VIRT and RES column.

NB : Valgrind doesn't detect leak memory.

I have a problem，if i have more than one client，and these clients have to bind on the same sever which is in a specific host.
How to write the server-end program,how to send the datas,what's the best way to use this library?

Hello.

Valgrind says:

==10956== Thread 5:
==10956== Invalid write of size 1
==10956==    at 0x5061EA6: handleConnection (cs104_connection.c:821)
==10956==    by 0x508F668: start_thread (pthread_create.c:479)
==10956==    by 0x4B37322: clone (clone.S:95)
==10956==  Address 0x4c5dcd0 is 496 bytes inside a block of size 552 free'd
==10956==    at 0x483BA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==10956==    by 0x5063C06: Memory_free (lib_memory.c:79)
==10956==    by 0x50613D9: CS104_Connection_destroy (cs104_connection.c:431)
==10956==    by 0x504FD02: process_meter_connection (lib.c:972)
==10956==    by 0x504FE1C: iec_104_fetch_thread (lib.c:995)
==10956==    by 0x506397B: destroyAutomaticThread (thread_linux.c:87)
==10956==    by 0x508F668: start_thread (pthread_create.c:479)
==10956==    by 0x4B37322: clone (clone.S:95)
==10956==  Block was alloc'd at
==10956==    at 0x483A7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==10956==    by 0x5063B5A: Memory_malloc (lib_memory.c:44)
==10956==    by 0x5060CF2: createConnection (cs104_connection.c:199)
==10956==    by 0x5060E4E: CS104_Connection_create (cs104_connection.c:243)
==10956==    by 0x504FD85: iec_104_fetch_thread (lib.c:984)
==10956==    by 0x506397B: destroyAutomaticThread (thread_linux.c:87)
==10956==    by 0x508F668: start_thread (pthread_create.c:479)
==10956==    by 0x4B37322: clone (clone.S:95)
==10956== 

This error may occur when connection was closed and user program set flag about this in connectionHandler() and then call CS104_Connection_destroy() on this connection fast enough.

Also, if user calls CS104_Connection_destroy() in connectionHandler() on CONNECTION_CLOSED event - following error occurs before cs104_connection.c:821 :

==13643== Thread 4:
==13643== Invalid read of size 8
==13643==    at 0x12AE62: handleConnection (cs104_connection.c:817)
==13643==    by 0x488B668: start_thread (pthread_create.c:479)
==13643==    by 0x49C7322: clone (clone.S:95)
==13643==  Address 0x4a98f28 is 488 bytes inside a block of size 552 free'd
==13643==    at 0x483BA3F: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==13643==    by 0x12CBD5: Memory_free (lib_memory.c:79)
==13643==    by 0x12A3A8: CS104_Connection_destroy (cs104_connection.c:431)
==13643==    by 0x118CFA: connectionHandler (lib.c:675)
==13643==    by 0x12AE50: handleConnection (cs104_connection.c:804)
==13643==    by 0x488B668: start_thread (pthread_create.c:479)
==13643==    by 0x49C7322: clone (clone.S:95)
==13643==  Block was alloc'd at
==13643==    at 0x483A7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==13643==    by 0x12CB29: Memory_malloc (lib_memory.c:44)
==13643==    by 0x129CC1: createConnection (cs104_connection.c:199)
==13643==    by 0x129E1D: CS104_Connection_create (cs104_connection.c:243)
==13643==    by 0x119280: iec_104_fetch_thread (lib.c:996)
==13643==    by 0x12C94A: destroyAutomaticThread (thread_linux.c:87)
==13643==    by 0x488B668: start_thread (pthread_create.c:479)
==13643==    by 0x49C7322: clone (clone.S:95)

So, there is 2 memory errors at once (and one of them is 1-byte memory corruption).

I found some configuration mistakes in cs104_slave.c.
Strings CONFIG_CS104_SUPPORT_SERVER_MODE_CONNECTION_IS_REDUNDANCY_GROUP
in some places have been improperly replaced by CONFIG_CS104_SUPPORT_SERVER_MODE_SINGLE_REDUNDANCY_GROUP.
This applies to lines 50, 635, 771, 2200 and maybe others.

Hello,

I have a Segmentation fault when I execute cs104_server example with cs104_client example (version 2.0.0, it works in 0.9.7)

here it is the valgrind result :
==30968== Memcheck, a memory error detector
==30968== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==30968== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==30968== Command: ./cs104_server
==30968==
New connection from 127.0.0.1
==30968== Thread 3:
==30968== Invalid read of size 8
==30968== at 0x41A746: HighPriorityASDUQueue_resetConnectionQueue (in /home/doerra/HbsSystemTools/lib60870-2.0.0/lib60870-C/build/examples/cs104_server/cs104_server)
==30968== by 0x41B9AD: handleMessage (in /home/doerra/HbsSystemTools/lib60870-2.0.0/lib60870-C/build/examples/cs104_server/cs104_server)
==30968== by 0x41BFB8: connectionHandlingThread (in /home/doerra/HbsSystemTools/lib60870-2.0.0/lib60870-C/build/examples/cs104_server/cs104_server)
==30968== by 0x41D6B5: destroyAutomaticThread (in /home/doerra/HbsSystemTools/lib60870-2.0.0/lib60870-C/build/examples/cs104_server/cs104_server)
==30968== by 0x4E3D063: start_thread (pthread_create.c:309)
==30968== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==30968==
==30968==
==30968== Process terminating with default action of signal 11 (SIGSEGV)
==30968== Access not within mapped region at address 0x18
==30968== at 0x41A746: HighPriorityASDUQueue_resetConnectionQueue (in /home/doerra/HbsSystemTools/lib60870-2.0.0/lib60870-C/build/examples/cs104_server/cs104_server)
==30968== by 0x41B9AD: handleMessage (in /home/doerra/HbsSystemTools/lib60870-2.0.0/lib60870-C/build/examples/cs104_server/cs104_server)
==30968== by 0x41BFB8: connectionHandlingThread (in /home/doerra/HbsSystemTools/lib60870-2.0.0/lib60870-C/build/examples/cs104_server/cs104_server)
==30968== by 0x41D6B5: destroyAutomaticThread (in /home/doerra/HbsSystemTools/lib60870-2.0.0/lib60870-C/build/examples/cs104_server/cs104_server)
==30968== by 0x4E3D063: start_thread (pthread_create.c:309)
==30968== If you believe this happened as a result of a stack
==30968== overflow in your program's main thread (unlikely but
==30968== possible), you can try to increase the size of the
==30968== main thread stack using the --main-stacksize= flag.
==30968== The main thread stack size used in this run was 8388608.
==30968==
==30968== HEAP SUMMARY:
==30968== in use at exit: 1,624 bytes in 15 blocks
==30968== total heap usage: 76 allocs, 61 frees, 11,328 bytes allocated
==30968==
==30968== LEAK SUMMARY:
==30968== definitely lost: 0 bytes in 0 blocks
==30968== indirectly lost: 0 bytes in 0 blocks
==30968== possibly lost: 544 bytes in 2 blocks
==30968== still reachable: 1,080 bytes in 13 blocks
==30968== suppressed: 0 bytes in 0 blocks
==30968== Rerun with --leak-check=full to see details of leaked memory
==30968==
==30968== For counts of detected and suppressed errors, rerun with: -v
==30968== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Killed

Hello,

For 104 slave, the APCI Parameters are set with a default value and there is no function to set it. Have you a reason for that or is it possible to add this function ?

Hello body，
When I used PMA2.0 ，act as iec104 slave，then use lib60870-C source to build a master demo. They can do it work, but run a period of time, like 30min,they communications will breakdown ,and the error code of socket is 10054.
It's PMA2.0 has some problem? Whice tools do you used for simulation IEC104 SLAVE.

In mode CONNECTION_IS_REDUNDANCY_GROUP:

If you create a slave (CS104_Slave_create) and destroy the slave (cs104_Slave_destroy) without calling start (CS104_Slave_start) inbetween it will produce a segmentation fault in trying to destroy the queue witch pointer was neither initialized with NULL nor instanciated (instantiation is done within the start function).
I have created a fix with a pull requests (#45 pull request) witch is awaiting your review since two weeks..
Thanks in advance.

Thank you for this wonderful lib60870.
I'm using it in mono environment as Server. I receive data from client with big-endian.
Such as float of 57.74 is 42 66 F5 C3.
Any plan to support big-endian of .Net version?

Thank you!

When running "make" on MacOS Catalina (and prior), which are "BSD", on final stages of build process, linker fails with messages:

The problem is that there is no "serial port HAL" library for BSD:

But, if we just point to Linux library ./hal/serial/linux/serial_port_linux.c as a library to be used for BSD, it compiles and works perfectly.

Is this a bug or an upcoming feature? :)

We have switched to "submodule" of your library in our project, so we can't make those fixes any more.
It's not a big problem since our working environment is 100% Linux, but it'd be great to have an opportunity to build and test on Mac sometimes.

If QOI not equals "<20> := Station interrogation (global)", example is not correct.
Correct use

ASDU newAsdu = new ASDU(cp, (CauseOfTransmission)qoi, false, false, 2, 1, false);

I've been trying to use provided C TLS examples, but I had no luck in getting them to comunicate.

lib60870-C/examples/tls_server$ ./tls_server
New connection from 127.0.0.1
Close connection

lib60870-C/examples/tls_client$ ./tls_client
Connect failed!
exit

Tried on two machines with different GCCs, they compile fine, but won't connect as shown above.
Any ideas on what might be the problem or how to debug it?

IEC 60870-5-101
Table 17 – ASDUs involved in the station interrogation procedure

All ASDUs for station interrogation procedure are listed.
MeasuredValueScaledWithCP56Time2a and SinglePointWithCP56Time2a not allowed.

private static bool interrogationHandler(object parameter, ServerConnection connection, ASDU asdu, byte qoi)
This is an incorrect example

In my setup adding -Wall and -Wextra to CFLAGS produces some warnings (gcc 8.3.0 on Debian buster).
Can you please try doing the same and check the output?
We can consider enabling these flags by default, in order to leverage compiler static analysis as much as possible, maybe enabling also using -Werror.

I'm a developer, when will support other protocol parts(101, 102 ,103)?

Is this library conformant with this standard when used with TLS enabled?

I have some suggestions to reduce the memory consumption, which is important for microcontrollers.

1. You need to define variables that aren't really modified during execution as 'const'. For example, these are all tables of virtual functions:
   const struct sInformationObjectVFT singlePointInformationVFT = {
   Respectively, for pointers
   typedef const struct sInformationObjectVFT* InformationObjectVFT;
   That will allow them to be placed only in flash memory, not in RAM.

2. In structures, the fields for storing integer data are always defined as 'int' (32 bits in many architectures), regardless of the actual data range. For example, in sCS101_AppLayerParameters and some others. Is it possible to use shorter data types?

3. I would like to exclude from the executable code procedures for working with ASDU of types, which I don't use. Maybe you can add configuration options like "#define CONFIG_SUPPORT_M_EP_TC_1" to disable calls from ASDU_getElement(). In my case reception of any M_* ASDUs isn't required. This option can save at least 8 kB.

Hello.
I haven't find API function to send command (C_SC_, C_DC__, C_RC_, C_SE_, etc). Any plan to implement this or there is a way to send command with generic functions ?

Hello,

I have a question about timeout and connection's failure flag :
In CS104_Connection we have three flags to define connection state : running, failure and close.
In handleConnection loop if handleTimeouts is false, the loop is stopped but any flag is set. It is a normal behaviour or the failure flag should be set at true ?

And to get connection's flags, is it possible to add get function in API ?

auto m_server = CS104_Slave_create(m_maxLowPrioQueuSize, m_maxHighPrioQueuSize); CS104_Slave_destroy(m_server)

In this case the self->asduQueue is null and in MessageQueue_releaseAllQueuedASDUs() try to access null pointer. In result, we have got undefined behavior.

    if (ca < 0)
        setCa = 0;
    else {
        if (self->parameters->sizeOfCA == 1) {
            if (ca > 255)
                setCa = 255;
        }
        else if (self->parameters->sizeOfCA > 1) {
            if (ca > 65536)
                setCa = 65536;
        }
    }

If setCa is greater than 65536, then it becomes 0x10000. Further in ASDU it will get as 0. This value is not used for this field.
Proper use

    if (ca < 0)
        setCa = 0;
    else {
        if (self->parameters->sizeOfCA == 1) {
            if (ca > 255)
                setCa = 255;
        }
        else if (self->parameters->sizeOfCA > 1) {
            if (ca > 65535)
                setCa = 65535;
        }
    }

How can I get the data from ASDU for unsupported types?
I need to implement file transfer functions. The only way to get information from a payload is ASDU_getElement(), but it works with a limited set of types. asduHandler registered by Slave_setASDUHandler() can't directly access the data, because the declaration of sASDU is private.

Hello, I found a SEGV inlib60870/lib60870-C/examples/cs104_server/simple_server.c, gdb debug trace to

0x000000000059ae6e in CP56Time2a_getHour (self=) at >src/iec60870/apl/cpXXtime2a.c:583
583 return (self->encodedValue[3] & 0x1f);

where the return seems to cause an unexpected SEGV error.

Below are steps followed to reproduce crash
Download latest source code from: /mz-automation/lib60870/, compiled with clang and ASANexport CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address"before make

Input data
crash.zip

ASAN Output

ASAN:DEADLYSIGNAL
=================================================================
==7137==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000013 (pc 0x00000059ae6e bp 0x7f81dbafbd70 sp 0x7f81dbafbad0 T4)                                                                                 ==7137==The signal is caused by a READ memory access.                                                                                                                                                              ==7137==Hint: address points to the zero page.
    #0 0x59ae6d in CP56Time2a_getHour /root/temp/iec/lib60870/lib60870-C/src/iec60870/apl/cpXXtime2a.c:583:13
    #1 0x511109 in printCP56Time2a /root/temp/iec/lib60870/lib60870-C/examples/cs104_server/simple_server.c:23:45
    #2 0x511109 in clockSyncHandler /root/temp/iec/lib60870/lib60870-C/examples/cs104_server/simple_server.c:51
    #3 0x58ced4 in handleASDU /root/temp/iec/lib60870/lib60870-C/src/iec60870/cs104/cs104_slave.c:1790:21
    #4 0x58ced4 in handleMessage /root/temp/iec/lib60870/lib60870-C/src/iec60870/cs104/cs104_slave.c:2043
    #5 0x5882b6 in connectionHandlingThread /root/temp/iec/lib60870/lib60870-C/src/iec60870/cs104/cs104_slave.c:2410:21
    #6 0x5a0962 in destroyAutomaticThread /root/temp/iec/lib60870/lib60870-C/src/hal/thread/linux/thread_linux.c:87:2
    #7 0x7f81e0a846b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
    #8 0x7f81dfe8f41c in clone /build/glibc-LK5gWL/glibc-2.23/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:109

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /root/temp/iec/lib60870/lib60870-C/src/iec60870/apl/cpXXtime2a.c:583:13 in CP56Time2a_getHour
Thread T4 created by T1 here:
    #0 0x431d2d in __interceptor_pthread_create (/root/temp/iec/lib60870/lib60870-C/examples/cs104_server/simple_server+0x431d2d)
    #1 0x5a05eb in Thread_start /root/temp/iec/lib60870/lib60870-C/src/hal/thread/linux/thread_linux.c:98:3
    #2 0x7f81e0a846b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)

Thread T1 created by T0 here:
    #0 0x431d2d in __interceptor_pthread_create (/root/temp/iec/lib60870/lib60870-C/examples/cs104_server/simple_server+0x431d2d)
    #1 0x5a06bb in Thread_start /root/temp/iec/lib60870/lib60870-C/src/hal/thread/linux/thread_linux.c:102:3

==7137==ABORTING

For SinglePointInformation, GetEncodedSize returns 1. When using IsSequence, there remains spaceLeft for 240 information objects. This will cause vsq to be rewritten in the AddInformationObject function. It is necessary to add the following condition:

		public bool AddInformationObject(InformationObject io) 
		{
			if (informationObjects == null)
				informationObjects = new List<InformationObject> ();

			if (hasTypeId) {
				if (io.Type != typeId)
					throw new ArgumentException ("Invalid information object type: expected " + typeId.ToString () + " was " + io.Type.ToString ());
			} else {
				typeId = io.Type;
				hasTypeId = true;
			}

            if ((vsq & 0x7f) == 0x7f)
                return false;

			int objectSize = io.GetEncodedSize ();

            // skip
		}

Hello, I found a SEGV inlib60870/lib60870-C/examples/cs104_server/simple_server.c. gdb trace to:

0x0000000000561b31 in CS101_ASDU_getCOT (self=) at src/iec60870/cs101/cs101_asdu.c:308
308 return (CS101_CauseOfTransmission) (self->asdu[2] & 0x3f);

where the return seems to cause an unexpected SEGV error.

Below are steps followed to reproduce crash
Download latest source code from: /mz-automation/lib60870/, compiled with clang and ASANexport CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address"before make

Input data
crash.zip

ASAN Output

 ASAN:DEADLYSIGNAL
=================================================================
==23999==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000010 (pc 0x00000054c69e bp 0x7f64474fbd70 sp 0x7f64474fbb10 T4)                                                                                ==23999==The signal is caused by a READ memory access.                                                                                                                                                             ==23999==Hint: address points to the zero page.
    #0 0x54c69d in InterrogationCommand_getQOI /root/temp/iec/lib60870/lib60870-C/src/iec60870/cs101/cs101_information_objects.c:5616:18
    #1 0x58aa85 in handleASDU /root/temp/iec/lib60870/lib60870-C/src/iec60870/cs104/cs104_slave.c:1724:59
    #2 0x58aa85 in handleMessage /root/temp/iec/lib60870/lib60870-C/src/iec60870/cs104/cs104_slave.c:2043
    #3 0x5882b6 in connectionHandlingThread /root/temp/iec/lib60870/lib60870-C/src/iec60870/cs104/cs104_slave.c:2410:21
    #4 0x5a0962 in destroyAutomaticThread /root/temp/iec/lib60870/lib60870-C/src/hal/thread/linux/thread_linux.c:87:2
    #5 0x7f644c5116b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)
    #6 0x7f644b91c41c in clone /build/glibc-LK5gWL/glibc-2.23/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:109

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /root/temp/iec/lib60870/lib60870-C/src/iec60870/cs101/cs101_information_objects.c:5616:18 in InterrogationCommand_getQOI
Thread T4 created by T1 here:
    #0 0x431d2d in __interceptor_pthread_create (/root/temp/iec/lib60870/lib60870-C/examples/cs104_server/simple_server+0x431d2d)
    #1 0x5a05eb in Thread_start /root/temp/iec/lib60870/lib60870-C/src/hal/thread/linux/thread_linux.c:98:3
    #2 0x7f644c5116b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9)

Thread T1 created by T0 here:
    #0 0x431d2d in __interceptor_pthread_create (/root/temp/iec/lib60870/lib60870-C/examples/cs104_server/simple_server+0x431d2d)
    #1 0x5a06bb in Thread_start /root/temp/iec/lib60870/lib60870-C/src/hal/thread/linux/thread_linux.c:102:3

==23999==ABORTING

The BitString32_create, Bitstring32WithCP24Time2a_create, Bitstring32WithCP56Time2a_create functions do not provide a QualityDescriptor argument to set the quality.
Are there other ways to set the quality field?

Hello.

Valgrind says:

==9657== Conditional jump or move depends on uninitialised value(s)
==9657==    at 0x12959D: Socket_connect (socket_linux.c:319)
==9657==    by 0x127F72: handleConnection (cs104_connection.c:733)
==9657==    by 0x488E181: start_thread (pthread_create.c:486)
==9657==    by 0x49C3B1E: clone (clone.S:95)
==9657==  Uninitialised value was created by a stack allocation
==9657==    at 0x12937F: Socket_connect (socket_linux.c:280)

Looks like it's happens after timed out connection attempt.

Thank you.

In the "socket_linux.c" file socket descriptor is closed in case of connection timeout at the end of Socket_connect function. And then this socket descriptor is closed again in function Socket_destroy. But it descriptor may be already reused in other thread.
In files "socket_win32.c" and "socket_bsd.c" there is no closing socket on timeout in Socket_connect.

chs takes the same value as lsq, because the increment of startIndex has been missed.

Hi team,

There is a NULL pointer dereference in link_layer.c

Snip link_layer.c

LinkLayer_setAddress(LinkLayer self, int address)
{
    self->address = address;
}

Stack-trace

==5832==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x55eb02eed6a2 bp 0x7ffc3b237e30 sp 0x7ffc3b237e20 T0)
==5832==The signal is caused by a READ memory access.
==5832==Hint: address points to the zero page.
    #0 0x55eb02eed6a1 in LinkLayer_setAddress /home/input0/Desktop/lib60870/lib60870-C/src/iec60870/link_layer/link_layer.c:142
    #1 0x55eb02eeab30 in CS101_Master_setOwnAddress /home/input0/Desktop/lib60870/lib60870-C/src/iec60870/cs101/cs101_master.c:311
    #2 0x55eb02ec4601 in main /home/input0/Desktop/lib60870/lib60870-C/examples/cs101_master_balanced/master_example.c:127
    #3 0x7fb921c52b96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #4 0x55eb02ec40f9 in _start (/home/input0/Desktop/lib60870/lib60870-C/build/examples/cs101_master_balanced/cs101_master_balanced+0x120f9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/input0/Desktop/lib60870/lib60870-C/src/iec60870/link_layer/link_layer.c:142 in LinkLayer_setAddress
==5832==ABORTING

I have a threaded application where one thread produces new ASDUs and another thread is responsible for slave connection handling. The server is running in the following mode:
CONFIG_CS104_SUPPORT_SERVER_MODE_CONNECTION_IS_REDUNDANCY_GROUP = 1

For low priority ASDUs (e.i. periodic measurements) I test CS104_Slave_getOpenConnections() > 0 in prior to calling CS104_Slave_enqueueASDU(slave, asdu).

It is a race condition that arises if a client closes the connection:
-> connectionHandlingThread: connectionEventHandler gets called (cs104_slave.c 2526)
-> connectionHandlingThread: release / frees the queue and the corresponding queueLock semaphore (cs104_slave.c 2535f)
-> MyThread: CS104_Slave_getOpenConnections() is still 1
-> MyThread: tries to send an ASDU by calling CS104_Slave_enqueueASDU(slave, asdu)
-----> locks self->openConnectionsLock (cs104_slave.c 3184)
-----> calls MessageQueue_enqueueASDU
-----------> waits forever for self->queueLock (DEADLOCK) (cs104_slave.c 269)
-> connectionHandlingThread: calls CS104_Slave_removeConnection(self->slave, self) (cs104_slave.c 2540)
----> waits forever for self->openConnectionsLock (DEADLOCK) (cs104_slave.c 2427)

On a x86 PC the race condition isn't happening that often, but it is easily reproducible on a raspberry pi (armhf32).

I could bypass this situation with an own connectionMap maintained within the connectionEventHandler-callback to test if there is an active connection or not to be able to discard new ASDUs, but I think you might want to fix this issue.