[CONTROLLER-807] Payload in non-first fragment of IPv4 packet should not be deserialized. Created: 11/Sep/14  Updated: 19/Oct/17  Resolved: 05/May/15

Status: Resolved
Project: controller
Component/s: adsal
Affects Version/s: Helium
Fix Version/s: None

Type: Bug
Reporter: Shigeru Yasuda Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


External issue ID: 1808

 Description   

When AD-SAL IPv4 class deserializes a raw packet, it deserializes the payload
as protocol header if the IP protocol number is 1 (ICMP) or 6 (TCP) or 17 (UDP).
But if an IPv4 packet is fragmented, the protocol header is present only in
the first fragment. So IPv4 class should not deserialize the payload if
fragmentation offset is not zero.

If a non-first fragment of an ICMP packet is deserialized as ICMP header,
ICMP class may corrupt the payload.

1. ICMP header is not present in non-first fragments of an ICMP packet.
But currently IPv4 class deserializes the payload as ICMP class instance
irrespective of fragmentation offset.

2. If a deserialized ICMP instance is serialized again, ICMP class always
updates the checksum field. So the computed checksum will be stored into
the payload unexpectedly if the packet is non-first fragment.

That is why IPv4 class should not set a protocol class to "payloadClass" field
unless the fragmentation offset is zero. The payload in non-first fragments
should be treated as raw bytes.



 Comments   
Comment by Shigeru Yasuda [ 11/Sep/14 ]

I verified that the following patch fixed this issue.

https://git.opendaylight.org/gerrit/11034

Comment by Carol Sanders [ 05/May/15 ]

This bug is part of the project to Move all ADSAL associated component bugs to ADSAL.

Generated at Wed Feb 07 19:53:55 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.