-
Notifications
You must be signed in to change notification settings - Fork 2k
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
gnrc_ipv6_ext_frag: remove fragment header when n-th fragment is first [backport 2020.01] #13169
Merged
fjmolinas
merged 1 commit into
RIOT-OS:2020.01-branch
from
miri64:backport/2020.01/gnrc_ipv6_frag_ext/fix/rm-nth-fh-on-1st-loss
Jan 20, 2020
Merged
gnrc_ipv6_ext_frag: remove fragment header when n-th fragment is first [backport 2020.01] #13169
fjmolinas
merged 1 commit into
RIOT-OS:2020.01-branch
from
miri64:backport/2020.01/gnrc_ipv6_frag_ext/fix/rm-nth-fh-on-1st-loss
Jan 20, 2020
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The reassembly buffer only needs (and stores) the headers *before* the fragment header (called per-fragment headers in RFC 8200, section 4.5). Currently, when a subsequent IPv6 fragment is received before the first fragment the fragment header is however not removed. With this fix it does. (cherry picked from commit 28ef3b6)
miri64
added
Area: network
Area: Networking
CI: ready for build
If set, CI server will compile all applications for all available boards for the labeled PR
Process: release backport
Integration Process: The PR is a release backport of a change previously provided to master
Type: bug
The issue reports a bug / The PR fixes a bug (including spelling errors)
labels
Jan 20, 2020
fjmolinas
approved these changes
Jan 20, 2020
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK!
I'll re-run the test for good measure. |
All good
|
miri64
deleted the
backport/2020.01/gnrc_ipv6_frag_ext/fix/rm-nth-fh-on-1st-loss
branch
January 20, 2020 10:18
80 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Area: network
Area: Networking
CI: ready for build
If set, CI server will compile all applications for all available boards for the labeled PR
Process: release backport
Integration Process: The PR is a release backport of a change previously provided to master
Type: bug
The issue reports a bug / The PR fixes a bug (including spelling errors)
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.
Backport of #13156
Contribution description
The reassembly buffer only needs (and stores) the headers before the fragment header (called per-fragment headers in RFC 8200, section 4.5). Currently, when a subsequent IPv6 fragment is received before the first fragment the fragment header is however not removed. With this fix it does.
Testing procedure
See Release-Specs 4, Task 10. They should succeed for multiple runs, especially if packets get lost. To make sure loss is due to the first fragment missing I applied the following patch (which causes an
E
to appear in the output whenever a packet is lost under this circumstance in the given test run):Issues/PRs references
Cause of RIOT-OS/Release-Specs#145 (comment)