BLE: No Valid Parameter check in send_conn_le_param_update()

[kipm-ot]

According to Core spec v5.1 vol 3 part A section 4.20: "CONNECTION PARAMETER UPDATE REQUEST", data fields in the Connection Parameter update request are Interval Min , Interval Max, Slave Latency and Timeout Multiplier. And their possible value ranges are as follows.

Interval Min : 6 to 3200
Interval Max : 6 to 3200
Slave Latency : 0 to 499
Timeout Multiplier : 10 to 3200.

But in send_conn_le_param_update() in conn.c, we are not checking the input parameter value ranges which cause issues as below.

Problem:
In conn_update_timeout(), When CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS is enabled it will take the above parameters (Interval Min , Interval Max, Slave Latency and Timeout Multiplier) from the Characteristics and accordingto Peripheral Preferred Connection Parameters characteristic Interval Min and Interval Max can have a value 0xFFFF (which means server do not have specific min/max values, master can decide).And when 0xFFFF is invalid in send_conn_le_param_update() which causes issues as Master do not expects 0xFFFF.

Solution:
In, send_conn_le_param_update(), we will have to add checks for the param values and then only send the update request. Ideally in the above case, if the values are fetched from
CONFIG_BT_GAP_PERIPHERAL_PREF_PARAMS which contains 0xFFFF then probabaly we need to send request with internal values (eg. conn->le.interval_min)

[jhedberg]

@Vudentz do you wanna look at this? It seems you introduced the 0xffff values in commit 593d856

[jhedberg]

@kipm-ot @aescolar what do you think the right policy should be? If any of the values is set to 0xffff we don't initiate param update triggered by the timer?

[jhedberg]

Sorry, just saw your proposed solution in the description @kipm-ot. Sounds reasonable to me. Are you planning to submit a PR?

[kipm-ot]

@jhedberg No worries, yes we will do a PR.