-
Notifications
You must be signed in to change notification settings - Fork 72
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
Fix APER length encoding edge case #91
Conversation
Thanks, @gniemirowski |
This commit is actually wrong. It doesn't fix the case, but it breaks the corner cases. It should be reverted! Section 4 of X.691 defines 64K as 65536, and Section 11.5.7 explicitly states So after this commit, you changing from less-than-or-equal 65536 to less-than 65536, resulting in all non-negative whole numbers with a range of 65536 to be encoded the wrong way (more than two octets) |
This commit adds a test case which shows a bug introduced in 0101252 [1]. As a result, a small value (under 1 octet) with range spanning full 2 octets (65536) is encoded incorrectly as 1 octet. Section 4 of X.691 defines 64K as 65536, and Section 11.5.7 explicitly states """ c) "range" is greater than 256 and less than or equal to 64K (the two-octet case). """ [1] mouse07410/asn1c#91
Fixes bug introduced in 0101252 [1]. This is actually mainly a revert of that commit. That commit introduced a bug in which a small value (under 1 octet) with range spanning full 2 octets (65536) was encoded incorrectly as 1 octet. Section 4 of X.691 defines 64K as 65536, and Section 11.5.7 explicitly states """ c) "range" is greater than 256 and less than or equal to 64K (the two-octet case). """ This was noted while encoding SBc-AP messaged generated with asn1c, where a SEQUENCE OF uses aper_put_length() to set the number of items. [1] mouse07410/asn1c#91
Related PR containing fixes: #93 |
First, it would be easier to track if this discussion was happening in a new issue, rather than in a merged and closed PR. Would one of you like to open a new issue, or should I do that? |
I created this ticket to follow up on this issue: #94 |
This commit adds a test case which shows a bug introduced in 0101252 [1]. As a result, a small value (under 1 octet) with range spanning full 2 octets (65536) is encoded incorrectly as 1 octet. Section 4 of X.691 defines 64K as 65536, and Section 11.5.7 explicitly states """ c) "range" is greater than 256 and less than or equal to 64K (the two-octet case). """ [1] #91
Fixes bug introduced in 0101252 [1]. This is actually mainly a revert of that commit. That commit introduced a bug in which a small value (under 1 octet) with range spanning full 2 octets (65536) was encoded incorrectly as 1 octet. Section 4 of X.691 defines 64K as 65536, and Section 11.5.7 explicitly states """ c) "range" is greater than 256 and less than or equal to 64K (the two-octet case). """ This was noted while encoding SBc-AP messaged generated with asn1c, where a SEQUENCE OF uses aper_put_length() to set the number of items. [1] #91
Fix for issue #62
Based on open5gs/open5gs@f47f65a