OFTP2 Decoder
Decode an OFTP2 trace (RFC 5024) frame by frame, 100 % client-side. SSID, SFID, DATA, EFID, ESID, NERP codelists, ASCII and base64 input. The dominant EDI transport in European automotive.
Paste an OFTP2 trace (SSID as first frame) to decode it.
How it works
OFTP2 (Odette File Transfer Protocol 2.0, defined by RFC 5024) is the dominant EDI transport protocol in the European automotive industry. It carries ORDERS, DELFOR, DELJIT, DESADV, INVOIC, REMADV flows and CAD payloads (STEP-AP242) between OEMs and Tier-1 / Tier-2 suppliers via ENX, Odette and Galia networks.
The transport layer is binary and TLS-secured (TLS 1.2 / 1.3), but each protocol command is an ASCII frame with strictly fixed-position fields. The decoder reads the envelope without trying to reconstruct the encrypted payload: it surfaces the negotiation (SSID/SSRM), the transferred files (SFID/DATA/EFID), the acknowledgements (EFPA/EFNA/NERP), and the session close (ESID).
OFTP2 session structure
The nominal scenario (RFC 5024 §6.1):
Initiator Responder
│ SSID (Start Session) ─► │
│ ◄─ SSRM (Ready) │
│ SFID (Start File) ─► │
│ ◄─ SFPA (Positive Ack) │
│ DATA × N ─► │
│ EFID (End File) ─► │
│ ◄─ EFPA (Positive End) │
│ ESID (End Session) ─► │
│ ◄─ ESID │ The decoder tolerates several variations: SSRM may be omitted, EFPA can arrive in line, bidirectional transfers (the CD Change Direction command) and resumed transfers with a non-zero restart position are all handled.
Protocol commands
- SSID — Start Session. Exchanges ODETTE-SFID identifiers, protocol level (5 for 2.0, 6 for 2.1), authentication flag, buffer size.
- SSRM — Start Session Ready Message. Application-level session-ready acknowledgement.
- SFID — Start File. Dataset metadata: virtual filename, format (V/F/T/U),
maxRecordSize,fileSize,restartPosition,cipherSuiteSelection,securityLevel. - SFPA / SFNA — File accepted or refused.
- DATA — Data Exchange Buffer. One frame per chunk of the (potentially encrypted) payload.
- EFID — End File. Record and unit (octet) count.
- EFPA / EFNA — Positive / negative end-of-file ack.
- NERP — Negative End Response. Application-level post-transfer rejection (RFC 5024 §5.10).
- ESID — End Session. Close with reason code.
NERP & ESID codes
NERP and ESID frames carry a two-digit reason code. The most common in production:
- 00 — Normal termination.
- 01 — Unknown command.
- 02 — Protocol violation (out-of-sequence command).
- 03 — Invalid user code or password.
- 04 — Incompatible mode (session parameters refused).
- 06 — Invalid restart position.
- 08 — Insufficient storage at destination.
- 10 — Unsupported cipher suite.
- 20 — Application-level rejection by receiver.
- 21 — File corrupted (checksum mismatch).
Security — TLS, signing, encryption
OFTP2 (the 2 matters) requires TLS 1.2 or later on the TCP layer (port 6619 by default). Above that, the SFID may negotiate an additional application-layer encryption:
SFIDCIPH = 00: no extra layer, TLS only.SFIDCIPH = 01: 3DES-CBC + RSA — deprecated. The decoder raisesW_INSECURE_CIPHER.SFIDCIPH = 02: AES-256-CBC + RSA — recommended.SFIDSEC = 03: file signed and encrypted (the defense-in-depth profile expected for sensitive automotive transfers).
Limits
- The decoder does not reconstruct the encrypted payload: it counts DATA chunks and accumulates raw bytes, but does not decrypt (the key material is not part of the trace).
- The underlying TLS handshake is not inspected — it lives below the command layer.
- X.509 validation of certificates used for end-to-end signing (signed EERP) is not performed.
- The decoder accepts two input encodings (raw ASCII or base64); other proprietary trace formats (Mendelson, IBM Sterling, etc.) are not converted automatically.
Privacy
Related documentation
- RFC 5024 — ODETTE File Transfer Protocol 2.0: rfc-editor.org — RFC 5024.
- Odette — the organisation maintaining OFTP: odette.org.
- ENX Association — the private European network used for most OFTP2 automotive transfers: enx.com.