Hi Michal, > -----Original Message----- > From: linux-bluetooth-owner@xxxxxxxxxxxxxxx [mailto:linux-bluetooth- > owner@xxxxxxxxxxxxxxx] On Behalf Of Michal Lowas-Rzechonek > Sent: Thursday, June 27, 2019 12:41 AM > To: linux-bluetooth@xxxxxxxxxxxxxxx > Cc: Gix, Brian <brian.gix@xxxxxxxxx> > Subject: [PATCH BlueZ v3 2/2] mesh: Use current IV Index when relaying > > If we are in IV Update state, packets shall be transmitted using IV Index - 1, > including relayed packets. > --- > mesh/net.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mesh/net.c b/mesh/net.c > index a5693f154..0a6ff8eac 100644 > --- a/mesh/net.c > +++ b/mesh/net.c > @@ -2512,7 +2512,7 @@ static void net_rx(void *net_ptr, void *user_data) > relay_advice = packet_received(net, key_id, iv_index, > out, out_size, rssi); > if (relay_advice > data->relay_advice) { > - data->iv_index = iv_index; > + data->iv_index = mesh_net_get_iv_index(net); I don't think this is correct. *relayed* packets must preserve the originators IV_Index... At most, two different IV_Index values are considered valid at any time in the mesh. Each node has it's own sense as to what the *Network* IV_Index is, and it shall accept that IV_Index, and 1 less... With this difference reflected in the IVI bit of the first octet. When acting as a relay, incoming messages must be one of these two settings to be recognized, but after decrementing TTL and re-encrypting, the IV_Index of the original sender must be preserved. The iv_index is part of both the Network nonce and the Access layer nonce. If a relay uses a different nonce than the originator (SRC), then the receiving DST device will be unable to decrypt the Access layer using the same nonce as the repackaged Network layer. > data->relay_advice = relay_advice; > data->key_id = key_id; > data->net = net; > -- > 2.19.1
