Fix SI95 transport header length bug

A bug in the buffer length extraction from the SI95 transport
header was causing failures when communicating with an application
using a backlevel version of RMR.  Symptoms were dropped return
to sender messages, and a flood of messages with type 0.  This
fix corrects this problem.

Issue-ID: RIC-341

Signed-off-by: E. Scott Daniels <daniels@research.att.com>
Change-Id: I0223608c26917a5f94378fd83e1bb71be93999fe

diff --git a/CHANGES_CORE.txt b/CHANGES_CORE.txt
index 4a275d8..6299123 100644 (file)
--- a/CHANGES_CORE.txt
+++ b/CHANGES_CORE.txt
@@ -5,6 +5,9 @@
 # API and build change  and fix summaries. Doc correctsions
 # and/or changes are not mentioned here; see the commit messages.
 
+2020 April 24; version 4.0.2
+       Correct bug in SI95 transport header length validation (RIC-341)
+
 2020 April 22; version 4.0.1
        Correct message type constant for Traffic Steering predication (RIC-342)
 

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 578a484..c7c4c95 100644 (file)
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -41,7 +41,7 @@ cmake_minimum_required( VERSION 3.5 )
 
 set( major_version "4" )               # should be automatically populated from git tag later, but until CI process sets a tag we use this
 set( minor_version "0" )
-set( patch_level "1" )
+set( patch_level "2" )
 
 set( install_root "${CMAKE_INSTALL_PREFIX}" )
 set( install_inc "include/rmr" )

diff --git a/src/rmr/si/src/mt_call_si_static.c b/src/rmr/si/src/mt_call_si_static.c
index fbbffaf..76b56b2 100644 (file)
--- a/src/rmr/si/src/mt_call_si_static.c
+++ b/src/rmr/si/src/mt_call_si_static.c
@@ -110,14 +110,26 @@ static void buf2mbuf( uta_ctx_t* ctx, char *raw_msg, int msg_size, int sender_fd
        byte order. If <mark> is not present, we use <int1>. This allows
        old versions of RMR to continue to work with new versions that now
        do the right thing with byte ordering.
+
+       If the receiver of a message is a backlevel RMR, and it uses RTS to
+       return a message, it will only update the old size, but when the
+       message is received back at a new RMR application it will appear that
+       the message came from a new instance.  Therefore, we must compare
+       the old and new sizes and if they are different we must use the old
+       size assuming that this is the case.
 */
 static inline uint32_t extract_mlen( unsigned char* buf ) {
        uint32_t        size;           // adjusted (if needed) size for return
+       uint32_t        osize;          // old size
        uint32_t*       blen;           // length in the buffer to extract
 
        blen = (uint32_t *) buf;
        if( *(buf + sizeof( int ) * 2 ) == TP_SZ_MARKER ) {
+               osize = *blen;                                                  // old size
                size = ntohl( *(blen+1) );                              // pick up the second integer
+               if( osize != size ) {                                   // assume back level return to sender
+                       size = osize;                                           // MUST use old size
+               }
                if( DEBUG > 1 ) rmr_vlog( RMR_VL_DEBUG, "extract msg len converted from net order to: %d\n", size );
        } else {
                size = *blen;                                                   // old sender didn't encode size

diff --git a/src/rmr/si/src/sr_si_static.c b/src/rmr/si/src/sr_si_static.c
index 798fe26..69e69e9 100644 (file)
--- a/src/rmr/si/src/sr_si_static.c
+++ b/src/rmr/si/src/sr_si_static.c
@@ -126,6 +126,7 @@ static inline void insert_mlen( uint32_t len, char* buf ) {
        blen++;
        *blen = htonl( len );                                   // new systems want a converted integer
 
+       memset( &buf[TP_SZFIELD_LEN], 0, 4 );   // clear to prevent future conversion issues
        buf[TP_SZFIELD_LEN-1] = TP_SZ_MARKER;   // marker to flag this is generated by a new message
 }