Skip to content
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

Merged
merged 1 commit into from
Mar 8, 2022
Merged

Fix APER length encoding edge case #91

merged 1 commit into from
Mar 8, 2022

Conversation

gniemirowski
Copy link

Fix for issue #62
Based on open5gs/open5gs@f47f65a

@mouse07410 mouse07410 merged commit 0101252 into mouse07410:vlm_master Mar 8, 2022
@mouse07410
Copy link
Owner

Thanks, @gniemirowski

@gniemirowski gniemirowski deleted the aper_length_fix branch March 8, 2022 21:46
@laf0rge
Copy link

laf0rge commented Jul 6, 2022

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
c) "range" is greater than 256 and less than or equal to 64K (the two-octet case).

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)

osmocom-gerrit pushed a commit to osmocom/asn1c that referenced this pull request Jul 7, 2022
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
osmocom-gerrit pushed a commit to osmocom/asn1c that referenced this pull request Jul 7, 2022
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
@pespin
Copy link

pespin commented Jul 7, 2022

Related PR containing fixes: #93

@grzegorzniemirowski
Copy link

grzegorzniemirowski commented Jul 7, 2022

@laf0rge This commit was about length and not non-negative whole numbers in general. Small lenghts with large ranges (>=64K) should be encoded in single byte. #93 breaks it again.

@mouse07410
Copy link
Owner

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?

@pespin
Copy link

pespin commented Jul 8, 2022

I created this ticket to follow up on this issue: #94

mouse07410 pushed a commit that referenced this pull request Jul 11, 2022
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
mouse07410 pushed a commit that referenced this pull request Jul 11, 2022
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants