commaai/openpilot · warning

failed to receive

Error message

failed to receive

What it means

Emitted by the PandaStream receive thread when panda->can_receive(raw_can_data) returns false while the device still reports connected. It means a bulk CAN read from the panda failed (libusb transfer error) — the message is generic on purpose since the underlying usb library logs the detailed error. The thread `continue`s, so it retries on the next 1 ms tick.

Source

Thrown at openpilot/tools/cabana/streams/pandastream.cc:62

}

void PandaStream::streamThread() {
  std::vector<can_frame> raw_can_data;

  while (!exit_) {
    std::this_thread::sleep_for(std::chrono::milliseconds(1));

    if (!panda->connected()) {
      fprintf(stderr, "Connection to panda lost. Attempting reconnect.\n");
      if (!connect()){
        std::this_thread::sleep_for(std::chrono::milliseconds(1000));
        continue;
      }
    }

    raw_can_data.clear();
    if (!panda->can_receive(raw_can_data)) {
      fprintf(stderr, "failed to receive\n");
      continue;
    }

    MessageBuilder msg;
    auto evt = msg.initEvent();
    auto canData = evt.initCan(raw_can_data.size());
    for (uint i = 0; i<raw_can_data.size(); i++) {
      canData[i].setAddress(raw_can_data[i].address);
      canData[i].setDat(kj::arrayPtr((uint8_t*)raw_can_data[i].dat.data(), raw_can_data[i].dat.size()));
      canData[i].setSrc(raw_can_data[i].src);
    }

    handleEvent(capnp::messageToFlatArray(msg));

    panda->send_heartbeat(false);
  }
}

View on GitHub (pinned to 516ec1e682)

Solutions

1. Check the libusb/panda layer output just before this message for the actual errno/libusb error code — this line is only the generic symptom.
2. Rule out the physical layer: shorter/shielded USB cable, powered hub, different port.
3. Verify CAN bus settings (baud rate per bus in the panda stream dialog) match the vehicle — a misconfigured bus floods errors.
4. Reflash/Power-cycle the panda if the device is wedged (unplug, replug, confirm with dmesg).

When it happens

Trigger: An active panda stream where can_receive() fails: USB transfer error/timeout from the panda (LIBUSB_ERROR_IO/TIMEOUT), device firmware wedged but still enumerated, bus congestion producing oversized/garbled packets the library rejects, or the connection dropping between the connected() check and the read. Because the loop just continues, a persistently failing read prints this in a hot loop.

Common situations: Marginal USB link (EMI, long cable, unpowered hub) causing transfer errors; panda firmware crash where enumeration survives but endpoints stall; CAN bus error storm from a bad baud-rate configuration hammering the receive path.

Related errors

• %s
• Connection to panda lost. Attempting reconnect.
• failed to open panda %s
• read failed: {e}
• write failed: {e}

AI-assisted analysis of commaai/openpilot@516ec1e682 (2026-08-15). Data as JSON: /api/errors/cc50b34351b91f3b. Report an issue: GitHub.