New Feature: attempt to dump all device identifiers (DIDs)

[alexdetrano]

Hi, I added the ability to brute force all device identifiers. Not sure if there is any interest for this feature but it's something I thought would be useful and I always end up writing hacky bash scripts to achieve this, so I thought it would be nice to add it to caringcaribou. The script attempts to issue UDS commands for read data by device identifier (SID 0x22) and only reports positive responses.

You can use it like python3 cc.py uds dump_dids --min_did 0xf187 --max_did 0xf188 0x710 0x7e8

You need to specify the source arbitration ID, the destination arbitration ID, the range of DIDs using minimum and maximum values.

Help feature looks like:

alex@debvm ~/s/c/tool> python3 cc.py uds dump_dids --help

-------------------
CARING CARIBOU v0.3
-------------------

Loaded module 'uds'

usage: cc.py uds dump_dids [-h] [-t T] [--min_did MIN_DID] [--max_did MAX_DID]
                           src dst

positional arguments:
  src                arbitration ID to transmit to
  dst                arbitration ID to listen to

optional arguments:
  -h, --help         show this help message and exit
  -t T, --timeout T  wait T seconds for response before timeout
  --min_did MIN_DID  minimum device identifier (DID) to read (default: 0x0000)
  --max_did MAX_DID  maximum device identifier (DID) to read (default: 0xFFFF)

I don't have real hardware to test against so I've been using a virtual CAN bus and simulating an ECU that responds with a positive response to DID 0xf187 and a negative response to 0xf188. An example run looks like

alex@debvm ~/s/c/tool> python3 cc.py uds dump_dids --min_did 0xf187 --max_did 0xf188 0x710 0x7e8

-------------------
CARING CARIBOU v0.3
-------------------

Loaded module 'uds'

Dumping DIDs in range 0xf187-0xf188

Identified DIDs:
DID    Value (hex)
0xf187 62f1deadbeeffeedface414243

I also added a unit test which could probably be improved upon. I am open to suggestions.

[kasperkarlsson]

Hi @alexdetrano and thank you for sending this PR!

Let me start off by saying that this both looks and works great :+1:

I only have one request - the unit test currently takes several seconds to run, due to the full DID range 0x0000-0xffff being brute forced. Would you mind decreasing the test range a bit, e.g. to 0x0100-0x0301 (with an expected response count of 3)? This avoids introducing any significant delay when running ./cc.py -i vcan0 test and still ensures that valid results are produced.

Also, feel free to add your name to the Contributors section of the README.md file, if you would like some extra exposure :wink:

Thanks again for contributing, I am looking forward to merging this request!

[alexdetrano]

thanks! glad you like it. I reduced the test cases from 0x0 - 0x101, this way we still get 2 positive responses and no significant delay is added to the unit tests. It still feels pretty snappy :)

[kasperkarlsson]

Awesome! Thanks again - this new feature both looks and feels just perfect :grin: :+1: