Corrected NTCIP1218 msgRepeatsOption value

[dmccoystephenson]

PR Details

Description

Problem

The SnmpNTCIP1218Protocol class is currently using 0x00 for the msg repeats options value, which is incorrect (for the context of deploying an unsigned TIM). It should be using 0x80.

Solution

The value being used for the msg repeats options value in the SnmpNTCIP1218Protocol class has been changed to 0x80.

Related Issue

No related GitHub issue.

Motivation and Context

The SnmpNTCIP1218Protocol class should use the correct value for the msg repeats option value to ensure a successful deposit.

How Has This Been Tested?

Depositing to an RSU has been verified to work with this change.

Types of changes

• Defect fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that cause existing functionality to change)

Checklist:

• I have added any new packages to the sonar-scanner.properties file
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
  ODE Contributing Guide
• I have added tests to cover my changes.
• All new and existing tests passed.

[mwodahl]

Looks good to me!

[drewjj]

It is important to note that x00 isn't incorrect entirely. It is incorrect for the context of deploying an unsigned TIM.

[dmccoystephenson]

It is important to note that x00 isn't incorrect entirely. It is incorrect for the context of deploying an unsigned TIM.

Will deploying a signed TIM using 0x80 work?

[drewjj]

It is important to note that x00 isn't incorrect entirely. It is incorrect for the context of deploying an unsigned TIM.

Will deploying a signed TIM using 0x80 work?

If it is deployed to an RSU to be broadcasted from a RSU it will not work. 0x80 tells the RSU to sign the message before broadcasting it. This will cause an already signed message to be doubly wrapped with a 1609.2 header.

In summary:
0x00 - Tells the RSU to broadcast the message without signing it or attaching a 1609.2 header to it.
0x80 - Tells the RSU to sign and attach a 1609.2 header before broadcasting the message.

0xC0 shouldn't be used ever because it achieves some weird hybrid of the two.

[payneBrandon]

It is important to note that x00 isn't incorrect entirely. It is incorrect for the context of deploying an unsigned TIM.

Will deploying a signed TIM using 0x80 work?

If it is deployed to an RSU to be broadcasted from a RSU it will not work. 0x80 tells the RSU to sign the message before broadcasting it. This will cause an already signed message to be doubly wrapped with a 1609.2 header.

In summary: 0x00 - Tells the RSU to broadcast the message without signing it or attaching a 1609.2 header to it. 0x80 - Tells the RSU to sign and attach a 1609.2 header before broadcasting the message.

0xC0 shouldn't be used ever because it achieves some weird hybrid of the two.

@drewjj do we need a way to configure this then, to allow a choice of whether to have the RSU sign or just forward?

[drewjj]

It is important to note that x00 isn't incorrect entirely. It is incorrect for the context of deploying an unsigned TIM.

Will deploying a signed TIM using 0x80 work?

If it is deployed to an RSU to be broadcasted from a RSU it will not work. 0x80 tells the RSU to sign the message before broadcasting it. This will cause an already signed message to be doubly wrapped with a 1609.2 header.
In summary: 0x00 - Tells the RSU to broadcast the message without signing it or attaching a 1609.2 header to it. 0x80 - Tells the RSU to sign and attach a 1609.2 header before broadcasting the message.
0xC0 shouldn't be used ever because it achieves some weird hybrid of the two.

@drewjj do we need a way to configure this then, to allow a choice of whether to have the RSU sign or just forward?

Yeah, that would be ideal if we want the ODE to be flexible. This pr seems like it has half the solution. #67

[dmccoystephenson]

Marking this as a draft for now until we modify the functionality to use 0x00 / 0x80 depending on context.