Regression in "offset" field value on SOMEIP-TP packets: Incorrect "offset" value generation using SOMEIP.fragment method

[wissemnano]

Brief description

There is a regression in the SOMEIP.fragment method for SOMEIP-TP packets starting from Scapy versions >= 2.6.x. The issue is caused by the change in the definition of the offset field from BitField("offset", 0, 28) to BitScalingField("offset", 0, 28, scaling=16, unit="bytes"). This change introduces a scaling factor of 16, which, combined with the division by 16 in the fragment method, results in incorrect offset values.

Context:
In the fragment method, the offset value is calculated using the following line:

q[fnb].offset += i * fragsize // 16

Because the offset field is now defined as a BitScalingField with scaling=16, the value is automatically scaled by 16. This means that the calculation in the fragment method is effectively dividing the expected offset by 16 twice, leading to incorrect results.

Regression:
This is a regression because the same code works correctly in Scapy versions <= 2.6.x, where the offset field was defined as BitField("offset", 0, 28) (no scaling). However, in Scapy versions >= 2.6.x, the receiver drops the packets because the offset values are incorrect.

check the offset field value on the attached failed example

as workaround i just do this: remove the division by 16 in the someip.py file

q[fnb].offset += i * fragsize

Scapy version

= 2.6.x

Python version

= 3.10

Operating system

Ubuntu

Additional environment information

No response

How to reproduce

fragments = tp_packet.fragment(fragsize=segment_length)

Actual result

seg_v11_fault.zip

Expected result

unicast_Tp_Vars_reverse.zip

Related resources

No response

[wissemnano]

I need to mention again it's work fine (the script) for previous version scapy <2.6.x, but it failed for scapy >=2.6.0

[polybassa]

Thanks for the report