-
Notifications
You must be signed in to change notification settings - Fork 557
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
Support of Aligned PER and Information Object Class #115
base: master
Are you sure you want to change the base?
Conversation
Tested with S1AP. Associated Table still needs to be designed.
@mouse07410 |
I did not look into #125 beyond "does it pass the tests". If it does not support Information Object Class, perhaps it would be better for you to add that support on top of #125? Because two competing PRs doing (mostly) the same thing isn't good, and my fork already merged #125 (and in addition - #129 so larger constraints are supported). If #125 lacks Info Object support, and you add that support to it - I'll merge your code. Otherwise, you'd have to wait for @vlm to decide which one of the two to merge, and in the end it might not be yours anyway. |
OK, I'll see what I can do |
Thank you! Please feel free to take a closer look at my fork, to see what enhancements are already there, so your amount of work could be less. ;-) |
@AuthenticEshkinKot also please take a look at #99 - the main reason I didn't merge it is that it fails CI. I didn't look for the cause (yet). If it's simple enough to fix, and if it addresses your needs - perhaps you could propose a change, and I'd integrate #99 with your fix? I just don't know what's the simplest/fastest/easiest way to add the capability you need - whether it's for you to create a subset of #115 that's compatible with #125 and #129, or to fix #99 , or... |
@mouse07410
Hope, this will help. |
First, thank you for the work you're doing. Merging #99 and #125 - my main concern is that #99 fails the CI tests. I'm trying to avoid introducing code that does not pass the CI. By the way, this was the main reason I initially merged #125 (that passes the CI) rather than #115 (that fails the CI). Since having support for wider constraints in PER is desirable - perhaps I need to re-consider my approach and merge #115 instead... For that to happen, I need for #115 to (a) pass the CI tests, and (b) support wider constraints (what #129 accomplishes). Also, we now know that #125 did not address some issues resulting in failure to properly support Information Object Class. It would also be good to know if there are ASN.1 constructs supported in #125 that #115 does not deal with. I.e., I am trying to figure - are these two PRs each cover things that the other one doesn't, or does one of them (#115) support everything that the other one (#125) does? |
Update Here are some details regarding why I'm not merging #99 until it is fixed:
Take a good look at the last error cluster - it looks like that code generates two copies of the same thing! Until and unless all of the above are fixed - that code is going nowhere. (As I said, it was the reason I did not consider #115 for inclusion, and chose to settle on #125 as it passed all the CI checks.) |
@mouse07410 |
Your master and #99 got same problem, as @ikarso's version - they fail to decode my example of APER. |
First of all - thank you for trying #99 and master for me.
This is sad, and strange. I've tried both of these branches with the data in https://github.com/ikarso/3GPPTS36.413_AuthenticEshkinKot, and it all parsed/decoded beautifully. What data were you using that failed to decode? What test-program did you use? I followed what @ikarso wrote in the README of his repo - and all worked well. Can you please add the data that #99 fails to decode to your fork (with some description, hopefully :)? So I can pull it and try myself?
PR has been created. There are two conflicts. One - in The other one is in |
@mouse07410 |
Perfect! Thanks!!
Ha! :-)
Sure, whatever's the most convenient way.
My pleasure - and thank you for fixing #115, and helping with the rest of this thing. Without your help Info Object support wouldn't have been merged. |
Hi, does one of you know if the APER support will be integrated into the master branch? At the OpenairInterface project we need to use S1AP release 14 and we need the APER encoding/decoding functionality. Our current fork does not compile the version 14 of S1AP, probably because of the information object class, which you implemented after our fork. It would actually be good for us to switch back to the main (this one here) asn1c instead of using our own version. From what I understand, the only problem for us to do so is the support of APER (but I didn't check deeper) which is not present. I can provide some help if you need. Thanks and regards. |
Hi, @cedric-roux |
@AuthenticEshkinKot @brchiu thanks. To be honest I would prefer to see APER put into this repository. I don't want to juggle with various repositories and patch sets. I will get lost. :) But for some particular research projects we have at OpenairInterface, that may make it. Thanks. |
ITNOA Hi, @vlm did you any plane to merge this PR? |
Hi, I used this 115 Pull request code, But still I am facing issue like this : |
Hi, @badhrinathpa ! |
Hi @AuthenticEshkinKot |
@badhrinathpa |
@AuthenticEshkinKot Thanks for the help. That solved the max ERAB problem. But there were other issues too. I needed the APER encode/decode. So, Used the code from master branch of @mouse07410 and used the command : |
|
This patch adds support of big integers. Cherry-picked from original vlm/asn1c master branch da997b1 Signed-off-by: Krzysztof Witek <[email protected]>
Signed-off-by: Krzysztof Witek <[email protected]>
APER encoded entities are padded on one byte boundaries. This patch skips the padding bits in order to point to the correct byte in the stream. Signed-off-by: Krzysztof Witek <[email protected]>
If there is nothing to read we should not access the data buffer. Signed-off-by: Krzysztof Witek <[email protected]>
This patch provides a workaround in case of an extensible enumaration with a huge undefined index. Signed-off-by: Krzysztof Witek <[email protected]>
The X.691 specs state that: "Bitstrings constrained to a _fixed length_ less than or equal to 16 bits do not cause octet alignment. Larger bitstrings are octet-aligned in the ALIGNED variant." This patch takes into account the above statement that only applyes to fixed length strings. Signed-off-by: Krzysztof Witek <[email protected]>
Aper decoder fixes
@AuthenticEshkinKot I see you've made updates and applied some fixes to this PR - could you please check it against my fork https://github.com/mouse07410/asn1c.git (which merged the original #115), branch Thanks! |
…ysztof Witek <[email protected]> commit a12c7fa from vlm/asn1c #115
With this changes I can parse asn1 from 3GPP TS 36.413 and decode incoming S1 messages.
This patchset consists of two parts: