Unexpected behavior when copying FieldContainer
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 12.6k
- Forks
- 2.2k
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 56
Description
Brief description
Copying a FieldContainer instance yields a copy of the contained field instead of the container itself.
This is relevant in cases where a class uses the "field copy" feature in its fields_desc, e.g.:
class A(Packet):
fields_desc = [ Emph(ByteField("foo", 0)) ]
class B(Packet):
fields_desc = [ A, ByteField("bar", 0) ]
In this situation, B's foo field should be of type Emph, but it actually is a plain ByteField.
Scapy version
2f3f5dd56bb114b96ce51ce71e2f4ab059b69a42
Python version
3.13.1
Operating system
Linux 6.12.11-200.fc41.x86_64
Additional environment information
No response
How to reproduce
Emph(ByteField("foo", 0)).copy()
Actual result
<ByteField ().foo>
Expected result
# output should be similar to that of
Emph(ByteField("foo", 0))
<scapy.fields.Emph at 0xdeadbeef>
Related resources
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the FieldContainer.copy() behavior and the field-copy path used by fields_desc, using Emph(ByteField("foo", 0)).copy() as the minimal reproduction. Add a regression test showing that copying preserves the Emph container, then verify the A and B example produces an Emph foo field.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 65/100