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()

[BenGardiner]

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

in short: yes.

threaded=True appears to 'upgrade' timeouts to hangs in both 2.6.0-rc2 and 2.6.0 for the ISOTP endpoint does not exist case (the origin of this issue) for both drivers tested (candle and slcan).

threaded=True also 'upgrades' timeouts to hangs with the slcan driver in 2.6.0 for the associated RDID single-frame request multi-frame response case (mentioned in https://github.com/secdev/scapy/issues/4838#issuecomment-3334947474 ) .

ver	driver	bg traffic	sr1() threaded=?	ISOTP DNE result	RDID SF req + MF resp result
2.6.0-rc2	candle	YES	False	timeouts ✅	data ✅
2.6.0-rc2	candle	YES	True	hang ❌	data ✅
2.6.0-rc2	slcan	YES	False	timeouts ✅	timeouts ❌
2.6.0-rc2	slcan	YES	True	hang ❌	timeouts [^1] ❌
2.6.0	candle	YES	False	timeouts ✅	data ✅
2.6.0	candle	YES	True	hang ❌	data ✅
2.6.0	slcan	YES	False	timeouts ✅	timeouts [^1] ❌
2.6.0	slcan	YES	True	hang ❌	hang ❌

[^1]: also more likely to yield python-can MUX warning of non-hexadecimal number found in fromhex() (found when repeating the attempts)