ISOTP can id UDS support

[melvinvdb]

Is your enhancement proposal related to a problem? Please describe.
The problem:
The current isotp library only supports listening and sending CAN message on the same CAN ID.
I have to explain this with some diagrams.
The current sample works like this:

It listens and sends message on the same CAN ID.
Note the CAN RX filters it adds here; this works fine.

Now UDS (unified diagnostic services):
With UDS every device has it's own CAN ID.
ECU 1 has CAN ID 0x7E0.
Tester 1 has CAN ID 0x7E8.
The ECU should listen on 0x7E0 and always respond on 0x7E8.
This looks like the following:

This means that the isotp_bind binds to the RX address instead of the TX address from the sample.
The current library doesn't support this as it adds a can rx filter to the same address twice.
In the sample this is 0x7E8.
This results in the following errors:

22 F1 80
Got 3 bytes in total
returning received len 3
[00:24:37.587,188] uds_handler: UDS event UDS_EVT_ReadDataByIdent
Sending 23 bytes
[00:24:37.591,156] isotp: Got unexpected frame. Ignore
[00:24:38.564,483] isotp: Reception of next FC has timed out
Error while sending data to ID 2024 [-2]

The isotp_bind method does a can_add_rx_filter on 0x7E0. When executing method send, this method also executes can_add_rx_filter on the same address. This causes the incorrect method to be called for FC handling.

Describe the solution you'd like
The library should only do one can_add_rx_filter when calling isotp_bind and should not call can_add_rx_filter again when doing a send.

Describe alternatives you've considered
The only consideration for me is modifying the library.

[henrikbrixandersen]

CC: @martinjaeger

[martinjaeger]

Thanks @melvinvdb for raising the issue.

It's a known limitation in the current implementation that we cannot bind and transmit with the same CAN ID, see #59896.

We started implementing a reworked version of the ISO-TP stack, but didn't finish it up. See above mentioned issue for some further background information regarding other shortcomings.

If you'd like to work on an improved ISO-TP stack, just let us know. I'm happy to support with reviews.