E-GMP: phone validation methods

未关闭
  • 哪里不对？
#92 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
rust
领域
embedded-iot, security

调研方向

Read issues #74 and #90, then inspect the E-GMP vehicle crate, core-interface, the virtual-car validation methods, and the DBC signals for the candidate buttons. The issue says to start with the passive ignition-and-button method, but captures and a maintainer decision on the button are still needed. Done means E-GMP runs validation sessions through core-interface, host tests cover the listed failure cases, and docs/ble.md and docs/can.md document the verified signal.

由索引模型根据 Issue 内容生成。

描述

e-gmp enhancement

Part of the prerequisites for real commands (#75). Follow-up to #74 (design) and #90 (implementation). The app side is OpenCarControls/mobile-app#60.

Problem

Since #90, a bonded phone can't send vehicle commands until it is validated in the car: the owner does something there that a stranger near the car can't. The mechanism lives in core-interface, and the vehicle crate provides the methods. virtual-car has two simulated ones (a code shown on the cluster, and a button). E-GMP provides none, so a phone can never be validated on a real car and every E-GMP command (#37–#42) would be refused with REJECTED_NOT_VALIDATED.

Proposal

Give the E-GMP crate at least one validation method. #74 names two candidates:

  1. Ignition on + a button (passive). The phone starts a session, the owner switches the car on and presses a button in the car a set number of times within the session timeout. This needs no transmit and no CAN read-write approval, so it works on a freshly installed device.
  2. A code shown on the cluster. The device sends a fresh code to the instrument cluster and the owner types it into the app. This transmits, so it needs frames captured from the car and the CAN read-write approval (the code is a platform frame, not a vehicle command). Do it after the first method.

Start with the passive one.

Passive method: what to decide
  • Which button. It must be something only someone inside the switched-on car can do, and its signal must be on M-CAN and verified. Candidates already in the DBC: the hazard switch, the rear camera button, Auto Hold, the brake switch. Check which of them change cleanly and can't be triggered from outside the car.
  • The ignition condition. The power state is already decoded (accessory, on, ready); decide which states count. The bus must be awake.
  • The sequence. The app shows the instructions from the method_id alone (no text comes from the device), so the sequence is fixed per method, for example three presses within the session timeout. Choose it so a single accidental press doesn't validate, and write down why.
  • Reporting. The vehicle reports success for the requesting phone's source_device_id; core-interface stores the validation.
Contracts and app
  • A stable method_id per method (for example egmp.ignition_button, egmp.cluster_code). No user-facing text in the contract or from the device.
  • Whether the method needs the approval is declared by the vehicle, as for virtual-car's methods.
  • The app maps each method_id to localized text, with a generic fallback per kind. Add the E-GMP identifiers to the list in mobile-app#60.

Needs from the maintainer

Captures from the car of the candidate buttons (with timed notes), and the decision on which one to use.

Done when

  • E-GMP lists its method(s) and runs the session through core-interface, with host tests using captured frames, including negative tests: ignition off, the wrong button, too few presses, a press after the timeout, a press during another phone's session.
  • The behaviour is documented in docs/ble.md and docs/can.md, with the button signal verified in the DBC.
  • An end-to-end test on the car, once mobile-app#60 lands: a newly paired phone validates and can send the first command (#39).
主要语言
Rust
星标
1
派生
0
平均合并
13 小时 27 分钟
30 天内合并 PR
31

环境准备

在 Codespaces 中打开

在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

OpenCarControls/firmware 的其他 Issue

查看 OpenCarControls/firmware 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。