PC board: an unreachable MQTT broker blocks the whole firmware

Abierto
  • ¿Algo no está bien?
#89 0 comentarios 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
embedded-iot

Línea de trabajo

Start with boards/pc/src/network.rs and trace mqtt_driver_task and how the PC board runs tasks on its Embassy executor. Compare its connection path with the other stream code that uses Embassy timers. Done means an unreachable broker no longer blocks the BLE HTTP server, CAN, or vehicle tasks while MQTT retries; the issue does not name specific tests.

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

Descripción

bug

Problem

mqtt_driver_task on the PC board (boards/pc/src/network.rs) opens the broker connection with a blocking std::net::TcpStream::connect. The PC board runs every task on one Embassy executor thread, so while that connect waits, nothing else runs: no BLE test HTTP server, no CAN, no vehicle tasks, no state publishing.

A refused connection returns at once, so a local broker that is down is fine. An address that doesn't answer (a host that is off or not on the network) leaves the connect waiting for the OS TCP timeout, more than a minute on Linux. Then the 5 s retry starts it again, so the firmware is blocked almost all the time.

This hits anyone running the PC board straight from config.toml.example: its broker_url is mqtt://192.168.0.100:1883, which usually doesn't answer. The log stops at MQTT: connecting to 192.168.0.100:1883 and the BLE HTTP mock on port 4242 refuses connections. Found while testing #74 end to end on virtual-car; pointing broker_url at a closed local port (mqtt://127.0.0.1:1) works around it.

Proposal

  • Connect without blocking the executor: a non-blocking socket polled with Embassy timers (like the rest of the stream), or the connect on a separate thread with the result handed back.
  • Bound the connect with a timeout (a few seconds), then retry as today.
  • Optionally make the example config's broker one that fails fast, or document that the PC board needs a reachable broker or a closed local port.

Done when

With an unreachable broker, the PC board's BLE HTTP server, CAN and vehicle tasks keep working while MQTT retries.

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.