Documentation
¶
Overview ¶
Package canfd decodes a captured CAN / CAN-FD frame in the SocketCAN candump text representation into its structured fields — the format-independent signal an automotive pentester reads off a bus capture without the bus attached.
Wrap-vs-native judgement ¶
Native. Like the other offline Sub-GHz / protocol decoders in this tree (subghz_tpms_decode, subghz_weather_decode, the canbus_* live Specs notwithstanding), the reusable part is a public deterministic transform: the SocketCAN candump frame grammar (ID#data / ID##flags+data), the ISO 11898-1:2015 CAN-FD DLC→length table, and the SAE J1939-21 extended-ID decomposition. The live canbus_* Specs drive an MCP2515 daughterboard to read frames; this decodes a frame already captured (candump -L, a SavvyCAN/Wireshark export, or a Flipper-side CAN sniff) with no hardware attached.
What it covers ¶
- Classic CAN 2.0 (ID#data) and CAN-FD (ID##flags+data) candump frames, standard (11-bit) and extended (29-bit) identifiers.
- CAN-FD flag nibble: BRS (bit-rate switch) and ESI (error-state indicator); RTR (remote frame) for classic CAN.
- The CAN-FD DLC↔length mapping (0-8, 12, 16, 20, 24, 32, 48, 64), flagging payloads that aren't a legal CAN-FD length.
- SAE J1939 decomposition of 29-bit IDs: priority, EDP/DP, PDU format/specific, source address, and the resolved PGN with PDU1 (destination-specific) vs PDU2 (broadcast) classification — the heavy-vehicle / agricultural / marine bus most extended-ID traffic uses.
Out of scope (deliberately) ¶
- Signal-level decode (physical bytes → engine RPM, etc.): that needs a per-vehicle DBC database and is unverifiable here, so the raw data bytes are surfaced for the operator to apply their DBC — a confidently-wrong signal value is worse than none.
- Live capture (use the canbus_* Specs with the MCP2515 board).
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func Encode ¶ added in v0.409.0
func Encode(r EncodeRequest) (string, error)
Encode builds the SocketCAN candump frame string for a CAN / CAN-FD frame — the inverse of Decode. The identifier is rendered the way candump pads it (3 hex chars for standard, 8 for extended) so Decode infers the width back correctly; classic frames use "ID#data" (or "ID#R"/"ID#Rn" for a remote frame) and CAN-FD frames use "ID##<flags-nibble><data>" with the BRS/ESI flags in the nibble. The result is exactly what canbus_inject sends and round-trips through Decode.
Types ¶
type EncodeRequest ¶ added in v0.409.0
type EncodeRequest struct {
ID uint32 // CAN identifier (11-bit standard or 29-bit extended)
Extended bool // 29-bit extended identifier
FD bool // CAN-FD frame (## grammar)
BRS bool // CAN-FD bit-rate switch (FD only)
ESI bool // CAN-FD error-state indicator (FD only)
RTR bool // classic remote frame (classic only)
RemoteDLC int // requested DLC for a remote frame (0..8)
Data []byte // payload (ignored for RTR)
}
EncodeRequest describes a CAN / CAN-FD frame to build in the SocketCAN candump grammar.
type J1939 ¶
type J1939 struct {
Priority int `json:"priority"`
EDP int `json:"extended_data_page"`
DP int `json:"data_page"`
PDUFormat int `json:"pdu_format"`
PDUSpecific int `json:"pdu_specific"`
SourceAddress int `json:"source_address"`
PGN int `json:"pgn"`
PGNHex string `json:"pgn_hex"`
Kind string `json:"kind"`
DestAddress *int `json:"destination_address,omitempty"`
}
J1939 is the SAE J1939-21 decomposition of a 29-bit extended ID.
type Result ¶
type Result struct {
Format string `json:"format"`
IDHex string `json:"id_hex"`
IDDecimal uint32 `json:"id_decimal"`
Extended bool `json:"extended"`
IDBits int `json:"id_bits"`
RTR bool `json:"rtr,omitempty"`
FDF bool `json:"fdf"`
BRS bool `json:"brs"`
ESI bool `json:"esi"`
DLC int `json:"dlc"`
DataLength int `json:"data_length"`
DataHex string `json:"data_hex"`
J1939 *J1939 `json:"j1939,omitempty"`
Notes []string `json:"notes,omitempty"`
}
Result is the structured decode of a CAN / CAN-FD frame.
Source Files