ISO-TP Flow Control: Bound Waiting and Block Size for a Constrained Receiver
Budget complete-PDU storage separately from flow-control pacing, and impose an independent operation deadline when waiting must be bounded. In Linux v6.12, reducing ISO-TP block size does not turn the userspace receive API into a stream of application-consumed blocks. Nor does the presence of a wait-count option prove that every peer wait is bounded by it.
This guide covers ordinary one-to-one ISO-TP with normal addressing and an identified peer. Classical CAN is used for the arithmetic example. Broadcast, application diagnostic services and CAN FD-specific capacity are outside that example. No diagnostic command or network test was sent.
1. Inventory both buffering boundaries
Record maximum accepted PDU length, kernel reassembly capacity, completed-datagram queue budget and application read-buffer size. Add peer limits, addressing, padding rules, kernel revision and the effective socket options.
The Linux ISO-TP guide describes a PDU-oriented socket interface and states that reception feasibility is decided at the First Frame. It also documents that this implementation does not generate WAIT frames.
Do not assume a small flow-control block size permits a PDU larger than the reassembly buffer. Likewise, space for one in-progress PDU does not establish that many completed PDUs can wait indefinitely for a slow application.
2. Assign each pacing value one meaning
| Control | Question it addresses | What it does not establish |
|---|---|---|
| Block size | How many Consecutive Frames before another flow-control boundary? | Total PDU storage capacity |
| STmin | What minimum separation is advertised between Consecutive Frames? | A maximum transfer duration |
| Protocol timeout | How long does this state wait for the next expected event? | A nonrenewable whole-operation deadline |
| Application deadline | When is this operation no longer useful or permitted to wait? | Automatic cancellation of a remote application action |
The UAPI defines block size zero as disabling intermediate block-size flow control, not zero receive capacity. Its STmin byte uses 0x00–0x7F for 0–127 milliseconds and 0xF1–0xF9 for 100–900 microseconds.
For example, 0x03 advertises 3 ms, while 0xF3 advertises 300 microseconds. Preserve the encoded byte and decoded unit in configuration reports. Reserved values must not be selected as an undocumented pacing shortcut.
3. Avoid promising application backpressure at each block
In the receive implementation, the First Frame’s declared length is checked against available reassembly storage, with an allocation attempt where applicable. Excess length leads to overflow handling. Subsequent block boundaries are handled inside the kernel, before the complete PDU is delivered to userspace.
Therefore application scheduling delays do not automatically pause every block through a userspace decision. If the design needs application-controlled admission, implement and qualify that requirement at the appropriate layer instead of assuming the socket provides a per-block callback.
Keep receiver CPU load, kernel buffering and application queue pressure as separate test dimensions. Slowing the application may fill completed-datagram queues without exercising the same condition as insufficient reassembly storage.
4. Bound waiting from the actual implementation
The incoming flow-control handler rearms its timer for a WAIT status; it does not enforce an incoming WAIT count from wftmax. Do not credit that field with a cumulative waiting limit absent from this path.
Give the initiating application a monotonic operation deadline and a defined terminal state for expiry. Specify how blocked work is interrupted or isolated using the application’s approved lifecycle design. A deadline variable alone is ineffective if the supervising task cannot regain control.
On expiry, report the known transport state and any unresolved application outcome. Do not infer that a remote diagnostic action was never executed, and do not retry a consequential service automatically merely because transport completion was late.
5. Keep encoded and forced timing units separate
The 32-bit forced TX/RX separation options are a different interface from the STmin byte. For v6.12, the header specifies nanoseconds, and the implementation consumes them accordingly. The tagged prose guide’s microsecond wording for those overrides does not match that implementation.
This article does not recommend forcing peer pacing. Record the discrepancy when maintaining an integration, pin the actual header/source and verify conversions in an isolated harness. Do not copy a timing integer between these interfaces.
Hypothetical block budget
Consider a fictional 47-byte PDU on normal-addressed Classical CAN, with a six-byte First Frame payload and up to seven payload bytes per Consecutive Frame. The remaining 41 bytes require six Consecutive Frames.
With block size two, the model needs three grants: initially, after two Consecutive Frames and after four. The receiver still needs capacity for the complete 47-byte PDU. This arithmetic excludes arbitration delay, padding details and processing latency; it is not a measured duration or approved peer setting.
6. Qualify stalled and constrained cases
- Maximum permitted PDU and a declared length just beyond the available limit.
- Block size zero versus a small positive size, with the expected flow-control boundaries captured.
- Legal millisecond and submillisecond STmin encodings, checked at the relevant observation layer.
- Missing flow control, repeated WAIT statuses and operation-deadline expiry.
- A slow application receiving repeated complete PDUs, distinct from reassembly exhaustion.
- Sequence and padding failures with their actual returned transport errors retained.
Use artificial payloads and an isolated simulator or approved bench. Do not connect a fixture that issues diagnostic services to an operating vehicle or machine. The tests proposed here were not executed.
7. Publish the supported contract
Retain both endpoint versions, full-PDU capacities, pacing values with units, timeout ownership, deadline behavior and captured fixture results. A useful contract explains which resource limits are protected and which waits can renew. Flow control is only effective when those boundaries match the implementation actually deployed.
