Add sanity-check to TCP options for loop#871
Merged
phillip-stephens merged 5 commits intomainfrom May 3, 2024
Merged
Conversation
zakird
approved these changes
May 3, 2024
Member
zakird
left a comment
There was a problem hiding this comment.
If the packet is malformed, do we want to +=1, or should we just give up on parsing options?
Contributor
Author
|
You're 100% right, thought about this on my walk home. We can't assume that the option that is malformed would have a length of 1 so we should just give up. I'll make that change. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This fixes the bug opened in #868. The cause was if a packet came back with a TCP option in which the length was 0 (this does not conform to the spec ofc), the callback would be stuck in the loop forever.
It also reverts the change I made in #869 that fixed PR #862 since that was not the root cause like I thought it was.
I'll close the PR #870 (which reverted the TCP options commit until I could figure out why it broke) since we should all be good now.
Testing
With the new fix, a large scan doesn't get stuck like it did AND we don't have the 0 rec/sec message in the monitor thread every 43 seconds.