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
TS 29.273 SAR contains MIP6-Agent-Info AVP from RFC5447, which in turn contains MIP-Home-Agent-Address AVP from RFC 4004.
In summary, specs A, B, C, where C depends on B, and B depends on A.
Create a "diameter_3gpp_ts29_273_swx.dia" file containing SAR message definition and which inherits ("@inherits diameter_rfc5447", diameter_rfc5447.dia) to reference "MIP6-Agent-Info".
Create a "diameter_rfc5447.dia" file containing MIP6-Agent-Info definition and which inherits ("@inherits diameter_rfc4004", diameter_rfc4004.dia) to reference "MIP-Home-Agent-Address".
Create a "diameter_rfc4004.dia" file containing MIP-Home-Agent-Address definition.
Hence, diameter_3gpp_ts29_273_swx.dia is not directly inheriting RFC4004: no "@inherits diameter_rfc4004" in diameter_3gpp_ts29_273_swx.dia.
Then create some code which generates a SAR message containing MIP6-Agent-Info which in turn contains a MIP-Home-Agent-Address, and transmits it with diameter:call().
The diameter app will compile just fine, but it will fail to encode it, because the generated diameter_3gpp_ts29_273_swx.erl/hrl file lacks the code to encode MIP-Home-Agent-Address : [error] <0.164.0>@aaa_diameter_swx:handle_call:{175,13} Error: encode
If one adds the explicit "@inherits diameter_rfc4004" in diameter_3gpp_ts29_273_swx.dia, then one can see that extra code is generated in diameter_3gpp_ts29_273_swx.erl/hrl and encoding works fine.
So, right now, one must inherit explicitly all indirect dependency .dia files in order to get a working encoder/decoder.
Import generated code with bug: In there I simply import the generated code with the bug present (no explicit inherit of the indirect dependency rfc4004b in swx file).
By looking at the last commit one can see code which imho should have already been there already before inheriting the indirect spec.
Expected behavior
I see 2 solutions to the problem:
Support automatically inheriting indirect dependencies. If there's spec "A, B and C; C inherits B; B inherits A", then when C inherits B, it should recursively generate code from A too.
Not support automatically inheriting indirect dependencies, but at least fail at compile time saying there's a missing inherit/type, since clearly the generated code will fail at runtime.
Affected versions
I'm seeing this with erlang OTP 26.2.2-1 package from Archlinux.
Additional context
The text was updated successfully, but these errors were encountered:
Describe the bug
TS 29.273 SAR contains MIP6-Agent-Info AVP from RFC5447, which in turn contains MIP-Home-Agent-Address AVP from RFC 4004.
In summary, specs A, B, C, where C depends on B, and B depends on A.
Hence, diameter_3gpp_ts29_273_swx.dia is not directly inheriting RFC4004: no "@inherits diameter_rfc4004" in diameter_3gpp_ts29_273_swx.dia.
Then create some code which generates a SAR message containing MIP6-Agent-Info which in turn contains a MIP-Home-Agent-Address, and transmits it with diameter:call().
The diameter app will compile just fine, but it will fail to encode it, because the generated diameter_3gpp_ts29_273_swx.erl/hrl file lacks the code to encode MIP-Home-Agent-Address :
[error] <0.164.0>@aaa_diameter_swx:handle_call:{175,13} Error: encode
If one adds the explicit "@inherits diameter_rfc4004" in diameter_3gpp_ts29_273_swx.dia, then one can see that extra code is generated in diameter_3gpp_ts29_273_swx.erl/hrl and encoding works fine.
So, right now, one must inherit explicitly all indirect dependency .dia files in order to get a working encoder/decoder.
To Reproduce
The steps mentioned above can be seen in this branch "pespin/diameter-bug" I created in osmo-epdg.git:
https://gitea.osmocom.org/erlang/osmo-epdg/commits/branch/pespin/diameter-bug
One can see 3 commits in that branch:
By looking at the last commit one can see code which imho should have already been there already before inheriting the indirect spec.
Expected behavior
I see 2 solutions to the problem:
Affected versions
I'm seeing this with erlang OTP 26.2.2-1 package from Archlinux.
Additional context
The text was updated successfully, but these errors were encountered: