E-GMP: phone validation methods

Abierto
  • ¿Algo no está bien?
#92 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
embedded-iot, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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).
Lenguaje dominante
Rust
Estrellas
1
Forks
0
Merge medio
13 h 27 min
PR fusionados (30 d)
31

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Sin Dockerfile ni archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OpenCarControls/firmware

Todos los issues de OpenCarControls/firmware

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.