Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

REDLINK SDK v6.32.7 Released

T

Trent Lillehaugen

Red Team
Joined
Aug 22, 2011
Messages
1,172
Reaction score
0
Points
0
REDLINK SDK v6.32.x is a minor update to REDLINK SDK v6.31.x, adding support for new weapon modules and fixing several bugs.


- Fixed typos/wording of comments
- Fixed labels
- Fixed typo (from RCP_API_ENABLE_CACHEING to RCP_API_ENABLE_CACHING)
- Fixed bug where 'is_hw_supported_valid' was not cleared when connecting to a camera
- Fixed RCP_PARAM_HDR_FACTOR not updating on boot
- Fixed bug in handling hardware capabilities for odler firmware
- Added parameters:
RCP_PARAM_SERIAL_2_PROTOCOL
RCP_PARAM_POWER_OUT_REAR_AUX_ENABLE
RCP_PARAM_POWER_OUT_REAR_AUX_STATUS
RCP_PARAM_POWER_OUT_REAR_AUX_RESET
RCP_PARAM_POWER_OUT_REAR_AUX_CURRENT
RCP_PARAM_POWER_OUT_TIMECODE_ENABLE
RCP_PARAM_POWER_OUT_TIMECODE_STATUS
RCP_PARAM_POWER_OUT_TIMECODE_RESET
Click to expand...


Always check https://www.red.com/developers for the most up to date version of the SDK.
 
Trent - Does the REDlink update automatically or do we have to do it separate from the camera? (I just don't remember.) Sorry to be lazy -is there a link?

oops - this is SDK. Was thinking of firmware.
 
REDLINK SDK - Code Analysis : rcp_api_process_data.c : Function : _rcp_process_hist_packet()

Comment: I believe there is code error in this function that could result in invalid memory access (ie a possible crash).

Code Fragment

int start_index = 0;
int ii = 0;
start_index = get_hex_encoded_byte(param);

while (ii < 128)
{
const int32_t high_nibble = (raw_data[(ii - start_index) / 2] & 0xF0) >> 4;
const int32_t low_nibble = (raw_data[(ii - start_index) / 2] & 0x0F);
..
}


Analysis

When get_hex_encoded_byte() returns a value of > 0, the high_nibble and low_nibble code will may access negative subscripts ( invalid parts of memory. )


AJ
 
Antony Newman said:
REDLINK SDK - Code Analysis : rcp_api_process_data.c : Function : _rcp_process_hist_packet()

Comment: I believe there is code error in this function that could result in invalid memory access (ie a possible crash).

Code Fragment

int start_index = 0;
int ii = 0;
start_index = get_hex_encoded_byte(param);

while (ii < 128)
{
const int32_t high_nibble = (raw_data[(ii - start_index) / 2] & 0xF0) >> 4;
const int32_t low_nibble = (raw_data[(ii - start_index) / 2] & 0x0F);
..
}


Analysis

When get_hex_encoded_byte() returns a value of > 0, the high_nibble and low_nibble code will may access negative subscripts ( invalid parts of memory. )


AJ
Click to expand...

Thanks for pointing this out. It will be fixed in a future release. As it turns out we weren't ever using the bad (it was guarded below in the following if statements with 'ii > start_index'), but we were certainly reading from an invalid memory location.
 
REDLINK SDK - Code Analysis : c_list.c Function : c_list_delete()


Code Fragment

 if (!c_list)
{
return C_LIST_PARAM_ERROR;
}
else
{
(void) c_list_clear(c_list);
c_list->free(c_list);
return C_LIST_SUCCESS;
}


Analysis

+) The c_list_delete() routine is permitted to returns errors.
+) The (void) masks any errors that c_list_clear() reports - ie returning a C_LIST_SUCCESS when the clear fails.


Suggestion

Amend this code to:

c_list_error_t err = c_list_clear(c_list);
c_list->free(c_list);
return err;


AJ
 
Last edited:
RESOLVED : USER (LEARNING) ERROR :-)

REDLINK SDK - Code Analysis : c_list.c Function : _c_list_import_normal_string()

Comment: I believe there is code error or documention error (or it could be that I am barking up the wrong tree!)

Code Fragment from _c_list_import_normal_string()

idx = atoi(buffer1);
...
/* Set index */
if (idx >= 0)
{
err = c_list_set_index(c_list, idx);
..
}

return C_LIST_SUCCESS;


Analysis

+) My (very basic) understanding is that this when a RCP message is sent like : #$WEAPON:D:MMMODE:0|-1|:
that the -1 will be translated into a number and stored in 'idx'

