TestISOTPFlowControlFrameTimeout fails on isotp-c/vcan

[driftregion]

//test:test_tp_compliance_tp_sock                                        PASSED in 3.2s
//test:test_tp_compliance_tp_c                                           FAILED in 0.4s
  /home/user/.cache/bazel/_bazel_user/134591d94928ce955abc5088343e92ae/execroot/_main/bazel-out/k8-fastbuild/testlogs/test/test_tp_compliance_tp_c/test.log

setting up CAN
setting up CAN
000149, client sends, 0x7e8 (phys), 01 02 03 04 05 06 07 08 
[  ERROR   ] --- �%e�
[  FAILED  ] TestISOTPFlowControlFrameTimeout
[==========] tests: 5 test(s) run.
[  PASSED  ] 4 test(s).
[  FAILED  ] tests: 1 test(s), listed below:
[  FAILED  ] TestISOTPFlowControlFrameTimeout

 1 FAILED TEST(S)

[muehlke]

Hi @driftregion, I looked into the test and I did not conceive to be compatible with ISOTP C. From what I could test is that, when using ISOTP C, the call to UDSTpSend() returns the right amount of bytes 8 since the SocketCAN write() is not aware of a FC timeout, it just writes the data to the CAN bus. You could suppress this test by checking the transport type and just running the test if using ISOTP Sockets. Otherwise the ISOTP C library would also have to be able to somehow detect this timeout. This is the insight I can offer to you at the moment. Hope you understood it 👍

[muehlke]

@driftregion Is this still relevant? Should I add the new test that omits using ISOTP C for this specific test or would you do it? Just asking because if I should do it, then I would try in the upcoming days.

[driftregion]

Hi @muehlke. Thanks for your interest in this issue.

since the SocketCAN write() is not aware of a FC timeout, it just writes the data to the CAN bus.

That is correct, SocketCAN is link-layer and therefore unaware of FC timeout, but isotp-c is. I think this test is relevant to isotp-c I think there is a path to making the test work for both isotp-c and isotp sockets.

Here is my understanding of the test sequence:

1. transport asked to send 8-byte (multiframe message)
2. transport sends 7/8 bytes, awaits FC frame
3. FC frame not received, transport should return an error

Do you have the same understanding?

It looks like isotp-c checks for an FC timeout here:
https://github.com/SimonCahill/isotp-c/blob/3dc6488f189b06fd40d47280ff36ad9bdb9e39f1/isotp.c#L525

isotp-c is non-blocking, ISOTP_SEND_STATUS_INPROGRESS == link->send_status can be used to check send status. This will change on FC timeout to ISOTP_SEND_STATUS_ERROR. @SimonCahill is this the recommended way to check for FC timeout in isotp-c?

Note that there is no delay between UDSTpSend and assert_true, therefore isotp-c is likely still in the ISOTP_SEND_STATUS_INPROGRESS state.

iso14229/test/test_tp_compliance.c

Lines 109 to 112 in 251b16f

	ssize_t ret = UDSTpSend(client, MSG, sizeof(MSG), NULL);
	// failure is expected as the elapsed 1s timeout raises an error on the ISOTP socket
	assert_true(ret < 0);

I understand that CAN_ISOTP_WAIT_TX_DONE makes isotp sockets block on write(...).
hartkopp/can-isotp#42
hartkopp/can-isotp#65

Because iso14229 targets real-time bare-metal systems we must uphold that transports are non-blocking. We're making an exception for isotp sockets because they imply linux and threads.

[SimonCahill]

Yes, this is the recommended method of determining whether or not the flow control has timed out or not.

Due to the nature of the library, it will also depend on the interval between calls to isotp_poll.

If a timeout has occurred, you can check for both link->send_status and link->send_protocol_result.

The combination of both send_status and send_protocol_result will give you the exact state the library is in.

[muehlke]

@driftregion we were on the same page about this issue, I adapted the test (added the suggestions by @SimonCahill
to check send_status and send_protocol_result) and implemented a new helper function needed in order to "simulate" the UDS server not responding when using ISOTP_C. If you approve my PR #46 then this issue can be closed.

I ran bazel test //test:all on my Ubuntu (24.0.1 LTS, x86_64) machine after installing testing dependencies and they all passed, just testing the fuzz server was skipped.