Location: isotp/transport.go:251-272 (First Frame branch of Recv)
Finding: When Recv sees a First Frame, it sends exactly one Flow Control frame carrying c.cfg.BlockSize, then loops consuming Consecutive Frames until the declared length is reached — it never emits a second FC. Per ISO 15765-2, a non-zero BlockSize tells the sender to transmit at most that many Consecutive Frames and then wait for another Flow Control before continuing. A spec-conformant external sender talking to a go-CAN receiver configured with BlockSize > 0 will send one block, then stall waiting for an FC that never comes, and eventually time out. This currently only "works" against go-CAN's own sender because sendMultiFrame re-requests an FC at block boundaries by waiting on waitFC, so the two sides interoperate with each other despite the receiver being non-conformant against a third party.
Recommendation: Track the Consecutive Frame count against BlockSize inside Recv's reassembly loop and emit a fresh Clear-to-Send Flow Control frame at each block boundary; alternatively, explicitly document and reject BlockSize > 0 as unsupported until this is implemented.
Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.
Location:
isotp/transport.go:251-272(First Frame branch ofRecv)Finding: When
Recvsees a First Frame, it sends exactly one Flow Control frame carryingc.cfg.BlockSize, then loops consuming Consecutive Frames until the declared length is reached — it never emits a second FC. Per ISO 15765-2, a non-zero BlockSize tells the sender to transmit at most that many Consecutive Frames and then wait for another Flow Control before continuing. A spec-conformant external sender talking to a go-CAN receiver configured withBlockSize > 0will send one block, then stall waiting for an FC that never comes, and eventually time out. This currently only "works" against go-CAN's own sender becausesendMultiFramere-requests an FC at block boundaries by waiting onwaitFC, so the two sides interoperate with each other despite the receiver being non-conformant against a third party.Recommendation: Track the Consecutive Frame count against
BlockSizeinsideRecv's reassembly loop and emit a fresh Clear-to-Send Flow Control frame at each block boundary; alternatively, explicitly document and rejectBlockSize > 0as unsupported until this is implemented.Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.