+) This prevents c_list_set_index() from being called due to 'if (idx >= 0)'
+) The knock on effect is that c_list_t structures 'cur' will remain unset = NULL (and not equate to a valid position in the linked list)

+) This will cause the following routines to fail:
clist.cpp cList::Error cList::getIndex(size_t &idx) const
c_list.c c_list_get_index()


Uncertainty

Opening up the RCPDemo code : I note that failure of the C++ routine is ignored. loadListData list->getIndex(currentRow);

.. And so now I am unsure if the this is a deliberate failure (ie that -1 values are being used to caused link list failures)


AJ

RESOLVED : USER (LEARNING) ERROR :-)
 
Last edited:
Antony Newman said:
REDLINK SDK - Code Analysis : c_list.c Function : _c_list_import_normal_string()

Comment: I believe there is code error or documention error (or it could be that I am barking up the wrong tree!)

Code Fragment from _c_list_import_normal_string()

idx = atoi(buffer1);
...
/* Set index */
if (idx >= 0)
{
err = c_list_set_index(c_list, idx);
..
}

return C_LIST_SUCCESS;


Analysis

+) My (very basic) understanding is that this when a RCP message is sent like : #$WEAPON:D:MMMODE:0|-1|:
that the -1 will be translated into a number and stored in 'idx'

+) This prevents c_list_set_index() from being called due to 'if (idx >= 0)'
+) The knock on effect is that c_list_t structures 'cur' to be NULL (and not equate to a position in the linked list)

+) This will cause the following routines to fail:
clist.cpp cList::Error cList::getIndex(size_t &idx) const
c_list.c c_list_get_index()


Uncertainty

Opening up the RCPDemo code : I note that failure of the C++ routine is ignored. loadListData list->getIndex(currentRow);

.. And so now I am unsure if the this is a deliberate failure (ie that -1 values are being used to caused link list failures)


AJ
Click to expand...

"0|-1|" represents an empty list. It doesn't make sense for an empty list to contain an index, and therefore it doesn't make sense to get or set the index.
 
REDLINK SDK - Code Analysis : rcp_api.h

Question) What is the RCP intention when sending out a message like: #$WEAPON:D:MMMODE:0|-1|:

typedef struct
{
...

int display_str_in_list; /* If true, the display string needs to be retrieved from this list rather than current message. */
...
} rcp_cur_list_cb_data_t



For the '#$WEAPON:D:MMMODE:0|-1|:' this converts to:
-> id : RCP_PARAM_MM_MODE
* -> list_string : 0|-1|
* -> list_string_valid : true
* -> display_str_in_list : true <--- Not sure what the intention is here?
* -> min_val_valid : false
* -> min_val : INVALID
* -> max_val_valid : false
* -> max_val : INVALID
* -> send_INT_back : true
* -> send_UINT_back : false
* -> send_STR_back : false
* -> update_only_on_close : false

Analysis

+) If my understanding is correct -> this results in "display string needs to be retrieved from this list rather than current message"
+) Should 'display_str_in_list' be false, or the comment amended.
+) When an RCP List Parameter is send with No List .... is there a purpose to the message?

Thanks,
AJ
 
Antony Newman said:

Question) What is the RCP intention when sending out a message like: #$WEAPON:D:MMMODE:0|-1|:
Click to expand...

I'm not sure what you mean when you say "what is the intention?". As you already know, "0|-1|" represents an empty list. I'm assuming on the camera you are connected to you do not have a Motion Mount installed - if you did, this list would not be empty.

Antony Newman said:
+) If my understanding is correct -> this results in "display string needs to be retrieved from this list rather than current message"
Click to expand...

That is correct, the field 'display_str_in_list' means that the display string for the given parameter should be retrieved from the list and not the normal "current" message.

Antony Newman said:
+) Should 'display_str_in_list' be false, or the comment amended.
Click to expand...

No, I don't think so. For this parameter you SHOULD get the display string from the list, it just so happens that there are no list entries (since the Motion Mount is not installed).

Antony Newman said:
+) When an RCP List Parameter is send with No List .... is there a purpose to the message?
Click to expand...

This might be a matter of semantics, but the message WAS sent with a list, just an empty list. If the question is what should your application do in response to this message I would suggest to either display an empty string or something like "N/A" to the user.

There is a bug in the API that will be fixed in a soon to be released version where RCP_PARAM_MM_MODE (MM_MODE) was not returning 0 when 'rcp_get_is_supported' is called if no Motion Mount was installed. In the corrected API code, this discussion would be pointless, as your code should ignore any parameters that are not supported for the connect camera.
 
You must log in or register to reply here.
Back
Top