Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Implement CAN logging with SavvyCAN's protocol

Open
  • Is something wrong?
#10 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
embedded-iot, networking

Research direction

Read the existing CAN debug implementation in core-interface/src/can_debug.rs and trace the board taps, MCP2515 debug mask switching, and publish_can_debug_task mentioned in the issue. Then identify the firmware entry points for vehicle tasks, client disconnects, and command/state queues. Done means SavvyCAN protocol logging sends CAN frames over Wi-Fi, handles disconnect and read-only behavior, validates bus IDs, and accounts for the listed legacy CAN debug path.

Written by the indexing model from the issue text.

Description

We need a way to make it easy to reverse engineer CAN buses from the firmware itself. The idea is to implement SavvyCAN's network protocol and send CAN frames using Wifi. We may need to disable the normal vehicle tasks when using this.

There was already a CAN debug tool that was started to be implemented in the firmware, but it will be easier to just use SavvyCAN instead.

Notes from the audit (old BLE CAN debug, still in main)
  • Remove the old BLE CAN-debug path as part of this (or before):
    core-interface/src/can_debug.rs, CAN_DEBUG_RX_CHANNEL, the board taps,
    MCP2515 debug mask switching, and publish_can_debug_task. In contracts,
    mark SetCanDebugEnabled / UpdateCanDebugFilters / CanDebugUpdate
    [deprecated = true] (append-only rule).
    Until then it's reachable by any bonded phone: SetCanDebugEnabled with
    bus_id >= 8 panics with a shift overflow in debug builds
    (can_debug.rs:73, also :46). Release builds silently wrap.
  • Lessons for the new version:
    • Validate bus_id against MAX_CAN_BUSES / the configured bus count.
    • Turn logging off when the client disconnects (the old one stays on).
    • With "disable normal vehicle tasks", also force read-only on.
    • Keep logging traffic off the shared command/state queues.
Dominant language
Rust
Stars
1
Forks
0
Avg merge
10h 56m
Merged PRs (30d)
15

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenCarControls/firmware

All issues in OpenCarControls/firmware

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.