New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Scapy.contrib.modbus cannot handle packets with multiple ADU/PDU sets #4096
Comments
I'm working on fixing this myself, but I'm not familiar with Scapy. It appears we need two steps to a solution.
In the ADU, well, I haven't figured out how to interpret the len variable from the packet during dissection without breaking the build function. The second step is to implement extract_padding. I'll know if I get there. |
Step 1: Properly calculate the length of the PDU using: Step 2: Extract PDU padding with
Step 3: Extract ADU Padding with
Step 4: Add a layer that contains a PacketListField
Step 5: Bind the new layer like:
This works, but I'm not convinced it's still the best way. I suspect there is a way to not use the PacketListField and still have each ADU be a sibling not a child. Are there unit tests associated with this module? |
I have run and passed the unit tests for this module. I intend to expand them in lieu of further guidance. |
Sorry for the delay. You may provide a Pull Request :) |
Brief description
In non-spec packets where multiple ADU/PDU layers exist in parallel the first Modbus ADU Response layer consumes the entire payload. This causes registerVal fields in ModbusPDU03 and 04 responses (at least), to end up significantly larger than expected and missing other ModbusTCPResponse packets.
Scapy version
2.5.0
Python version
3.11.3
Operating system
Windows 10
Additional environment information
No response
How to reproduce
Actual result
132:99
Observe that we have 132 registerVal words, when we expected 99 based on bytecount
Expected result
99:99
Related resources
SamplePackets.zip
The text was updated successfully, but these errors were encountered: