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
# API and build change and fix summaries. Doc correctsions
# and/or changes are not mentioned here; see the commit messages.
# 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)
2020 April 22; version 4.0.1
Correct message type constant for Traffic Steering predication (RIC-342)
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( 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( install_root "${CMAKE_INSTALL_PREFIX}" )
set( install_inc "include/rmr" )
set( install_root "${CMAKE_INSTALL_PREFIX}" )
set( install_inc "include/rmr" )
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.
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
*/
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 ) {
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
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
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
blen++;
*blen = htonl( len ); // new systems want a converted integer
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
}
buf[TP_SZFIELD_LEN-1] = TP_SZ_MARKER; // marker to flag this is generated by a new message
}