Handle IPv6 fragment extension header #832
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
Handle IPv6 fragment extension header
only return NULL when reached end of packet (no data)
Explanation:
When issue #488 was fixed (pr #496) (version=4.3.0, and carried forward to version=4.4.0), the fix prevented IPv6
fragment extension header handling. The need was to prevent addressing headers beyond packet length (to avoid
heap corruption). However, the fix prevents any further processing of the packet after fragment extension header found.
When the extension header
proto=TCPR_IPV6_NH_FRAGMENT
, we can skip that header (fixed length=32 bits),process any further extension headers, and return a pointer to packet data.
When issue #611 was fixed (pr #613), the solution was to leave any IPv6 packets with fragment extension header
untouched (and generate
TCPEDIT_SOFT_ERROR
). This change allowed tcprewrite to continue, and these packetscould be skipped (use option
--skip-soft-errors
). This was to avoid abort/failure of the code to run on pcap havingany fragment headers.
Both of these issues are handled by this PR.
Reference: