commaai / opendbc

democratize access to car decoder rings

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

CANParser: invalid counter counter wraps around

sshane opened this issue · comments

I assume the counter checks are intended to match between opendbc and panda, so while testing I noticed a mismatch as well as a bug:

panda clips the invalid counter counter to 5, but opendbc lets it wrap around no problem since it's a uint8_t:

counter_fail += 1;

0x201 COUNTER FAIL #253 -- 9 -> 9
opendbc/can/parser.cc: 0x201 message checks failed, checksum failed 0, counter failed 1
ret.gas 63427.0 safety gas 17731
0x201 COUNTER FAIL #254 -- 9 -> 4
opendbc/can/parser.cc: 0x201 message checks failed, checksum failed 0, counter failed 1
ret.gas 63427.0 safety gas 17731
0x201 COUNTER FAIL #255 -- 4 -> 15
opendbc/can/parser.cc: 0x201 message checks failed, checksum failed 0, counter failed 1
0x201 COUNTER FAIL #2 -- 9 -> 1
ret.gas 23536.0 safety gas 17731
0x201 COUNTER FAIL #3 -- 1 -> 13
ret.gas 107119.0 safety gas 17731
0x201 COUNTER FAIL #4 -- 13 -> 9
ret.gas 57396.0 safety gas 17731

TODO:

  • fix
  • some test that ensures CANParser doesn't go valid again after some time

@deanlee if you find this fun, otherwise I'll do it tomorrow 🙂

I'm afraid that I can't fix this properly. All I can think of at the moment is using a counter_fail = std::min(MAX_BAD_COUNTER, counter_fial+1) . But I'm not sure if it can really solve the problem.

I think we want to match panda behavior here, so that is correct. In my fuzzing test which tests that both parse messages the same, this difference in bad counter windup causes some mismatches.

yeah let's just clip to something like uint8t_max

panda clips to 5 (max bad counters), so there will be some mismatch there as well. opendbc's CANParser also has this 5 limit, it just didn't clip it to that, or anything.