Isotp soft socket sr1 hang/no return and timeout= was specified

[BenGardiner]

Brief description

In between 2.6.0-rc2 and 2.6.0 this started for me . Problem occurs also in 2.6.1

In working (from my perspective) version using isotp soft socket .sr1() to an ecu which does not respond will eventually return with empty response when timeout= was passed

In broken versions .sr1() blocks indefinitely.

Scapy version

2.6.1

Python version

3.11.11

Operating system

Windows 11

Additional environment information

No response

How to reproduce

Issue a UDS request with an isotp soft socket .sr1() and a non-zero timeout. Choose IDs such that the there will be no response from the target ECU.

Actual result

sr1() blocks indefinitely

Expected result

Expected result is a return sometime after the timeout.

Related resources

No response

[BenGardiner]

I have attached some pcaps and matching logic analyzer captures for both 2.6.0-rc2 and 2.6.0 ISOTP requests to a non-existent endpoint for both candle and slcan python-can drivers. In all 2.6.0-rc2 cases the result is timeouts exhausting the retries and in all 2.6.0 cases the result is an indefinite hang.

scapy-2.6.0_v_2.6.0-rc2-captures.zip

cc @polybassa @epozzobon

also some related behaviour with RDID returning a long value (ie. where the req is short but the response is many fragments); these RDIDs fail depending on the python-can driver used, the background traffic and also -rc2 or not:

version	driver	background traffic	result
2.6.0-rc2	candle	YES	✅
2.6.0-rc2	slcan	YES	timeouts
2.6.0-rc2	slcan	NO	✅
2.6.0	candle	YES	✅
2.6.0	slcan	YES	indefinite hang
2.6.0	slcan	NO	✅

[polybassa]

Thanks a lot for the Issue and the analysis. I'll dig into it.

[polybassa]

Hi Ben, could you please verify one thing.

Does the issue still exists, if you pass threaded=True to sr1()