You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm fairly n00b so may be wrong, but are sequence numbers being compared incorrectly relative to RFC1982? It looks like the comparison (and not just the addition) should account for the potential wraparound by only comparing values that lie within the same half-range (in this case ~32767 values) rather than within the full (65536) range of the values?
If I'm right, instead of doing it with raw u16 values it would probably make sense to integrate the sna crate instead, as it already does this properly (with tests to prove it).
As a quick sanity-check, I believe this test should pass, when applied to sequence numbers per the RFC: assert!(123u16 > 65230u16) It appears to me the current code would result in probably at least one ignored update of each entry every 65536 times around.
The text was updated successfully, but these errors were encountered:
I'm fairly n00b so may be wrong, but are sequence numbers being compared incorrectly relative to RFC1982? It looks like the comparison (and not just the addition) should account for the potential wraparound by only comparing values that lie within the same half-range (in this case ~32767 values) rather than within the full (65536) range of the values?
If I'm right, instead of doing it with raw u16 values it would probably make sense to integrate the sna crate instead, as it already does this properly (with tests to prove it).
As a quick sanity-check, I believe this test should pass, when applied to sequence numbers per the RFC:
assert!(123u16 > 65230u16)
It appears to me the current code would result in probably at least one ignored update of each entry every 65536 times around.The text was updated successfully, but these errors were encountered: